[ros-users] ROS_HOME and rosinstall

[Ken Conley]

On Thu, Feb 2, 2012 at 2:57 PM, Thibault Kruse <kruset at in.tum.de> wrote:
> I don't know much about those configuration files, but the same
> argument holds for it. If the user wants different configuration files,
> and used different ROS_HOME's, causing duplicate log / test
> result folders.
>
> Given that there are already the variables:
> ROS_LOG_DIR
> ROS_TEST_RESULTS_DIR
>
> it would not be inconsistent to that structure to also have
> ROS_CONFIG_DIR
> ROS_BINARY_DIR
>
> And it might indeed by most sensible to use a same location as default for
> ROS_LOG_DIR
> ROS_TEST_RESULTS_DIR
> ROS_CONFIG_DIR
> and leaving those vars empty by default, whereas having individual locations
> for
> ROS_BINARY_DIR
>
> I am aware that currently this only affect roslisp and (AFAIK) rosjava
> users, so most people
> reading this probably don't care either way. I'd like to hear Damon Kohlers
> view, putting you
> on BCC to raise your attention.

Actually... I wrote that bit of mess in rosjava (and am looking
forward to re-writing it), but Damon is welcome to chime in as well.

A 'ROS_BINARY_DIR' doesn't make much sense to me as it's irrelevant
whether or not its binary or not.  The intent of ROS_HOME is to be a
program-writable location.  Some of the data rosjava writes to
~/.ros/rosjava is text, some is binary; all it generally means is
someplace to store stuff.

That's a long way of saying a 'ROS_BINARY_DIR' has the exact same
meaning as ROS_HOME: where do I dump stuff.  It happens that, for
historical reasons, we happen to have sub-categories of stuff we can
override, like log and test files, but, IIRC, that's only because
ROS_LOG_DIR was invented before ROS_HOME.  If we had more foresight
and came up with ROS_HOME first, I doubt ROS_LOG_DIR would exist.  We
probably would have done ROS_TEST_RESULTS_DIR differently as well.

So, for me at least, it's mainly a question of whether or not we:

 a) have programs be responsible for their own scoping, e.g. detecting
the distro
 b) shift ROS_HOME around to provide scoping

I'm starting to lean more towards (a) because I think it provides more
flexibility in the long term.

For example, in the configuration file case, imagine if you had to
have a different .emacs/.vimrc file for every ROS setup that you had.
As long as the configuration syntax is future-proofed, then I
shouldn't have to re-establish my tool configuration depending on each
distribution (note: I am talking about tool config, not library
config).  Imagine, for example, preferences for rosinstall, rosdep,
rviz, rxbag, etc...

 - Ken

>
> cheers,
>  Thibault
>
>
> On 02/02/2012 07:47 PM, Ken Conley wrote:
>>
>> I'm not sure how I feel about this one.  I see the merits on both
>> sides; there's also some features in Fuerte that may provide
>> alternatives.  There's basically three categories of data at issue
>> here:
>>
>> (1) Log data: There's not much issue mixing log data, so this is
>> likely more problematic to segment as it makes it harder to clean up.
>> The log directory is separately configurable via ROS_LOG_DIR, but I'm
>> not sure that's related.
>>
>> (2) Generated program resources: ROS_HOME is the only guaranteed
>> writable location to ROS programs, so these dynamically get generated
>> there.  Having a single ROS_HOME is problematic for these tools.
>>
>> (3) Configuration files: ROS_HOME is intended to house .rc-like
>> configuration files.  This ability is a bit underutilized at this
>> point, but the hope/vision is that more tools will be more
>> user-configurable.  Having more ROS_HOMEs is probably bad for these
>> tools (configuration file compatibility aside), as it means that users
>> would have to copy customizations into new ROS_HOMEs each time.
>>
>> Thus, separate ROS_HOMEs benefits generated resources, hurts
>> configuration files, and probably leads to accumulate of extra data.
>>
>> In ROS Fuerte, programs will more easily be able to detect the ROS
>> distribution codename (e.g. fuerte, groovy) via:
>>
>>  * etc/ros/distro
>>  * ROS_DISTRO environment var
>>  * rosversion -d
>>  * rospkg.distro.current_distro_codename()  (python)
>>
>> Today we're working on fixing up roslisp, so I can explore having it
>> use a distribution-specific subdir for its generated assets.  This is
>> not the same a rosinstall-specific directory, but will at least
>> address a common case of the problem.
>>
>>  - Ken
>>
>> On Wed, Feb 1, 2012 at 11:46 AM, Thibault Kruse<kruset at in.tum.de>  wrote:
>>>
>>> Hi,
>>>
>>> ROS_HOME currently defines a path that can be used to dump certain build,
>>> compilation and runtime files (e.g. test results, log files, rosjava
>>> jars,
>>> roslisp binaries). See http://ros.org/wiki/ROS/EnvironmentVariables
>>> It defaults to ~/.ros.
>>>
>>> I believe it can easily cause trouble when users have different ROS
>>> distros
>>> installed that share the same ROS_HOME, in particular for binaries.
>>>
>>> I wonder whether it would be useful to make rosinstall by default set
>>> ROS_HOME to something more specific than ~/.ros.
>>> For debian packages of ROS, it might be useful to set ROS_HOME to
>>> ~/.ros/<distro>  in the setup.sh.
>>>
>>> Else, rosinstall could specify a specific subdirectory for the given
>>> rosinstall location.
>>> That could e.g. be something like "<path_to_new_.rosinstall>/ros_data" or
>>> .../ros_temp
>>>
>>> I am not sure whether there are useful cases for sharing data within the
>>> same ROS_HOME between setups with different ROS_ROOT or different
>>> ROS_PACKAGE_PATH, and whether those would justify keeping a single
>>> default
>>> ROS_HOME, rather than making that an expert option.
>>>
>>> The only risk i see in having individual ROS_HOMEs for individual
>>> rosinstall
>>> environments is that users may collect several such obsolete directories
>>> on
>>> their harddrive over time, taking up space (e.g. for logs) while being
>>> invisible to the current ROS_HOME and thus to tools like rosclean and
>>> roswtf.
>>>
>>> One alternative would be to define a new env variable, e.g. ROS_BINS,
>>> where
>>> binaries should go, while test results and logs would still go to
>>> ROS_HOME,
>>> and let rosinstall manage that new env variable ROS_BINS the way
>>> suggested
>>> above for ROS_HOME.
>>>
>>> cheers,
>>>  Thibault
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users