[ros-users] 'stackless' packages

Ken Conley kwc at willowgarage.com
Wed Feb 9 22:55:11 UTC 2011


On Wed, Feb 9, 2011 at 2:40 PM, Patrick Bouffard
<bouffard at eecs.berkeley.edu> wrote:
> Thanks Ken. I think your response should be tagged with #stacks,
> #packages, #designdecisions, and #guru. :)
>
> Is there more info on what 'unary stacks' will look like, beyond the
> one mailing list thread? And do you have a recommendation for my
> current quandary? I'm still leaning towards stackless packages, at
> least for right now.

Unary stacks will probably be as simple as having a stack.xml file and
manifest.xml file in the same directory, but we haven't had a chance
to spin up a prototype to see what the effect on tools would be.

Unfortunately I don't have a solution for you now, and I understand
your pain -- we feel on our side as well.  The ROS stack separation
was simply too much strain on us in this cycle to put in one more
thing like this.

cheers,
Ken

>
> Pat
>
> On Wed, Feb 9, 2011 at 1:33 PM, Ken Conley <kwc at willowgarage.com> wrote:
>> Hi Patrick,
>>
>> Thanks for your thoughts.  We are planning to address this with unary stacks.
>>
>> A lot has been said back and forth about relationships to debian
>> packages, how stacks evidence themselves in the runtime system, etc...
>> and I think it's worth clarifying the intent of stacks.
>>
>> Stacks != collection of packages
>>
>> Stacks = installation information for code
>>
>> This is, intentionally, stacks do not evidence themselves in the
>> runtime system, and, similarly, packages do not evidence themselves in
>> the installation system.  This maintains a separation of concerns.
>>
>> Ideally, stacks exist at the boundary of coupling between various
>> libraries.  This is related to our commitment to maintain
>> backwards-compatibility between releases.  If several packages are
>> grouped in a package together, then they can move their coupled APIs
>> together in lockstep.  If they exist in separate, installable units,
>> one may have to take additional steps to make these API modifications
>> as you increase the configuration space of the install (i.e. a user
>> may install the update for one library, but not the other).
>>
>> Finally, the debians are not the reason that stacks exist, they are
>> merely a by-product of releasing a stack.  The release of a stack
>> actually kills many birds with one stone:
>>
>>  * It creates a versioned source tarball of the stack
>>  * It records information about which version of a stack works with
>> which ROS distribution
>>  * It provides information about how the source control for the code
>> is organized (branches/tags/etc...)
>>
>> This information is consumed by multiple systems:
>>
>>  * our documentation infrastructure
>>  * our indexing infrastructure
>>  * our debian build system
>>  * our continuous integration (testing) infrastructure
>>  * rosinstall/roslocate
>>
>> In the future, this would hopefully feed into other build
>> infrastructures, like macports, yum, etc...
>>
>> regards,
>> Ken
>>
>>
>> On Wed, Feb 9, 2011 at 11:32 AM, Patrick Bouffard
>> <bouffard at eecs.berkeley.edu> wrote:
>>> I have a slight sense of deja-vu posting this so apologies if this has
>>> already been discussed at length--though if so, I wasn't able to find
>>> it (looking forward to the stackoverflow-type answers system.. :)
>>>
>>> I'm planning to do some restructuring of the packages and stacks in
>>> starmac-ros-pkg in order to fix what I like to call my "Bug #1" [1].
>>> At the moment there are two main offenders: packages dealing with the
>>> AscTec Pelican hardware and packages dealing with the Kinect. I don't
>>> want these to be mixed in with the starmac_flyer stack, which should
>>> ideally be completely hardware-setup agnostic and only contain core
>>> stuff common to flying any quadrotor with any sort of additional
>>> sensing.
>>>
>>> The thing is, in doing this I keep coming to the point where I am
>>> faced with creating new stacks that have only one package in them,
>>> which makes me wonder whether the stack is really needed at all. Near
>>> as I can tell, stacks don't really 'exist' at runtime, as far as ROS
>>> is concerned. That is, at runtime, either in launch files or at the
>>> rosrun commandline, only packages are ever referred to, not stacks. In
>>> fact even at compile time, package names come up a lot, in C++
>>> #include and Python import statements, but I can't think of a case
>>> where one has to refer to a stack. The only time I ever refer to a
>>> stack by name is as an argument to rosmake, and then it's really just
>>> shorthand for "rosmake package_a package_b package_c", where those
>>> packages are the ones that are contained in the specified stack.
>>> Perhaps there are other cases that I just haven't come across, if so
>>> I'm sure someone will point this out..
>>>
>>> But otherwise, is it therefore fair to say that stacks are purely a
>>> means of collecting packages together? I understand that in general
>>> the rule of thumb is that when debian packages are built, they
>>> correspond 1:1 to ROS stacks. But is that actually a necessity or just
>>> convention? Either way, does it matter if I don't have immediate plans
>>> to make debian packages?
>>>
>>> So it seems to me that there may be some cases where it doesn't make
>>> sense to place a package within a stack at all. For example, I might
>>> have a 'starmac_kinect' package, which one would only want to install
>>> if using a kinect. I might also have, say, 'starmac_hokuyo' which
>>> would have some functional similarity to starmac_kinect, but one would
>>> also only want to install when using a Hokuyo LRF. Putting them
>>> together in a stack would imply that they would always be installed
>>> together and this would be problematic since such a stack (say
>>> 'starmac_sensors') would then have to depend on the union of the
>>> stacks needed for both of the packages.
>>>
>>> What would seem more sensible to me is to keep the starmac_kinect and
>>> starmac_hokuyo packages together in a 'starmac_sensors' directory, but
>>> not make that directory a stack.
>>>
>>> Another similar problem occurs in what is now the 'starmac_demos'
>>> stack -- as we add more demos, the dependencies of that stack will
>>> grow to include the union of all the stack dependencies of all the
>>> enclosed packages--which doesn't make sense as usually one will only
>>> be interested in particular demo, not all of them (and all their
>>> dependencies)!
>>>
>>> So my question is what are the downsides, if any, with the stackless
>>> package approach I've described?
>>>
>>> Thanks,
>>> Pat
>>>
>>> [1] https://bugs.launchpad.net/starmac-ros-pkg/+bug/706079
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



More information about the ros-users mailing list