Re: Request for comment REP 127 / dependency specification

[Jonathan Bohren]

On Mon, Oct 15, 2012 at 10:31 AM, tkruse <tibo...@googlemail.com> wrote:

Also, now that the current REP127 version has materialized in the source, it seems to force to give a lot of redundant information such as:
  <build_depend>catkin</build_depend>
  <build_depend>cpp_common</build_depend>
  <run_depend>cpp_common</run_depend>
That a catkin package depends on catkin for build should be implicit, and having to specify build+run dependencies like cpp_common twice also looks bad to me. As an example, in actionlib.package.xml or roscpp/package.xml, this causes a long list of entries making it difficult to find duplictate, missing or obsolete entries.

Also it's still not clear to me why we're not using the less verbose schema closer to:

<depend pkg="cpp_common" build="true" run="true"/>

--

Jonathan Bohren

PhD Student

Dynamical Systems and Control Laboratory

Laboratory for Computational Sensing and Robotics

The Johns Hopkins University

(707) 520-4736

j...@jhu.edu

[Dirk Thomas]

On 15.10.2012 07:49, Jonathan Bohren wrote:

> On Mon, Oct 15, 2012 at 10:31 AM, tkruse <tibo...@googlemail.com <mailto:tibo...@googlemail.com>> wrote:
>
> Also, now that the current REP127 version has materialized in the source, it seems to force to give a lot of redundant information such as:
> <build_depend>catkin</build_depend>
> <build_depend>cpp_common</build_depend>
> <run_depend>cpp_common</run_depend>
> That a catkin package depends on catkin for build should be implicit, and having to specify build+run dependencies like cpp_common twice also looks bad to me. As an example, in
> actionlib.package.xml or roscpp/package.xml, this causes a long list of entries making it difficult to find duplictate, missing or obsolete entries.
>
>
> Also it's still not clear to me why we're not using the less verbose schema closer to:
>
> <depend pkg="cpp_common" build="true" run="true"/>

This has been proposed and discussed before on this mailing list and the majority of people decided that these attributes are not a preferred/desired solution.

In the same discussion it was also agreed on that being more explicit (having separate build and run dependencies) is preferred over a joined tag combining both.

- Dirk

[Jack O'Quin]

I was one who recommended separate build and run dependencies.

Now I wonder if that was a mistake. I was mostly thinking in terms of
Debian packages, which have clear divisions along those lines. I
failed to think of a legitimate example of the need for both.

Existing ROS packages, however, frequently merge the two, combining
headers (build-dependencies) and libraries (run-dependencies) in the
same ROS package. So, the combined case is probably much more common
than I realized. Combining them in a single ROS package clearly makes
sense, just as it does for upstream Debian source tarballs.

So, now I wonder:

* When will the packaging system allow dividing a single ROS package
into separate Debian or other run-time and build dependencies?

* How should the `package.xml` refer to those separate Debian package
names? At that point, they really will be independent and should be
listed separately.
--
joq

[Jonathan Bohren]

On Mon, Oct 15, 2012 at 1:47 PM, Dirk Thomas <dth...@willowgarage.com> wrote:

This has been proposed and discussed before on this mailing list and the majority of people decided that these attributes are not a preferred/desired solution.

I think I missed this discussion, and I can't find it in the google group search. What were the pros/cons? I was also looking at some migrated packages/stacks and it looks verbose and really hard to read since there aren't any spaces surrounding the package names.

-j

[tkruse]

Discussion in these posts:
https://groups.google.com/d/msg/ros-sig-buildsystem/_jRvhXFfsVk/QxPm3ouS5UQJ
Thibault:

"* The structure depends, run_depends, build_depends is not future proof, more scopes might become relevant
* Also the depends semantics should be clarified, what effect will it have if I put <depends>xyz</depends> in the package.xml?"

https://groups.google.com/d/msg/ros-sig-buildsystem/_jRvhXFfsVk/omvNL2EX1RAJ
Damon:

The more Maven-esque way to form the example from the REP
would be:

<package>
  ...
  <dependencies>
    <depends scope="compile">libboost-

thread-dev</depends>
    <depends scope="run">libboost-thread</depends>
    <depends scope="test">libgtest-dev</depends>
  <dependencies>
</package>

To make it more compact, the compile scope could be considered the default.

https://groups.google.com/d/msg/ros-sig-buildsystem/_jRvhXFfsVk/5Gld9AqqB-IJ
Dirk (to Damon):
I like that idea.
One minor thing: I would consider to choose an other default.
Most of our dependencies are "build" and "run", so I would propose to use both when no scope is specified.

https://groups.google.com/d/msg/ros-sig-buildsystem/_jRvhXFfsVk/NLaKQHj42asJ
William:

I like Damon's suggestion of having just <depends> but having an optional scope attribute.

https://groups.google.com/d/msg/ros-sig-buildsystem/_jRvhXFfsVk/CItG36S6-GEJ
Jack:

<depend>:
========

I like the improved flexibility of this section.

But the proposed syntax is ugly, even by XML standards. Surely there
is a better representation. I thought the original proposal with
nested dependency tags was cleaner. Using empty attributes rather than
tags seems confusing and error-prone for users.

I disagree with both "build" and "run" being the default attribute. I
would be astonished if that were the "most common use case". Surely
"run" is the most common?
...

https://groups.google.com/d/msg/ros-sig-buildsystem/_jRvhXFfsVk/skA6WiG2ubIJ
Thibault:

For dependency versions, I would prefer "version=..." instead of version_gte, and version_exact instead or version_eq.
I am not sure whether version_lte or version_gt are useful options. Would the following be insufficient:

<build_depend version="1.1">...</build_depend>

<build_depend version="1.1" version_lower_than="2.1">...</build_depend>
<build_depend version_exact="1.1">...</build_depend>

I think that's about it, for me it is difficult to tell whether any consent or majority vote was ever reached, or whether the current REP represents that consent.

[Jonathan Bohren]

It sounds like Dirk's suggestion of having a tag <depends> without build or run specification could be a solution to the verbosity of having to describe packages that are both build and run deps.

Also, I don't see any justification here for the attributeless schema. Why are we making it so dramatically different from the dependency schema in rosbuild manifests?

--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To unsubscribe from this group, send email to ros-sig-buildsy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/ros-sig-buildsystem/-/h6WxDR4FeyEJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[tkruse]

You mean, instead of
  <build_depend>actionlib_msgs</build_depend>
  <build_depend>boost</build_depend>
  <build_depend>catkin</build_depend>
we could go back to
  <build_depend name="actionlib_msgs" />
  <build_depend name="boost" />
  <build_depend name="catkin" />

Or even
  <build_depend name="actionlib_msgs boost catkin"/>

The justification is that XML standard usage is using tag values for content, and attributes for metadata. Whether this is good or not is a dilemma as old as XML, see http://www.ibm.com/developerworks/xml/library/x-eleatt/index.html

I agree that in just the 3 lines above, the attribute notation is easier on the eye for me.
However you also have to compare this to the versioned dependency notation (which seems not to be used yet):

  <build_depend version_gte="1.1" version_lt="2.0">actionlib_msgs</build_depend>
  <build_depend version_gte="1.3">boost</build_depend>
  <build_depend version_gte="0.5" version_lt="0.6">catkin</build_depend>

vs.

  <build_depend version_gte="1.1" version_lt="2.0" name="actionlib_msgs" />
  <build_depend version_gte="1.3" name="boost" />
  <build_depend version_gte="0.5" version_lt="0.6" name="catkin" />

Maybe with this, the element notation has a slight advantage. In particular since the attribute order may be jumbled for auto-generated output.

[Jonathan Bohren]

On Oct 17, 2012 5:44 AM, "tkruse" <tibo...@googlemail.com> wrote:
>
> You mean, instead of
>   <build_depend>actionlib_msgs</build_depend>
>   <build_depend>boost</build_depend>
>   <build_depend>catkin</build_depend>
> we could go back to
>   <build_depend name="actionlib_msgs" />
>   <build_depend name="boost" />
>   <build_depend name="catkin" />
>
> Or even
>   <build_depend name="actionlib_msgs boost catkin"/>
>
> The justification is that XML standard usage is using tag values for content, and attributes for metadata. Whether this is good or not is a dilemma as old as XML, see http://www.ibm.com/developerworks/xml/library/x-eleatt/index.html

Well this document does literally say " On the other hand: If the information is expressed as an atomic token, use attributes. "

When I see elements in an XML schema, it doesn't feel as solid as putting something in a qouted string. It looks like there can be other sub-elements.

>
> I agree that in just the 3 lines above, the attribute notation is easier on the eye for me.
> However you also have to compare this to the versioned dependency notation (which seems not to be used yet):
>
>   <build_depend version_gte="1.1" version_lt="2.0">actionlib_msgs</build_depend>
>   <build_depend version_gte="1.3">boost</build_depend>
>   <build_depend version_gte="0.5" version_lt="0.6">catkin</build_depend>
>
> vs.
>
>   <build_depend version_gte="1.1" version_lt="2.0" name="actionlib_msgs" />
>   <build_depend version_gte="1.3" name="boost" />
>   <build_depend version_gte="0.5" version_lt="0.6" name="catkin" />
>
> Maybe with this, the element notation has a slight advantage. In particular since the attribute order may be jumbled for auto-generated output.
>

So why not:

<build_depend name="actionlib_msgs" >
<version gte="1.1" lt="2.0"/>
</build_depend>

This also gives us room to put more extensible information about a given dep.

[tkruse]

On Wednesday, October 17, 2012 11:57:21 AM UTC+2, Jonathan Bohren wrote:

So why not:

<build_depend name="actionlib_msgs" >
<version gte="1.1" lt="2.0"/>
</build_depend>

This also gives us room to put more extensible information about a given dep.

Let's compare small blocks of several elements, as readability only becomes an issue then.

<build_depend version_gte="1.1" version_lt="2.0">actionlib_msgs</build_depend>

<build_depend version_gte="1.3">boost</build_depend>
<build_depend version_gte="0.5" version_lt="0.6">catkin</build_depend>

vs

<build_depend name="actionlib_msgs" >
  <version gte="1.1" lt="2.0"/>
</build_depend>

<build_depend name="boost" >
  <version gte="1.3"/>
</build_depend>
<build_depend name="catkin">
  <version gte="0.5" lt="0.6">
</build_depend>

or

<build_depend name="actionlib_msgs" ><version gte="1.1" lt="2.0"/></build_depend>

<build_depend name="boost" ><version gte="1.3"/></build_depend>
<build_depend name="catkin"><version gte="0.5" lt="0.6"></build_depend>

Your idea is unusual, but I think it may work well for readability, especially since we do not know how many people will ever use versioned dependencies.

[Tully Foote]

Hi, 

There was discussion of the scoping in the middle of September in the this thread (ReRequest for comment REP 127).   The last comment I find relating to tags vs attributes is here [1] and it stated that XML was verbose and the difference was not a big deal  After that the discussion moved onto other topics and the existing proposal stayed as written.  At this point we have 240+ packages building in groovy with the spec as written and discussed.  As much as we can optimize the number of characters and subjective readability it's going to be verbose either way.  

At this point I suggest that unless someone has a compelling reason that the existing standard is not technically adequate that we not continue discussing the xml format of the dependency tags.  There are lots of other things which can use attention in our push to get groovy (beta) out the door this week.  

Tully

[1] https://groups.google.com/d/msg/ros-sig-buildsystem/_jRvhXFfsVk/QZJe5zMS8g8J

--

You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To unsubscribe from this group, send email to ros-sig-buildsy...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/ros-sig-buildsystem/-/go7RwV0_OhEJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Tully Foote
tfo...@willowgarage.com
(650) 475-2827