[ros-users] 'stackless' packages

Patrick Bouffard bouffard at eecs.berkeley.edu
Thu Feb 10 19:02:01 UTC 2011 

On Thu, Feb 10, 2011 at 10:52 AM, Ken Conley <kwc at willowgarage.com> wrote:
> On Thu, Feb 10, 2011 at 10:41 AM, Patrick Bouffard
> <bouffard at eecs.berkeley.edu> wrote:
>> On Wed, Feb 9, 2011 at 2:55 PM, Ken Conley <kwc at willowgarage.com> wrote:
>>> 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.
>>
>> Don't get me wrong--it's not that painful a problem on my side! :) I
>> just want to avoid creating larger problems than the ones I'm solving.
>>
>> I don't think the fact that unary stacks are not yet implemented is
>> really an issue for me now--the issue is more my ignorance of what
>> exactly are all the implications of having packages in stacks or not.
>>
>> Yesterday, I moved a couple of packages from existing stacks to
>> directories that don't have stacks, and also renamed them in the
>> process.
>>
>> For example,
>> FROM: starmac_flyer(stack)/flyer_kinect(package)
>> TO: starmac_sensors(directory)/starmac_kinect(package)
>>
>> One thing I noticed is that the change doesn't seem to have registered
>> in the ros.org documentation index.
>
> I updated your repo page to use:
>
> <<RepoHeader(starmac-ros-pkg packages)>>
>
> which also lists packages as well.  I see starmac_kinect listed there.

Thanks, I didn't know about that option!

>
>> So is it the case that, without being inside a stack, a package in my
>> repository will not be indexed on ros.org? If so then that's a very
>> good reason to use a stack.
>>
>> As it stands now, my "bug #1" is essentially fixed in that the
>> extraneous dependencies shouldn't be there anymore. However it seems
>> like the unwanted side effect is now that the online documentation is
>> messed up.
>>
>> The main reason I didn't want to make these new directories (e.g.,
>> starmac_sensors) into stacks has to do with the stack dependencies, as
>> I explained earlier. But I'm thinking that perhaps the best compromise
>> right now is to turn those directories into stacks (is stack.xml all
>> the indexer requires?) but not to declare any stack dependencies. If I
>> did this would the indexer be happy? From what you've said so far it
>> seems like that would be the case so long as I don't try to do a
>> release.
>>
>> Thanks for all the help and sorry that I have to throw these questions
>> at you at such a busy time. When things quiet down a bit one thing
>> that probably would help is to have some documentation on the indexer,
>> since a lot of my questions seemed to essentially boil down to things
>> that the indexer documentation would address.
>>
>> One more thing--it occurs to me that if it were possible to declare
>> "optional" (or perhaps "recommended") stack dependencies, then that
>> would also help in this case. Let me know if this is something I could
>> ticket for consideration.
>
> I'm not sure what optional dependencies would mean from an
> installation point of view. I assume the fact that the indexer is
> working that you don't need this feature?

Correct.

Cheers,
Pat


>
>  - Ken
>
>>
>> Cheers,
>> Pat
>>
>>
>>>
>>> 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
>>>>
>>> _______________________________________________
>>> 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