Re: [ros-users] ROS_HOME and rosinstall

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: User discussions
Date:  
To: User discussions
Subject: Re: [ros-users] ROS_HOME and rosinstall
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 <> 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
>
> https://code.ros.org/mailman/listinfo/ros-users