Bugzilla Bug 192505

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