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