Add separate ROSDEP_ETC_DIR to help situations like #582.

[allenh1]

Adds a separate variable to control where rosdep keeps its sources, as ROS_ETC_DIR is used for other purposes.

connects to #582

---

This change is 

[allenh1]

I'll rebase this on top of #584 once @dirk-thomas releases the new patch release.

[allenh1]

@dirk-thomas Ok, rebased.

[allenh1]

@dirk-thomas could we open discussion abuot this issue again? @awesomebytes is trying to install in a non-root prefix, and this came up again.

[dirk-thomas]

@dirk-thomas could we open discussion abuot this issue again?

Sorry, I am not maintaining this repo. I will leave it up to @wjwwood to comment.

[wjwwood]

Realistically, this isn't high priority for me and I won't have time to get to it right now. Sorry @allenh1, perhaps in a few weeks I can swing around and do some rosdep maintenance.

[yev-d]

Any updates on this? I ran into this issue when I've installed ros through conda-forge, and tried to inisialize rosdep, within the conda environment, which it failed since it was looking for /etc/ros in the root. My issue I've posted is here on github.
Would love to get this resolved somehow, or if at least someone would confirm that ROS doesn't work with conda.

[tfoote]

@yev-d If you could test this and provide feedback on the PR that would be helpful. I think that the statement that rosdep doesn't work on conda without access to /etc/ros is valid. That's not the same as saying that ROS doesn't work with conda.

I believe that this is moderately low priority as most people will just drop the rosdep sources file into that location and then move on. It's not optimal but it's a small onetime cost to work around. This is especially true because rosdep is designed to work with the system packages so having the sources systemwide is actually a designed feature. Your use case with Conda may have slightly different priorities, if so please consider contributing to help make those priorities happen.

[yev-d]

@tfoote You know, I'm convinced that ROS does work with conda, and that I'm just missing the workarounds like the one you've mentioned.
P.S. No idea what it means to "test this" or to test anything =D, so I'll leave it at that ^_^

[Tobias-Fischer]

It works fine for me on conda-forge as described in conda-forge/rosdep-feedstock#4, however it should say "ROS_ETC_DIR" instead of "ROSDEP_ETC_DIR" (see https://www.ros.org/reps/rep-0123.html)

[allenh1]

@wjwwood could you please give this patch a glance? Seems it's come up again.

[Tobias-Fischer]

I just realised that @allenh1 deliberately created a new environment variable. In this case merging this PR does not add any risks at all, as it falls back to the current location if the new variable is not defined.

Discussion point is then whether this needs to be documented somewhere ..

[Tobias-Fischer]

Is there any news on this PR?

[nuclearsandwich]

@Tobias-Fischer to help this PR along would you be interested in adding a test which exercises the new behavior?

[Tobias-Fischer]

Hi @nuclearsandwich - I am not familiar with rosdep and writing a test would unfortunately consume too much of my time. However, I am not sure a test is really needed - all the PR does is turning a constant into a configurable variable via an environment variable. Rather than a test, I think some documentation would be more beneficial; but as I said, I am not familiar enough with rosdep to have a strong opinion.

[nuclearsandwich]

I am not sure a test is really needed

I'd like a test which simulates a rosdep init run with ROSDEP_ETC_DIR defined to a test path and verifies that the default source is created there to guard against future regressions.

I think some documentation would be more beneficial

Documentation would also be a fantastic addition and your contributions there would be welcome.

https://github.com/ros-infrastructure/rosdep/blob/master/doc/overview.rst#setting-up-rosdep is a good place to start if you would like to update the docs. If you target this pull request branch we could keep everything in one branch before merging.

[peci1]

I think this PR is obsolete - isn't all of the required functionality already available by setting ROSDEP_SOURCE_PATH?

get_sources_list_dir() first uses the hardcoded path, but then it passes it as default to get_sources_list_dirs(), which first reads ROSDEP_SOURCE_PATH, and only if it doesn't exist, returns the hardcoded path. Otherwise, it returns the path specified in the environment variable.

The only difference I see is that get_sources_list_dirs() checks for existence of the directories, and if the one specified in ROSDEP_SOURCE_PATH doesn't exist, it returns the hardcoded path. But making sure that the directory exists before calling rosdep is pretty easy IMO.