[ros-users] ROS_HOME and rosinstall

[Thibault Kruse]

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.

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