1 |
On Mon, Oct 08, 2012 at 05:16:05PM +0200, Michał Górny wrote: |
2 |
> Hello, |
3 |
> |
4 |
> This is the second and hopefully last version of python-r1 + |
5 |
> distutils-r1 eclasses before committing. I would also like to shortly |
6 |
> point out the goals and the differences between various python eclasses |
7 |
> in Gentoo. |
8 |
> |
9 |
> Both are attached. For those who prefer hosted form: |
10 |
> https://bitbucket.org/mgorny/gx86-working-tree/src/5a2d39e69d6d/gx86/eclass/python-r1.eclass |
11 |
> https://bitbucket.org/mgorny/gx86-working-tree/src/5a2d39e69d6d/gx86/eclass/distutils-r1.eclass |
12 |
> |
13 |
> Changes from the previous version: |
14 |
> - support for DOCS and HTML_DOCS (alike EAPI 4); |
15 |
> - minimal support for passing arguments to setup.py (through |
16 |
> distutils-r1_python_compile & distutils-r1_python_install); |
17 |
> - EPYTHON values adjusted to match python.eclass; |
18 |
> - scripts are -${EPYTHON} suffixed -- i.e. foo-python2.7, |
19 |
> foo-pypy-c1.8; |
20 |
> - a wrapper script[1] is used to choose the correct script instead of |
21 |
> constant symlink. Thus, EPYTHON & eselect-python are respected, |
22 |
> - PYTHON_COMPAT can be an array only. |
23 |
> |
24 |
> What still needs considering: |
25 |
> - a nicer way of passing setup.py arguments (mysetuppyargs=()?, |
26 |
> esetuppy wrapper?); |
27 |
> - Prefix support. |
28 |
> |
29 |
> [1]:https://bitbucket.org/mgorny/python-exec |
30 |
> |
31 |
> |
32 |
> Now, for the differences part. |
33 |
> |
34 |
> Goals |
35 |
> ----- |
36 |
> |
37 |
> python.eclass aims to support every single Python package out there, |
38 |
> including rare corner cases supported in-eclass. It supports both |
39 |
> packages supporting one and multiple Python implementations. distutils |
40 |
> support is provided by second eclass, and both provide phase functions |
41 |
> (python.eclass providing default ph.f. wrappers). |
42 |
> |
43 |
> python-distutils-ng aims to support majority of Python packages using |
44 |
> distutils. With a bit of hackery it can support non-distutils packages, |
45 |
> but the use is limited to the common cases. In an uncommon case, it's |
46 |
> not flexible enough. It supports Python packages supporting multiple |
47 |
> implementations only. |
48 |
> |
49 |
> python-r1 aims mostly to provide tools to support majority of Python |
50 |
> packages. It tries to be simple & flexible, thus allowing handling |
51 |
> various corner cases without special branches of code in the eclass. |
52 |
> It doesn't export any phase functions, nor set dependencies by default |
53 |
> (just provides a variable with them). |
54 |
> |
55 |
> Right now, it supports packages supporting multiple implementations |
56 |
> only; if necessary, the support will be extended -- either through |
57 |
> additional code if that wouldn't add too much complexity, or through |
58 |
> additional eclass. |
59 |
> |
60 |
> It is accompanied by distutils-r1 which provides a simple overlay for |
61 |
> the very common case of distutils packages. This eclass exports phase |
62 |
> functions and sets dependencies implicitly. It also handles renaming |
63 |
> the distutils-installed scripts and linking the python-exec wrapper. |
64 |
> |
65 |
> |
66 |
> Python targets |
67 |
> -------------- |
68 |
> |
69 |
> python.eclass uses implicit Python target specifications. It provides |
70 |
> no ebuild-transparent way of enabling/disabling them. |
71 |
> |
72 |
> python-distutils-ng and python-r1 use USE flags to explicitly list |
73 |
> enabled Python implementations. Both eclasses use the same values for |
74 |
> PYTHON_TARGETS USE_EXPAND. |
75 |
> |
76 |
> |
77 |
> Installed scripts |
78 |
> ----------------- |
79 |
> |
80 |
> python-distutils-ng rework the installed scripts creating copies for |
81 |
> Python implementations and changing the shebang. The created copies |
82 |
> don't differ any other way. The old script name is then symlinked to |
83 |
> the version for default implementation. |
84 |
> |
85 |
> python.eclass & python-r1 instead let distutils rework the scripts |
86 |
> and just rename them before merging. A wrapper is used to choose |
87 |
> the correct version, respecting EPYTHON & eselect-python. |
88 |
> |
89 |
> python.eclass installs the files to separate installation images |
90 |
> and merges them. python-r1 installs them to the main image directly, |
91 |
> renaming the installed scripts between successive implementations. |
92 |
> |
93 |
> python.eclass creates a wrapper script for each package. The script is |
94 |
> written in python. python-r1 instead installs the compiled wrapper |
95 |
> once (in an ebuild), and symlinks it for the packages. The wrapper is |
96 |
> written in much simpler C. |
97 |
> |
98 |
> The implementation suffixes for all three eclasses are different: |
99 |
> - python.eclass uses -2.6, -2.7 for Python, -2.7-pypy-1.8, |
100 |
> -2.7-pypy-1.9 for pypy and -2.5-jython for jython (enjoy!); |
101 |
> - p-d-ng uses Python target names (-python2_6, -python2_7, -pypy1_8), |
102 |
> - p-r1 uses $EPYTHON values (-python2.6, -python2.7, -pypy-c1.8 (sic!)). |
103 |
> |
104 |
> |
105 |
> Dependency on Python |
106 |
> -------------------- |
107 |
> |
108 |
> python.eclass has a few variables necessary to set dependencies |
109 |
> on Python implementation, including internal sub-syntax (and an even |
110 |
> more complete generator sub-syntax in progress overlay). I suspect that |
111 |
> most of the possible variants can be achieved using it, just please |
112 |
> don't make me try learning it all. |
113 |
> |
114 |
> Additionally, packages supporting multiple Python implementations are |
115 |
> required to specify their supported Python versions twice -- with |
116 |
> PYTHON_DEPEND and RESTRICT_PYTHON_ABIS. |
117 |
> |
118 |
> USE flag dependencies are specified using three variables, and I'd like |
119 |
> to avoid getting anywhere deeper. |
120 |
> |
121 |
> p-d-ng has a very simple dependency setup. It has a variable for |
122 |
> listing supported Python versions and a variable to make Python |
123 |
> dependencies conditional under the 'python' flag. Lately, it has been |
124 |
> added a method of listing requested USE flags. |
125 |
> |
126 |
> p-d-ng does not provide any support for more complex dependency |
127 |
> specifications, nor a way to disable adding default Python dependencies. |
128 |
> |
129 |
> python-r1 does not append any dependencies by default, and instead |
130 |
> exports them in a variable. The variable can be used to easily express |
131 |
> simple cases, and avoids polluting the ebuild in more complex cases. It |
132 |
> also supports providing USE dependencies for the implementation. |
133 |
> |
134 |
> distutils-r1 adds the Python dependencies to RDEPEND & DEPEND; |
135 |
> additionally, it adds a dependency on python-exec. |
136 |
> |
137 |
> |
138 |
> Dependencies on other packages |
139 |
> ------------------------------ |
140 |
> |
141 |
> As python.eclass (as of gx86 state) does not express enabled |
142 |
> implementations explicitly, it is not possible to request those |
143 |
> implementations from other packages. The dependencies on other Python |
144 |
> packages are thus simple. |
145 |
> |
146 |
> p-d-ng does not provide any simpler way of writing dependencies |
147 |
> on other Python packages using the eclass. Thus, the necessary USE |
148 |
> dependencies have to be written by hand. |
149 |
> |
150 |
> python-r1 does provide a simple PYTHON_USEDEP variable which can be |
151 |
> used in dependency atoms to request the same Python implementations |
152 |
> being enabled. |
153 |
> |
154 |
> |
155 |
> Phase functions for distutils |
156 |
> ----------------------------- |
157 |
> |
158 |
> distutils.eclass allows specifying additional arguments to setup.py. |
159 |
> src_install() installs default documentation files (*unconditionally*) |
160 |
> and ${DOCS}, it also does installation image magic. |
161 |
> |
162 |
> p-d-ng has mixed unconditional and user-overridable stuff. Copying |
163 |
> sources is done unconditionally; redoing scripts can be disabled using |
164 |
> a separate variable. setup.py invocations are overridable. |
165 |
> |
166 |
> d-r1 splits each phase into 'global' and 'per-implementation' stages |
167 |
> which are both overridable. The default stages apply PATCHES (and user |
168 |
> patches), copy sources, run setup.py, install DOCS & HTML_DOCS and link |
169 |
> python-exec wrappers. |
170 |
> |
171 |
> |
172 |
> |
173 |
> Thank you for reading up to this. I'd appreciate any comments, ideas, |
174 |
> and especially any API suggestions while the eclass still ain't live. |
175 |
|
176 |
Hi! |
177 |
|
178 |
Do you have any examples of ebuild conversion for non-distutils |
179 |
using ebuild? I was reading trough these threads but could find |
180 |
only examples for distutils-r1. |
181 |
|
182 |
I have a package which requires for each supported python |
183 |
version to know python executable, include dir and library to |
184 |
build python bindings (uses cmake) and location for |
185 |
site-packages so I can manually install them. |
186 |
|
187 |
Of these there is function only for executable |
188 |
(python_get_PYTHON). I hope there is a reasonable way to provide |
189 |
the rest of them without the need for me to resort on guessing |
190 |
the locations. |
191 |
|
192 |
|
193 |
Reinis |