I might need someone with a Mac to help me debug t...
# development
b
I might need someone with a Mac to help me debug the failure on this PR: https://github.com/pantsbuild/pants/pull/17563
🫠 1
👀 1
oh nevermind I think I know th ebug perhaps
👀 2
oops, lol was on the wrong branch. Still no clue 😅
w
I’m invested in this roller coaster
b
I want off Mr. Bones' Wild Ride
I believe the correct command is
./pants run build-support/bin/_release_helper.py -- build-wheels
Oh huh I can reproduce. Thats a start. Why'd it pass on Linux in CI?!
Oh:
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmp5oeg4q6d/entry_8/pants/VERSION'
OK so on
main
the
VERSION
file is not part of
testutil
, so why is it failing now?
Oh @ancient-vegetable-10556 I'm suspecting this is due to
read_resource
perhaps?
a
HRRRRM MAYBE
b
aha, yes. Replacing the code in
version.py
with the old code gets past this issue seemingly? (although I get a different error)
a
I have forgotten a lot of this over the last couple of months, short of keeping everything working as best I could
b
We call
read_resource
in 8 places. I wonder what would happen if we replaced the internals with just
pkgutil.get_data
a
it would return to working just fine
note that
pkgutil.get_data
is somewhat broken (again, in ways I don’t remember)
that whole pyox process was difficult. I tried too many things for notetaking to be effective
b
ah iunderstand now
Oh it says so in your pr: `Resources can only be loaded from packages that contain an
__init__.py
file or namespace packages that do not contain `__init__.py``
You mind if I back that PR out?
a
IMHO there should be a very good reason, since
read_resource
exists to support an enduring API in Python, and
pkgutil.get_data
is deprecated and could go away
b
a
iirc we’re using a backport that fixes that ticket, but don’t quote me on that
b
Well this is becoming quite the ball to untangle
😢 1
w
🎢
b
So, one way to fix this is just to throw out PEP 420, since neither Pants-wheel'd nor Pants-PEXd are actually PEP 420 packages.
__file__
loading for
VERSION
would work
Or maybe a judicious symlink? 🤔
Wait a minute, I edited
version.py
but the line it complains on when I run
./pants run build-support/bin/_release_helper.py -- build-wheels
still has the old code. What gives?
Have I been making changes and testing nothing? 🤯
ah weird cache issue. huzzah
a
wheeeee 😕
b
OK so I'm just gonna use a subdir and call it a day
Say hello to
pants/_version
a
oh. Um, we also didn’t do that for a reason 🙂
b
🫠
a
b
I'm willing to change that and force
PANTS_FROM_SHA
users to update their script. I don't think we can expect the
./pants
shim to never change (especially considering it's about to change A BUNCH in the scie world)
a
We really need a way to propagate updates to the launcher script, tbqh
b
I don't disagree, but it's a chicken and egg problem 😛
a
not really, it’s a thing you can put into Pants itself
b
Also, the reality seems ot be that loading resources from the topmost namespace of a namespace package is a HUGE recipe for disaster
a
yeah, agreed
b
Because there is no answer to "who owns
pants
?" when
pants
is a namespace package
a
Right, that’s basically the definition of namespace packages
b
🙂
So I'll update the PR and lay out clearly this will break
PANTS_FROM_SHA
and then also PR the wrapper script
a
anyway, I would also be in favour of moving it for a specific version, but we should also push out a fix in 2.13/2.14 telling people to upgrade the wrapper script
b
I'm neutral on that I think. Whats the utility of backporting?
We can also do the symlink thing if the pain is real...
a
so that they update before they move to a release where it’s broken
b
If they're using
PANTS_FROM_SHA
they're already updating 😉
Let's have this discussion in GH, though so it's carved more into stone than sand
a
We never assessed the level of pain, we just tried to keep things working as best as they can
I agree keeping it for posterity is good
b
Actually though yeah since this is PANTS_FROM_SHA, backporting will do almost nothing
That only helps the people using `PANTS_FROM_SHA`for a commit on those branches which should be extremely rare
a
OK
b
But also doesn't hurt. I'm back to neutral 🙂
a
I think this is a feature we should eventually have, and this is a good opportunity to at least create the ticket 🙂
b
The updater/checker?
a
right
b
You making it? 😛
a
sure
b
🎉
Actually wait, yeah backporting is the "nice" thing to do, jus tin case. Thanks for the callout
a
Soooo, I think we might actually need to make the
PANTS_FROM_SHA
functionality a bit smarter, because it’s going to break if you’re testing commits a few months either side of now 🫠
b
or just another way of getting the version
a
yeah
Let’s see if I can come up with an approach
b
I'm thinking we don't need to know the version up front. Name the bootstrap folder related ot the SHA, download Pants at that SHA, then we can get the version from the installed code
It's probably doable. Let's move to DM