On 29/02/12 20:51, Alexandre Rostovtsev wrote: > On Tue, 2012-02-28 at 22:13 +0100, Krzysztof Pawlik wrote: >> Hello, >> >> After some work during weekend on Python packages I've decided to start a >> rewrite of Python/distutils eclass for installing Python packages. My main >> goal >> was simplicity and functionality similar to ruby-ng.eclass (thanks Ruby team >> for >> your great work!). Python team members already contributed comments and >> suggestions and helped me to make the eclass better, thank you! >> >> Highlights: >> - *SIMPLE*next >> - uses PYTHON_TARGETS use-expand (no more python-updater, whoooo!) >> - EAPI4 required, uses REQUIRED_USE >> - <400 lines of code including documentation >> - should work for >95% of packages (my educated guess) >> - did I mention it's *SIMPLE*? >> - easy to maintain & read so it's also easy to use >> >> Important thing: I'm not aiming at having 100% functionality of current >> python.eclass+distutils.eclass in the new one, I think that simplicity is >> more >> important that supporting every possible, obscure case that's out there. >> >> I'm attaching the eclass itself and two ebuilds using it, code is also >> available >> in my overlay at >> http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary >> >> If there are no objections then during the weekend (March 3, 4) I will add >> this >> to portage (after finishing remaining TODO items, PyPy requires 4G of >> RAM(!!)). > > The proposed eclass omits three features from python.eclass which are > heavily used in the gnome stack.
Correct me if I'm wrong, but Gnome doesn't use standard distutils?
Regardless of this eclass you can still use python.eclass, it not going anywhere
anytime soon (just like I wrote in one of previous e-mails).
> First, it does not set EPYTHON, which is a problem for the many packages
> whose build systems execute /usr/bin/python and assume that it's a
> generic python2 or the same version of python2.x for which the package
> is being built.
Setting EPYTHON is not a problem -- just another variable.
> Second, there doesn't seem to be any support for packages that do not
> install in python's site-packages and do not allow multiple python ABIs.
> If I have, for example, a package that installs python modules
> in /usr/lib/appname or /usr/share/appname, how can I specify that
> PYTHON_TARGETS="python2.6" or "python2.7" or "python3.2" is allowed, but
> something like PYTHON_TARGETS="python2.7 python3.2" is not?
You're correct, note that I've stressed that this eclass is mainly for
distutils-based packages. I'm not using Gnome, so can you provide some package
examples that I can look at?
<personal opinion>
If package decides to use given language then please, please play by the rules
set by the rest of world (Ruby -> gems, Python -> distutils, Perl -> CPAN, PHP
-> PEAR).
I don't like installing Python code outside of site-packages, the only exception
to that rule is portage (at least for now).
</personal opinion>
> Third, python-distutils-ng_doscript() installs only one file at a time
> (no built-in support for multiple files at a time or for recursing
> through a directory tree),
Yes, that why bash has `for' loop ;)
> installs it only in /usr/bin (a package might
> want it in e.g. /usr/libexec or /usr/share/appname/scripts)
Yes, I might add --destdir (or something like that) later on.
> and always
> creates scriptname-IMPLEMENTATION (polluting tab-completion in /usr/bin
> for the common case of programs that do not support multiple python
> ABIs). As a result, it is far less useful than python.eclass's
> python_convert_shebangs().
Yes, that "pollutes" this name space, but I'm not buying this argument. Do you
know how CVS and .svn "pollute" my tab-completion list? I even set FIGNORE so I
can live with it.
I'd be happy to hear how to solve this - what prefix or suffix to use? One way
would be quite trivial: if only one implementation is enabled do not create
script-${impl}, go with single file, does that sound good?
--
Krzysztof Pawlik <nelchael at gentoo.org> key id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
