https://pantsbuild.org/ logo
Join Slack
Powered by
Hi <@U04S45AHA>! We are debugging an issue with pa...
# pex
d
Hi @enough-analyst-54434! We are debugging an issue with pants release at Twitter, which is also the reason master is red right now. We are seeing the same thing that is started to happening in upstream on 
Deploy unstable pants pex
Travis shard at your commit updating pex to 2.0.3. https://travis-ci.org/pantsbuild/pants/builds/622371760 We’ve run the pip command that the pex is running. In the directory of wheels some of them are linux_x86_64 and some of them are manylinux1_x86_64. It looks like we were able to resolve both of them with the same command before. Now the platform flag limits us to one or another. Is there a quick an easy fix? Could you help us, or implement it? If not, can we please revert the pex update until we have the issue solved? Thanks! 🙂
a
Do we need to do something like 
--platform=linux|manylinux
when we invoke pip (don’t know if that exists)? Or to change how we’re publishing those wheels from the build wheels job?
e
For foreign platforms there is no way to say both, but I think we may be lying about foreign here for the linux case. Looking...
a
What does lying about foreign mean? Treating things which should be equivalent as not?
e
Correct. Generally if you say platform=a|b|c its a lie, you cannot in fact deal with some dists resolved for a , some b some c. Consider macosx|linux
At any rate, the failure in CI is not linux/manylinux, its osx
Digging maybe 10 more minutes, but I think I will have to revert to buy time to figure out what's up with osx.
a
Interesting, internally we’re seeing it with Linux, so maybe both are broken and we get a random ordering or something?
e
Perhaps.
a
The OSX being broken is much more mysterious to me!
Anywho, thanks so much for jumping on it 🙂
e
The OSX case is a bug: https://github.com/pantsbuild/pex/issues/823 The linux/manylinux case is less clear to me. The appropriate fix for that case may be to run auditwheel to add the appropriate tags to "linux-x86_64" wheels. Doing so for the wheels pants depends on reveals all are manylinuxXYZ compatible. The OSX case though is enough to revert here. PR coming...
d
John, thank you! I appreciate it 🙂
r
I think the crux of this issue is the exact thing I mentioned in this thread: https://pantsbuild.slack.com/archives/C087V4P1T/p1573407828009400
i.e. manylinux should be a behavioral flag - and not a platform - for cross-platform builds.
e
The problem is, for a foreign platform 
linux
means nothing. This is why pypi doesn't allow it. 
linux
just means it works on the linux it was built on, not much more. So if you want to resolve 
linux
wheels you are guessing or else have arranged that all wheels available that are platform tagged 
linux
are in fact built for the linux you expect. If you have done that arrangement, then all wheels should be built for the platform you expect - ie: all 
linux
, no 
manylinux
.
My understanding is that twitter has 1/2 arranged for the 
linux
to work out, but still has wheels built manylinux too. AFAICT you really need to build all linux wheels for each linux type you deploy to and have a separate, isolated find-links for each such linux.
Still working on the OSX side of this though, which is a bit different. I'll file an issue for the linux side separately.
r
AFAICT you really need to build all linux wheels for each linux type you deploy to and have a separate, isolated find-links for each such linux.
that is not my understanding of the case whatsoever
“supports manylinux” means that in addition to resolving linux-x86_64 wheels, you also resolve manylinuxN-x86_64 as well. it’s additive, not exclusive.
e
When you build and deploy a wheel with platform linux-x86_64 to an index - how do you know which linuxes it works for?
r
and manylinux wheels are only useful in the event of publishing to pypi, where your consumer’s linux variants are unknown
for sdist -> bdist conversion tho, those build processes almost always produce linux-x86_64
which is 10000% fair game for non-pypi indexes
When you build and deploy a wheel with platform linux-x86_64 to an index - how do you know which linuxes it works for?
more often than not, you have control over that at the infra level (i.e. we control the Linux variant in Twitter DC)
e
OK - then if so, why don't you do this for all the wheels in your index?
IE: why are they not all linux-x86_64 ?
r
this is why manylinux is only relevant in wide publishing models - on the public internet, its vastly unknown; in-house, where linux-x86_64 bins are totally fair game it’s typiclly much more controllable
so at one point, before we had manylinux support, we would simply rename manylinux wheels to linux
e
Understood. I'm asking about Twitter
Do I have to worry about you having a mix?
r
we definitely have a mix.
e
You arguably should not have a mix
r
of linux, manylinux1 and manylinux 2010
whole heartedly disagree
this is how manylinux was designed to work.
its additive, not exclusive.
i.e. not a platform.
but a more tightly scoped variant, that is additive
hence my initial concerns
in no place that I have ever seen, aside from your work, has 
manylinux1-x86_64
been described as a platform - full stop
e
The problem with a foreign resolve is you have no info about the host. That info is needed to make the manylinux call.
r
yes, this is why it was a flag!
for foreign resolve, you declare it explicitly
e
Exactly, and so it will need to be listed as an explicit psuedo-platform for the foreign case.
r
(and most linux’ are compatible - thats the point - so it’s typically on by default)
e
Need to find a way to request >1 platform from pip here
r
thats the rub tho. because of the way that multi-platform resolves happen, you’re gonna have a Bad Time if you think of it as a platform.
and not an expansion of possible matches.
e
It is thought of as exactly that in tag expansion code
r
whats the approximate 
pip
invocation pex 2.x uses now for resolve?
e
The exact is revealed with -v or -vvv, not sure which.
Just a sec.
r
mainly curious about the mode e.g. 
pip wheel
pip download
etc
its also important to note that cross-platform targeting via pip was an afterthought - vs a first class feature of pex. so it would not surprise me to find gaps here.
pip
historically inferred platform on the running machine, always, hence why the flag is needed cross-plat.
e
For a foreign platform only, the quadruple of --platform --python-version --implementation --abi
r
so design crux here seems to be: 
pip
mode for manylinux resolve is optimized for infer vs explicit, pex was other way around until fused
e
This simply needs a hack to pip. Roughly the same hack we previously made to pep425tags. I'll do something there and try to make it presentable for upstream pip instead of maintaining a hacked copy like we have been.
It used to be the case they only accepted one version, now they accept plural. We leverage this pex 1.6.x did and pex 2.x does too. Similarly we'll want platform to become plural.
17 Views
Open in Slack
PreviousNext
Powered by