Re: [gentoo-python] Re: [PATCH eselect-python 1/2] Store per-version interpreter preference in a file as well.

[Michał Górny]

On Thu, 1 Nov 2012 15:42:42 -0700
Brian Harring <ferringb@×××××.com> wrote:

> On Thu, Nov 01, 2012 at 10:27:19PM +0100, Micha?? G??rny wrote:
> > On Thu, 1 Nov 2012 14:48:55 -0400
> > Mike Gilbert <floppym@g.o> wrote:
> >
> > > On Thu, Nov 1, 2012 at 11:44 AM, Mike Gilbert <floppymaster@×××××.com> wrote:
> > > > On Thu, Nov 1, 2012 at 7:54 AM, Micha?? G??rny <mgorny@g.o> wrote:
> > > >> The idea is very simple: /etc/env.d/python/python[23] with a one-line
> > > >> value similar to the main interpreter /config file.
> > > >>
> > > >> That should be simpler & more reliable than reading a symlink. And at
> > > >> some point we can replace the symlink with an $EPYTHON-aware wrapper
> > > >> as well.
> > > >
> > > > I don't understand the point of this. Do we have some need to enable
> > > > EPYTHON usages for scripts that have a python2 or python3 shebang?
> > > >
> > > > I also don't understand how a text file is more reliable than a
> > > > symlink; they are basically the same thing, but the symlink has a
> > > > different file mode.
> >
> > Ah, and I'd forget. I have the following dream:
> >
> >   /etc/env.d/python/python2
> >   /etc/env.d/python/python3
> >   /etc/env.d/python/config -> python2
> >
> > So, python{2,3} keep the per-version interpreters, and config is just
> > a symlink to one of them. Two bird with one stone -- readlink to get
> > which group is enabled, cat to get the exact interpreter. I'm proud
> > of myself!
>
> I too have a dream; git://pkgcore.org/eslect-python .
>
> That's a shebang based version of what I proposed a while back.  It
> works now and has tests.  It's written to be basically a drop in for
> existing python.eclass generation of shebangs, w/ the
> hardlinking/de-duplication/farking-fast/fix python3.2
> /usr/bin/sphinx-build scenario.

Could you please provide an explanation of what it does? I mean, a few
points of what happens when you run it in various scenarios. That's 600
lines of C code, I think Python folks would appreciate not having to
read that line by line.

> The remaining work for that is thus:
>
> 1) If the EPYTHON targets aren't given via shebang arg, then it needs
>  to fallback to grabbing the targets from the file (easy enough).
>
> 2) Add a few helpers/wrappers to make it easier to do the
> deduplication/shebang rewriting.

How would you perform deduplication while you're at it? Could you
measure or at least consider the benefits of it?

> Frankly, you should be looking at this imo, rather than trying
> standalone files.  Yes, files is simpler- but you'll wind up sooner or
> later rebuilding it into what I already built out here.

I think you are missing the point I'm raising here. Mostly because your
python-wrapper doesn't handle per-version preferences like python-exec
does, unless I'm missing something.

> """
> Add a python-shebang utility, slave python-wrapper to it.
>
> Going forward, the intent is to push the PYTHON_ABIs of a given
> script down into it's shebang, pointing the shebang at python-shebang.
>
> In this way, all known/supported abi's are available at the time of
> execution; further, if the target is told to respect-EPYTHON (meaning
> no searching for something to execute, either active python version or
> EPYTHON var), we can push this down into that list and have that code
> handle it.
>
> [...]
>
> to the simpler form of:
> for x in sphinx{,-{2.7,3.2}}; do echo > $x <<EOF
> #!/usr/bin/python-shebang python2.7,python3.2
> <code>
> EOF
> done

Hmm, are you assuming that /usr/bin/sphinx carries the actual code?
Or some special wrapper code?

Not to mention you still bind the whole thing to installed package.
If you need to fix those files, you need to reinstall all packages
installing them.

> The gains of this are thus:

Could you please compare it to the modern solution (python-exec) rather
than the deprecated one? You are no longer on the uncharted waters.

-- 
Best regards,
Michał Górny