Gentoo Archives: gentoo-python

From: Mike Gilbert <floppym@g.o>
To: Gentoo Dev <gentoo-dev@l.g.o>, gentoo-python@l.g.o
Subject: Re: [gentoo-python] New eclass for Python
Date: Wed, 29 Feb 2012 05:13:34
Message-Id: CAJ0EP41dbDB+AkdOFp0aS2Vtcb_KWRCKvXEjkD1mTYrRXNPR=Q@mail.gmail.com
In Reply to: [gentoo-python] New eclass for Python by Krzysztof Pawlik
1 On Tue, Feb 28, 2012 at 4:13 PM, Krzysztof Pawlik <nelchael@g.o> wrote:
2 > Hello,
3 >
4 > After some work during weekend on Python packages I've decided to start a
5 > rewrite of Python/distutils eclass for installing Python packages. My main goal
6 > was simplicity and functionality similar to ruby-ng.eclass (thanks Ruby team for
7 > your great work!). Python team members already contributed comments and
8 > suggestions and helped me to make the eclass better, thank you!
9 >
10 > Highlights:
11 >  - *SIMPLE*next
12 >  - uses PYTHON_TARGETS use-expand (no more python-updater, whoooo!)
13 >  - EAPI4 required, uses REQUIRED_USE
14 >  - <400 lines of code including documentation
15 >  - should work for >95% of packages (my educated guess)
16 >  - did I mention it's *SIMPLE*?
17 >  - easy to maintain & read so it's also easy to use
18 >
19 > Important thing: I'm not aiming at having 100% functionality of current
20 > python.eclass+distutils.eclass in the new one, I think that simplicity is more
21 > important that supporting every possible, obscure case that's out there.
22 >
23 > I'm attaching the eclass itself and two ebuilds using it, code is also available
24 > in my overlay at http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary
25 >
26 > If there are no objections then during the weekend (March 3, 4) I will add this
27 > to portage (after finishing remaining TODO items, PyPy requires 4G of RAM(!!)).
28 >
29 > --
30 > Krzysztof Pawlik  <nelchael at gentoo.org>  key id: 0xF6A80E46
31 > desktop-misc, java, vim, kernel, python, apache...
32 >
33
34 # Phase function: src_unpack
35 python-distutils-ng_src_unpack() {
36 [[ "${PYTHON_OPTIONAL}" = "yes" ]] && { use python || return; }
37
38 if type python_unpack &> /dev/null; then
39 # This should not run anything specific to any single Python
40 # implementation, keep it generic:
41 python_unpack_all
42 else
43 [[ -n ${A} ]] && unpack ${A}
44 fi
45 }
46
47 I think you meant to write "if type python_unpack_all".
48
49 More to the point, I don't actually understand why this function
50 exists. It doesn't actually do anything that default_src_unpack does
51 not do already. Exporting it will clobber any vcs eclasses if the
52 inherit order is wrong.