[ros-users] 'stackless' packages

[Ken Conley]

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.

> 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?

 - 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
>