Gentoo Archives: gentoo-dev

From: Krzysztof Pawlik <nelchael@g.o>
To: gentoo-dev@l.g.o
Cc: Alexandre Rostovtsev <tetromino@g.o>
Subject: Re: [gentoo-dev] New eclass for Python
Date: Wed, 29 Feb 2012 20:25:38
Message-Id: 4F4E8991.8040907@gentoo.org
In Reply to: Re: [gentoo-dev] New eclass for Python by Alexandre Rostovtsev
1 On 29/02/12 20:51, Alexandre Rostovtsev wrote:
2 > On Tue, 2012-02-28 at 22:13 +0100, Krzysztof Pawlik wrote:
3 >> Hello,
4 >>
5 >> After some work during weekend on Python packages I've decided to start a
6 >> rewrite of Python/distutils eclass for installing Python packages. My main goal
7 >> was simplicity and functionality similar to ruby-ng.eclass (thanks Ruby team for
8 >> your great work!). Python team members already contributed comments and
9 >> suggestions and helped me to make the eclass better, thank you!
10 >>
11 >> Highlights:
12 >> - *SIMPLE*next
13 >> - uses PYTHON_TARGETS use-expand (no more python-updater, whoooo!)
14 >> - EAPI4 required, uses REQUIRED_USE
15 >> - <400 lines of code including documentation
16 >> - should work for >95% of packages (my educated guess)
17 >> - did I mention it's *SIMPLE*?
18 >> - easy to maintain & read so it's also easy to use
19 >>
20 >> Important thing: I'm not aiming at having 100% functionality of current
21 >> python.eclass+distutils.eclass in the new one, I think that simplicity is more
22 >> important that supporting every possible, obscure case that's out there.
23 >>
24 >> I'm attaching the eclass itself and two ebuilds using it, code is also available
25 >> in my overlay at http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary
26 >>
27 >> If there are no objections then during the weekend (March 3, 4) I will add this
28 >> to portage (after finishing remaining TODO items, PyPy requires 4G of RAM(!!)).
29 >
30 > The proposed eclass omits three features from python.eclass which are
31 > heavily used in the gnome stack.
32
33 Correct me if I'm wrong, but Gnome doesn't use standard distutils?
34
35 Regardless of this eclass you can still use python.eclass, it not going anywhere
36 anytime soon (just like I wrote in one of previous e-mails).
37
38 > First, it does not set EPYTHON, which is a problem for the many packages
39 > whose build systems execute /usr/bin/python and assume that it's a
40 > generic python2 or the same version of python2.x for which the package
41 > is being built.
42
43 Setting EPYTHON is not a problem -- just another variable.
44
45 > Second, there doesn't seem to be any support for packages that do not
46 > install in python's site-packages and do not allow multiple python ABIs.
47 > If I have, for example, a package that installs python modules
48 > in /usr/lib/appname or /usr/share/appname, how can I specify that
49 > PYTHON_TARGETS="python2.6" or "python2.7" or "python3.2" is allowed, but
50 > something like PYTHON_TARGETS="python2.7 python3.2" is not?
51
52 You're correct, note that I've stressed that this eclass is mainly for
53 distutils-based packages. I'm not using Gnome, so can you provide some package
54 examples that I can look at?
55
56 <personal opinion>
57 If package decides to use given language then please, please play by the rules
58 set by the rest of world (Ruby -> gems, Python -> distutils, Perl -> CPAN, PHP
59 -> PEAR).
60
61 I don't like installing Python code outside of site-packages, the only exception
62 to that rule is portage (at least for now).
63 </personal opinion>
64
65 > Third, python-distutils-ng_doscript() installs only one file at a time
66 > (no built-in support for multiple files at a time or for recursing
67 > through a directory tree),
68
69 Yes, that why bash has `for' loop ;)
70
71 > installs it only in /usr/bin (a package might
72 > want it in e.g. /usr/libexec or /usr/share/appname/scripts)
73
74 Yes, I might add --destdir (or something like that) later on.
75
76 > and always
77 > creates scriptname-IMPLEMENTATION (polluting tab-completion in /usr/bin
78 > for the common case of programs that do not support multiple python
79 > ABIs). As a result, it is far less useful than python.eclass's
80 > python_convert_shebangs().
81
82 Yes, that "pollutes" this name space, but I'm not buying this argument. Do you
83 know how CVS and .svn "pollute" my tab-completion list? I even set FIGNORE so I
84 can live with it.
85
86 I'd be happy to hear how to solve this - what prefix or suffix to use? One way
87 would be quite trivial: if only one implementation is enabled do not create
88 script-${impl}, go with single file, does that sound good?
89
90 --
91 Krzysztof Pawlik <nelchael at gentoo.org> key id: 0xF6A80E46
92 desktop-misc, java, vim, kernel, python, apache...

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] New eclass for Python "Andreas K. Huettel" <dilfridge@g.o>
Re: [gentoo-dev] New eclass for Python Alexandre Rostovtsev <tetromino@g.o>