Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass

[Michał Górny]

On Thu, 25 Oct 2012 20:55:37 +0200
hasufell <hasufell@g.o> wrote:

> On 10/25/2012 07:43 PM, Michał Górny wrote:
> > On Thu, 25 Oct 2012 18:41:47 +0200 hasufell <hasufell@g.o>
> > wrote:
> >
> >> 1. there is still no way to convert shebangs via python-r1
> >
> > What conversion do you expect? The docs say it clearly that the
> > eclass will be extended on request, so please file a clear request
> > what you want with an example use case.
>
> request: A function that converts the shebang to a version specific
> python shebang chosen by me.
>
> usecase: python scripts installed by a non-distutils build system
> which need appropriate shebang conversion (Unless we can fix that in a
> different way.)

That's a fair request. Last thing which I have to think about is
whether we want this in python-r1, or a more general shebang replacement
function in eutils.

> >> 2. there are no equivalent functions to the python_get_* stuff
> >> which are sometimes necessary for broken build systems or test
> >> phases
> >
> > There is python_export(). I will be happy to extend it / add
> > python_get*() wrappers when someone makes a clear list of what is
> > needed.
> >
> > Example use cases will be appreciated again. Good examples will
> > make it possible to choose good variable names.
>
> example:
> x11-misc/redshift-1.7-r1
>
> I'll give more examples as I come across those again. This is much
> "afair".

Sorry, didn't notice the sitedir use.

> >> 3. there is no equivalent for python_mod_optimize. Having that
> >> in distutils-r1 does not suffice for non-distutils packages where
> >> I might have to do that stuff manually.
> >
> > There is a lot of stuff missing for packages which try to install
> > Python stuff by hand rather than using proper setup. I will be
> > happy to provide more when I know what is actually needed and how
> > it will be used.
> >
>
> example:
> x11-misc/redshift-1.7-r1
>
> Again, I'll give more examples as I come across those.

Err, do you expect the eclass to provide a function to restore
the py-compile script you're removing?

> >> 5. distutils-r1_rename_scripts does not allow to specify a
> >> location possibly breaking non-standard locations (e.g. games
> >> location)
> >
> > It's a quick function. Adding additional paths or changing the
> > algorithm won't be hard. Just don't expect me to do random stuff
> > just because someone may want that someday.
> >
> > FYI: I've added that mindless games/bin to the paths.
>
> that games/bin change is not sufficient since the games variables can
> be modified by the user and this is supported by the games eclass. So
> you have to pass an option to the ebuild developer.

User can do many stupid things, and some eclasses are just stupid
and should be killed with fire. A lot of fire. Passing an option is
just inventing a minigun to shot a mosquito.

I will be happy to fix that whenever someone stumbles around that.
If ever. If ever distutils setup.py will actually install anything
to /usr/randomlocation/bin which will be actually supposed to be
rewritten.

> >> 8. how would I manually generate implementation-suffixed scripts
> >> without distutils-r1?
> >
> > You would use the function I would introduce when I got the
> > request filed and potential discussion done. Most importantly,
> > whether there should be a way to call 2to3 on the scripts.
> >
> > By the way, did you just request two partial features instead of
> > requesting a way to manually install Python scripts?

Ok, looking at redshift, I'm not really sure if we really need or even
want to install implementation-suffixed scripts there. That's something
to discuss.

The main reason for implementation-suffixing of scripts is that
distutils can mangle the scripts for various implementations (i.e. 2to3
them). The side reason is ability to force a particular implementation
when no other suitable way is available (which is pretty rare).

To be honest, redshift doesn't fit either. I doubt anyone will really
need to put 'gtk-redshift-python2.6' anywhere, and both scripts will be
identical. So it may be just enough or even better just to mangle
the script to have 'python2' shebang.

> >> example: x11-misc/redshift-1.7-r1
> >
> > Thanks. I will take a look at that package and see what is
> > necessary to make it buildable with python-r1.
> >
> > By the way, do I understand correctly that right now you are
> > building stuff for a random Python implementation and removing it
> > afterwards? I believe that's something really worth fixing.
> >
>
> That way was chosen to avoid an extensive patch I have already
> written. The maintainer of the package did not want to keep that
> around through version bumps which is understandable.

You again fail to see an interim solution which will solve the issue
without much trouble, similar to one used for multilib. You let
the build system work with the default implementation, then repeat
install for remaining implementations.

Of course, right now it's not supported by python-r1. I will think how
to solve it in a simple way.

-- 
Best regards,
Michał Górny