Since I did not get any replies to my email to -dev I presume there is no "standard" way to deal with the code that is common to eclasses (ebuilds) and eselect modules. (If there is, please just point me towards some descrition, I could not find any). Here is the situation: I have some vars and code that is shared among gnatbuild.eclass, gnat.eclass and gnat.eselect module. Right now most of it is in the eselect module that gets sourced by gnat.eclass (after minor cleanup) with a var or two duplicated in gnatbuild.eclass. I would like to organize this a bit better, now that iternals have largerly stabilized. The trivial way would be to split common code off into some file and just source it where proper. The most straightforward approach seems to be to provide another eclass - some gnat-common.eclass and then inherit it in gnatbuild.eclass and gnat.eclass and source it from eselect module. The good about with this approach is that it is guaranteed to be there for other eclasses to use and does not depend on the eselect module being installed. The bad is that, with it being an eclass one would expect the usual ability to override it by putting new version under PORTAGE_TMPDIR. While this would be handled naturally for the eclasses, this search and identify functionality will have to be added to the eselect module, which is at least boring :), but more seriously, this should be supported by eselect framework, not individual modules. So, since the eselect modules have this ability to "inherit" stuff that is defined under libs/ it only makes sense to add the function that would perform this search and sourcing to one of the scripts, and package-manager.bash seems to be the most relevant. What do you think? George
I think no. This ties eselect much too closely to the package manager, and requires it to know far too much about package manager internals. eselect needs to work even when the package manager is h0rked. There are also environment issues. The eselect environment isn't particularly similar to the ebuild environment. Things that work in one don't work in the other, or work differently (for example, 'inherit' isn't available to eselect, and 'die' does different things).
This is why I propose to provide this as a function in "extra module", besides the one that is already tied to package manager and not as a "central feature" (to cite the eselect dev guide: "To use any of the other functions, you have to first inherit the corresponding library file."). This will not tie eselect and active package manager themselves but rather will allow one to tie a particular eclass and a particular eselect module where necessary. Otherwise, how should I provide shared code? Having it duplicated *will* lead to broken packages and so is potentially worse than having some scheme marginally tying eselect modules end eclasses as optional functionality. BTW, we already have portage.bash, paludis.bash and package-manager.bash installed as part of eselect, doing things similar to what I described. I merely propose to extend the most relevant module with one more function. George
(In reply to comment #2) > This will not tie eselect and active package manager themselves but rather > will allow one to tie a particular eclass and a particular eselect module > where necessary. Otherwise, how should I provide shared code? Having it > duplicated *will* lead to broken packages and so is potentially worse than > having some scheme marginally tying eselect modules end eclasses as optional > functionality. Ok, to put it more bluntly: You can't share code between eselect modules and ebuilds because they're executed under what is in effect two different languages. Ebuilds use bash with various options changed and a particular common set of functions; eselect moduels use bash with various different options changed and a different particular common set of functions, some of which clash with those in the ebuild environment. The use of 'inherit' as a name implies is perhaps unfortunate. Whilst eselect modules were designed to be conceptually somewhat like ebuilds, from an execution perspective they are very different. As a simple example, consider EXPORT_FUNCTIONS -- it's required for supporting an eclass and is part of the ebuild 'language', but does not exist and cannot exist sensibly for eselect modules. You may think you can restrict yourself to commonly-implemented functionality in shared code. This only works in the extremely trivial case, however, and the extremely trivial case is insufficient for real world use. It would be far too easy for someone to make a change to the eclass without realising that that change would break eselect. There is the additional issue that eselect cannot depend upon having a working package manager or a correct user package manager configuration. The assumption that eselect will have access to the gentoo-x86 tree is invalid. > BTW, we already have portage.bash, paludis.bash and package-manager.bash > installed as part of eselect, doing things similar to what I described. I > merely propose to extend the most relevant module with one more function. There's a big difference between wrapping a few API calls and expecting code to work in a common environment. Really package-manager.bash shouldn't exist at all, but it's there because it simplifies some common use cases... The only sensible solution here is to have two lots of code. Not the same code in two places, because ebuilds and eselect modules use a different 'language', but two independent sets of code.
(In reply to comment #3) >The assumption > that eselect will have access to the gentoo-x86 tree is invalid. Ok, that's a key point. > The only sensible solution here is to have two lots of code. Not the same code > in two places, because ebuilds and eselect modules use a different 'language', > but two independent sets of code. Well, it *is* the same code and I am not duplicating it. Duplicating will create problems down the line with more certainity (even I (the maintainer and creator of the code) would fail to remember details when trying to address some problem after not looking at the code a few month later). "Two lots of similar code" are there as well, just using some core functions, plus some dressing of eselect and eclass particulars. It is those core functions that pose the problem. The code is exactly like that - restricted to basic functions for core actions. Now I just want to organize it a bit better - inheriting the whole eselect module does not feel good when I need only one major function and few supporting ones. These can be split into a separate "container" written in a simple bash and "guarded" with a comment that no extentions to bash are allowed. The question I have is where to put this? Unfortunately there does not seem to be a guaranteed place, so perhaps just a separate file in eselect-gnat would be better then.. Yes, theoreticaly this does not feel good - but looks like this is better than the other way around in the view of above comment that eselect cannot depend on portage tree being present. All of the gnat related stuff can depend on eselect-gnat being present, provided users use some sensible package manager. And if not, that's their fault. (Oh, and that core stuff is sources in eclass only inside functions, not at the top level, so the validity can be verified and things can degrade gracefully in case the eselect-gnat installation failed (which is errorneous situation in itself. No other installation could proceed then anyway.)). Closing this bug then. George
for tracking purposes.
Messed up dependencies on bugs last time a bit (this one is more relevant).
