On Thu, Feb 2, 2012 at 2:57 PM, Thibault Kruse 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  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/  in the setup.sh. >>> >>> Else, rosinstall could specify a specific subdirectory for the given >>> rosinstall location. >>> That could e.g. be something like "/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@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users