On Thu, Feb 10, 2011 at 10:52 AM, Ken Conley wrote: > On Thu, Feb 10, 2011 at 10:41 AM, Patrick Bouffard > wrote: >> On Wed, Feb 9, 2011 at 2:55 PM, Ken Conley 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: > > <> > > 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 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 >>>>> 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@code.ros.org >>>>>> https://code.ros.org/mailman/listinfo/ros-users >>>>>> >>>>> _______________________________________________ >>>>> ros-users mailing list >>>>> ros-users@code.ros.org >>>>> https://code.ros.org/mailman/listinfo/ros-users >>>>> >>>> _______________________________________________ >>>> ros-users mailing list >>>> ros-users@code.ros.org >>>> https://code.ros.org/mailman/listinfo/ros-users >>>> >>> _______________________________________________ >>> ros-users mailing list >>> ros-users@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >>> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >