<tumbleweed>
we detecting some of the multiarch values from the processor is hard (e.g. armel vs armhf debian archs)
<tumbleweed>
s/we//
<tumbleweed>
so I can't even really put an if ladder in there to generate the right values
<tumbleweed>
the simplest is to get it from the build environment. Either sys.implementation._multiarch from the caller python, or an environment variable / translation option. cpython uses a configure flag, for example
<tumbleweed>
but if it went back to using gcc --print-multiarch I wouldn't need to
<ceridwen>
tumbleweed, That's what I figured about venv and pypy3 on Ubuntu/Debian. Thanks for confirming my suspicion! Nothing like requiring numpy for matplotlib.
<mattip>
tumbleweed: I remeber 5f72d59b9aa1 giving the wrong value for some platform, I should have mentioned which in the commit message
<mattip>
I will revert it, add your patch, and let's see what the buildbots come up with (the result will be in the tarball's _sysconfigdata__*.py file)
<LarstiQ>
Does --print-multiarch also work for non-gcc environments?
<mattip>
it seems not, sys.implemenation._multiarch is python3+
<tumbleweed>
debian's python2 has sys.implemenation._multiarch too
<mattip>
ohh. I guess it doesn't hurt to backport it
<tumbleweed>
ah, no it's "sys._multiarch" on python 2
<tumbleweed>
sys.implementation was the generalisation from upstream cpython
<mattip>
hmm. So I will apply your patch to py3.7, py3.8
<mattip>
and do sys._multiarch for 2.7
<tumbleweed>
thanks, one less patch for me
<tumbleweed>
you're applying the lib_pypy rearrangement to 3.8 only. I'm wondering if I should bite the bullet and do it for 2.7 and 3.x in Debian. It does tidy things up
<tumbleweed>
I assume your motivation for 3.8-only was so virtualenv could handle it?
<tumbleweed>
or is there a dependency on something in 3.8?
<mattip>
It is a mess with setuptools which now vendors distutils which has its own command/install schema
<mattip>
I guess I could have special cased via the pypy version number instead of the python version, but it seemed dangerous
<mattip>
I don't want to break old versions
<tumbleweed>
right
<mattip>
maybe there are other tools that do funky stuff with the layout, it seemed safer to make a clean break with python3.8
<tumbleweed>
I'll experiment if I find some time
<mattip>
I guess it would be "safe" to backport the layout changes to 2.7, since anyway setuptools for 2.7 does not vendor distutils
<mattip>
the changes to virtualenv should be version agnostic, they involve checking characteristics not versions
<mattip>
my problem with virtualenv tests is that they compare themselves to venv, and venv was (is still) broken on the latest rc s
<tumbleweed>
the code in pypy/module/imp/importing.py should probably be using multiarch, too
<tumbleweed>
get_so_extension() I mean
<tumbleweed>
I'm kind of suprised this works at all on non-amd64