| 1 |
Hello, all. |
| 2 |
|
| 3 |
I've been working on solving the issues we had with Python script |
| 4 |
wrapping. I'd like to present the best solution I could think of, along |
| 5 |
with a technical demo, and ask for your opinion. |
| 6 |
|
| 7 |
|
| 8 |
Wrapping Python scripts currently involves renaming them through |
| 9 |
appending ${EPYTHON} suffix. This change in filename sometimes results |
| 10 |
in unexpected results, especially with packages that use sys.argv[0]. |
| 11 |
This breaks mis-designed packages such as gentoolkit or pkgcore, |
| 12 |
and often results in unexpected help output. |
| 13 |
|
| 14 |
It should be noted that kernel has special behavior wrt shebangs, |
| 15 |
and modifies argv[0] when they are involved. Therefore 'simple' setting |
| 16 |
of argv[0] for exec*() calls in the wrapper doesn't help here. |
| 17 |
|
| 18 |
In the past, python.eclass used Gentoo-specific patches to Python to |
| 19 |
work around those issues, and overriding sys.argv[0] on Python-side. |
| 20 |
python-r1 no longer uses those patches, and we will hopefully drop them |
| 21 |
after getting rid of python.eclass. |
| 22 |
|
| 23 |
|
| 24 |
The new way would involve moving them into dedicated directory instead. |
| 25 |
That is: |
| 26 |
|
| 27 |
old way: /usr/bin/foo-pythonX.Y |
| 28 |
|
| 29 |
new way: /usr/lib/python-bin/pythonX.Y/foo |
| 30 |
|
| 31 |
While this still involves changing argv[0], it has a few advantages |
| 32 |
over the current solution: |
| 33 |
|
| 34 |
1. basename(sys.argv[0]) stays unchanged. this fixes gentoolkit, |
| 35 |
pkgcore and makes 'foo --help' output 'foo'. |
| 36 |
|
| 37 |
2. PATH is no longer polluted by a dozen of foo-* variants. While some |
| 38 |
people may consider this a disadvantage, it makes bash completion |
| 39 |
a little less irritating at least. It also avoids having sub-commands |
| 40 |
like 'git bz-python2.7' :). |
| 41 |
|
| 42 |
3. variant choice can be implemented purely using PATH adjustments. |
| 43 |
That is, in a very optimistic case the wrapper scripts wouldn't need to |
| 44 |
be called. |
| 45 |
|
| 46 |
|
| 47 |
If you'd like to test it, I'm attaching a complete patch that should |
| 48 |
work on top of current tree. It modifies the python eclasses and adds |
| 49 |
a new slot to python-exec. The same changesets can be found on |
| 50 |
python-script-location-r1 branch of my gx86-working-tree repo [1]. |
| 51 |
|
| 52 |
It should be noted that while the eclass changes on that branch can be |
| 53 |
considered testing-ready, the C wrapper code is a quick, dirty hack |
| 54 |
and will be rewritten in the future if we decide to go this way. |
| 55 |
|
| 56 |
Currently known issues with the demo: |
| 57 |
|
| 58 |
1. the few ebuilds that try to play with wrappers directly do not work |
| 59 |
because they rely on old paths (dev-python/wxpython), |
| 60 |
|
| 61 |
2. parallel 'doins' is broken in portage [2] which can break a few |
| 62 |
more ebuilds (dev-python/docutils), |
| 63 |
|
| 64 |
3. baselayout doesn't provide a way to prepend paths before |
| 65 |
the standard set [3], so the wrapper are always used indep of PATH. |
| 66 |
|
| 67 |
[1]:https://bitbucket.org/mgorny/gx86-working-tree/commits/branch/python-script-location-r1 |
| 68 |
[2]:https://bugs.gentoo.org/show_bug.cgi?id=484332 |
| 69 |
[3]:https://bugs.gentoo.org/show_bug.cgi?id=484268 |
| 70 |
|
| 71 |
|
| 72 |
Please let me know what you think of this solution. It could be |
| 73 |
implemented mostly safely since the 'old' and 'new' wrappers can |
| 74 |
co-exist on the system. |
| 75 |
|
| 76 |
-- |
| 77 |
Best regards, |
| 78 |
Michał Górny |
Archives