-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: opt-in to make target repo writable #123
WIP: opt-in to make target repo writable #123
Conversation
For now I would prefer to merge #120 instead. |
(Hmm this title (゚д゚)) I saw #122 where existing users might prefer the current behavior, in which they can write into source space.
While right thing IMO to do may be to force not to use source space (and correct the sample code on travis-ci.org), merging this PR is okay temporarilly for me, to maintain the same behavior that was previously functioning (like #122 case). |
For now I would suggest to not merge it, but keeping it open for voting :) |
Ok. I just slightly changed the title, to reflect the context of this change better (and also to remove possible unintended political implication ;) ). |
97fff86
to
8958828
Compare
I understand why you want to enforce "best practices", but the consistency of the user experience for an application like this is the most important feature. I don't need you to save me from myself. Deprecate the behavior, print a notice, and make the change in some major version release. Unless I force git to checkout a specific commit of this library, you can break my tests at will. In my humble opinion, +1. |
We are refactoring a lot (#98) and this leads to regression bugs as well. Side effects like patching within the source are a great opportunity to shoot yourself in the foot, so this should be prevented by default.
It is hard to provide releases if everyone is cloning the source HEAD.. |
8958828
to
86b6c35
Compare
I have refactored this PR to be an opt-in flag instead. |
86b6c35
to
a30e7ad
Compare
opt-in for write access to target source
a30e7ad
to
26b8b61
Compare
I have refactored this once again. |
While I am of the opinion that "good tools prevent unwary users to shoot themselves in the foot", I am currently relying on pip to install python packages as editable (to get a clean python installation instead of a ROS |
Shouldn't I am really struggling to open this door, as it would allow users to just set this option instead of fixing the underlying issues |
Even if it seem harsh I have to state this (given all the bad advices I see around the web) : Setting Incidentally ROS uses the PYTHONPATH in a way that makes it incompatible with existing de-facto python standard like virtual environments. Hence my long struggle with catkin_pip, which cannot use virtualenv. It ultimately boils down to "Workspaces stack up (and confuse everyone), virtualenvs just dont." plus a bunch of other incompatible trickeries. The However the other one, I am not aware of anything I can do to work around it at this time : https://pip.pypa.io/en/stable/reference/pip_install/#editable-installs especially says :
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this PR is review-merge-ready, but if it is then +1 for backward compatibility, no matter how long it's been since the disruptive change.
I'm just not sure if readers of this feature get what it means, because I'm afraid people may call "target source" in their own way. Personally in ROS world "workspace" is the most specific but I don't know.
@@ -187,6 +187,7 @@ Note that some of these currently tied only to a single option, but we still lea | |||
* `USE_DEB` (*DEPRECATED*: use `UPSTREAM_WORKSPACE` instead. default: true): if `true`, `UPSTREAM_WORKSPACE` will be set as `debian`. if `false`, `file` will be set. See `UPSTREAM_WORKSPACE` section for more info. | |||
* `USE_MOCKUP` (default: not set): reletive path to mockup packages to be used for the tests | |||
* `VERBOSE_OUTPUT` (default: not set): If `true`, build tool (e.g. Catkin) output prints in verbose mode. | |||
* `WRITABLE_SOURCE` (default: false): Set this to true if you need the target source to be writable at build (not recommended). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
target source
could better describe what actually points to. target source in your workspace
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the source in TARGET_REPO_PATH
?
(all other src folders are writebale anyway..)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe catkin tools or CMake already has a variable name for this and we can reuse it ? like PROJECT_SOURCE_DIR or so? https://cmake.org/Wiki/CMake_Useful_Variables
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for PROJECT_SOURCE_DIR
. That sounds more common.
Meanwhile TARGET_REPO_PATH
is probably an equivalent in industrial_ci
. Either way, it may not be something that is exposed to end users is it as an API, except in document like this thread? So we could keep TARGET_REPO_PATH
in the source code while using PROJECT_SOURCE_DIR
in document, as an idea.
First of all I still not recommend to merge it. Something like |
I know this has been a long-standing issue and no one has commented on this in some time but I wanted to mention a situation that I found where this is a problem and I don't see any other solution. I happened across the mavros repo recently and saw that the author had created a commit to start using industrial_ci. However, he quickly gave up because a read-only file system in the src folder caused the catkin CMake macro em_expand to be unable to write its output file within the source directory of the project. As the em_expand() function still exists in the current version of catkin, it seems like this is a perfect use-case for allowing writable src subdirectories. |
@JWhitleyAStuff: Thanks for pointing this out! |
@ipa-mdl I prefixed the title with "WIP". I've liked that practice to communicate better. Have you changed mind about this PR to move forward? |
Is this pullrequest likely to be merged at some point? I would be very interested in having a writable src folder in travis CI. |
I don't think so.
Please try #361. Despite the branch name, it still uses catkin_tools for ROS1.
|
Thanks for the quick reply and the pointer! |
I better close this now, #361 is the way to go. |
fixes #122 and probably #121
I really don't like making the src writable again, as the build should never mess with the src folder.
However, it was writable before and this fix improves the user experience.