Is it time to change the default filename from .rosinstall to .wstool?

[jbohren]

Would it be reasonable to change the default config file from .rosinstall to .wstool? The idea is that wstool will still recognize .rosinstall files, but will also process files named .wstool. By default going forward, wstool init would create a .wstool file.

[tkruse]

-1, I see little benefit from it, but it creates confusion. Describe more what benefits you see.

As an example, wstool also consumes oth xyz.rosinstall files from various locations. That commonality indicates a relationship.

[130s]

+1; For beginners, googling about .rosinstall will hit the pages for the tool rosinstall, which could make them confused (at least I was made so).
This can be moderated by clarifying the relationship on rosinstall web pages though.

[jbohren]

@130s

+1; For beginners, googling about .rosinstall will hit the pages for the tool rosinstall, which could make them confused (at least I was made so).
This can be moderated by clarifying the relationship on rosinstall web pages though.

Exactly.

Also, these days people are with me when I tell them about wstool until I mention that it uses the '.rosinstall' extension. Then it brings up questions like "is this installing something?" "How is this different from rosdep install?" "Is this a ROS-specific thing?" Etc.

It wouldn't be hard to have wstool handle two filetypes, and it would clear up a lot of the beginner confusion.

[tkruse]

-0, then. Fair enough, but given the naming changes in the past, a name that is not bound to the tool but to the purpose might be more useful, then.

[jbohren]

Ok so how about (off the to of my head):

• .repos
• .repositories
• .versioned_dirs
• .vcs_dirs
• .vcsdirs
• .vcsd

[tfoote]

-1

I'm not enthusiastic about changing the name just for the sake of changing the name. It's quite disruptive, requires a lot of documentation and support changes, including updating REPs http://www.ros.org/reps/rep-0126.html, wiki, answers.ros.org answers.

I suggest that until we change the format, we keep the name. At that time we can update the documentation for both the new format definition and new name. There will not be ambiguity in searches and support requests.

Explaining that it's reusing a file format from another similar tool is not that hard.

[wjwwood]

So, the reason for using .rosinstall is because the contents are specific to rosinstall. I understand the desire to move to something that better reflects the workspace and wstool, but we should keep in mind that the contents remain a rosinstall file. To me this is a bit of a Bike Shed argument, and since any change has cost in engineering time and user disruption, I would -0 it.

In the past we had talked about changing away from the current rosinstall format, but we shied away from that because we didn't want to have to implement and new library which provided the functionality of rosinstall for the new format. Two main reasons for replacing rosinstall:

• As pointed out above, rosinstall neither needs to be ROS specific nor does it install anything, so a better name would be appropriate
• The rosinstall format allows you to specify conflicting local-names
• rosinstall provides functionality which couples it to rosbuild, rosws, and catkin

To the second point, consider this:

- git:
  uri: https://github.com/org/foo.git
  version: master
  local-name: foo
- git:
  uri: https://github.com/fork/foo.git
  version: master
  local-name: foo

If you try to run rosinstall the above, you will have both trying to go into the foo folder locally and rosinstall will just use the second one, ignoring the first. The new format was to be something like this:

foo:
  vcs: git
  url: https://github.com/org/foo.git
  version: master
foo-fork:
  vcs: git
  url: https://github.com/fork/foo.git
  version: master

Because the local name is the key of the dictionary, it naturally prevents this overlap.

Anyways, I said all that to say: I was always thinking that when/if we change the format, then we would change the file name, but not before.

So if we do change it before we change the tool/format then I agree it should be a purpose oriented name.

[jbohren]

Anyways, I said all that to say: I was always thinking that when/if we change the format, then we would change the file name, but not before.

So if we do change it before we change the tool/format then I agree it should be a purpose oriented name.

Ok, I didn't realize there was even a rough plan to fix the issues with the format. It definitely makes sense to wait until that happens.

So I'll close this, and we can track a new format in a new ticket?

[wjwwood]

So I'll close this, and we can track a new format in a new ticket?

Well, I don't know of any timeline to replace rosinstall, and the work involved has delayed action on this thus far.

[tkruse]

The idea of using a different filename was discussed for wstool here:
http://www.ros.org/reps/rep-0133.html#use-a-new-filename-for-wstool

A draft of a different format was discussed once here:
http://ros-users.122217.n3.nabble.com/rosinstall-file-syntax-td3792537.html
Maybe there were some more posts that I cannot find now, i don't remember much else though.

[jbohren]

Well, I don't know of any timeline to replace rosinstall, and the work involved has delayed action on this thus far.

Of course. I'm not saying that anyone does have time. But it's it's something that would be nice, we might as well track it. I'm also not suggesting that rosinstall changes, just that wstool would use an improved format with a different filename.

[tkruse]

rosinstall is now just a thin layer on top of wstool as a library. We do that in order to maintain code only once. So if we introduce new syntax, we introduce it for both.

[jbohren]

So @dirk-thomas ... https://github.com/dirk-thomas/vcstool ?

[tkruse]

vcstool is an alternative to rosinstall/wstool that does not support rosmake (no central file from which to produce a ROS_PACKAGE_PATH, or a setup.sh). It is viable in combination with catkin.

See https://groups.google.com/d/msg/ros-sig-buildsystem/VqziwxVnmb0/ui_BZ3qy4x4J for some history.

[dirk-thomas]

The technical advantages of vcstool from my point of view:

• does not use any separate file for meta information, information about repositories can not go out-of-sync
• uses a different file format to "export" repository configurations (which does not allow collisions by design), can "import" the same file format (as well as rosinstall files)
• exports allow different "granularity": store specific branch / tag / hash in export file

The advantages from a user point of view:

• operates on any filesystem hierarchy
• has some advanced option like vcs log --limit-untagged
• allows running arbitrary commands on a set of repositories (see vcs custom)
• is a very thin wrapper around the native tools and does not perform any magic and therefore no surprises

There are certainly features in wstool / rosinstall which vcstool does not cover but for my personal use I never use those tools and therefore can't comment on them.

[jayvdb]

Why not add support for .wstool as the default, and fall back to .rosinstall.

For extra sanity, if both exist, check they are identical, and fail if they are not.

[dirk-thomas]

Closing since the repository is about to be archived: see #154.