Re: Solving the multiarch triplet once and for all
On Dec 18, 2012, at 02:22 PM, Julien Cristau wrote:
>On Thu, Dec 13, 2012 at 11:34:12 +0100, Jakub Wilk wrote:
>
>> How about undoing the Python multi-arch mess until someone provides
>> evidence that the changes solve more problems than they create?
>>
>Having some explanation of what's going on would definitely help. Is
>there a wiki or mailing list url that I missed and that describes what
>this is about?
I don't think you missed anything specific to Python. The Debian multiarch
effort is described in this wiki page (with lots of sub-links):
http://wiki.debian.org/Multiarch
My take on it is this: in order to support installation of packages in
multiple architectures, you need a multiarch triplet-specific directory into
which you can install architecture-dependent code. For typical (e.g. C)
libraries and headers, you have paths like /usr/lib/<multiarch-triplet> and
/usr/include/<multiarch-triplet>.
For Python, we need a multiarch-aware location to install extension module .so
files. As you know, Python uses /usr/lib/pythonX.Y and
/usr/include/pythonX.Y, which aren't multiarch-aware. We could extend
Python's ABI flag directories (PEP 3149), e.g. /usr/lib/python3.3m but I don't
think that's a good idea. Python already defines a platform-specific
location, e.g. /usr/lib/pythonX.Y/plat-linux2, but that isn't specific enough,
so Python was changed in Debian to search for and install to
`plat-<multiarch-triplet>`.
So far so good, except that there are lots of other tools that just assume
`plat-linux2` (or really, `plat-${sys.platform}`) because that's what they've
always done. No big surprise really, since *lots* of tools aren't/weren't
prepared for multiarch. Welcome to the brave new world.
At the command line, there are two official ways to discover the multiarch
triplet:
$ dpkg-architecture -qDEB_HOST_MULTIARCH
$ gcc --print-multiarch
I don't know which one is preferred, but I'm guessing it has more to do with
whatever packages you want to depend on.
It seems silly to me to require Python programs to shell out to either of
these every time they need to know the triplet. It's not *entirely* trivial
to do. A good example is virtualenv's site.py, which for bootstrapping
reasons can't use subprocess. Why force Python programs to re-invent 1000
different ways to get this information, when we can (and have to) calculate it
when Python is built.
Besides, Python programs don't necessarily want the triplet for the
architecture they're running on, but for the architecture that the Python
executable was built for. And that's not information that shelling out will
help you with.
So my proposed solution is to calculate the triplet for the architecture that
Python is being built on at configure time, and stash that into the sys module
so that Python code has a consistent, easy, and documented way to get at it.
sys is always going to be available, so that solves the bootstrap problem that
virtualenv has.
In Python 3.3, PEP 421 describes exactly where this information should go.
sys.implementation is the place to put it, and the name must start with an
underscore, so I chose `sys.implementation._architecture`.
In Python 2.7, there is no sys.implementation, so I chose `sys._architecture`
as the place to stash this.
If your code is bilingual, then you'd use:
>>> getattr(sys, 'implementation', sys)._architecture
which doesn't seem too horrible while we still have to support Python 2
<wink>. Once everyone agrees this is the right approach, I'll document this
in the Debian wiki, and it should be used consistently wherever it's needed.
I have opened bugs and uploaded patches to fix Python 2.7 and 3.3, and
python-virtualenv.
Cheers,
-Barry
Reply to: