<@U06A03HV1> how polished do you think Pex lockfil...
# development
h
@witty-crayon-22786 how polished do you think Pex lockfiles need to be for 2.11?
@happy-kitchen-89482 found https://github.com/pantsbuild/pex/issues/1734, and there is still the issue with installing lock files that toolchain is experiencing (not yet triaged).
Benjy and I discussed that probably we need to decide between: 1) release slips to possibly next week 2) dont publicize pex locks, or at least hedge a lot
w
given the consensus around “strict release cycle and keep unstable rather than slipping a release” in the other thread, i don’t think that we delay 2.11.x.
h
OK. There will at least be 2.11.1
I can do a 2.11 rc after my next cp? (rip softwrap merge conflict)
w
so, probably: hedge a lot and call PEX a beta.
👍 1
yea, sounds good.
h
Cool. We already hedge a bit
Copy code
"However, Pex lockfile generation is a new feature. Given how vast the Python packaging "
            "ecosystem is, it is possible you may experience edge cases / bugs we haven't yet "
            "covered. Bug reports are appreciated! "
            "<https://github.com/pantsbuild/pants/issues/new/choose>\n\n"
I could
s/new/beta
?
w
fine with that wording. the big question is just whether the default should be
PEX
.
which is a complicated question, given that it affects users who
--enable-resolves
, rather than only brand new users
we’ve said in the past that support for thirdparty repositories is an important feature, so it’s possible that that is enough of a reason…? but also, using
pip
rather than `poetry`’s resolver when you
--enable-resolves
is good (although the additional differences we’re encountering due to
--universal
make that less convincing)
h
In 2.11, the default is still poetry but we deprecate not setting a default. It is only 212 where we have to choose, and I'm less worried about that because we still have 2 to 3 weeks available to us to stabilize Also poetry is very broken
h
Yeah, I guess we fast-follow with a 2.11.1, or just 2.12.x
w
It is only 212 where we have to choose
i don’t think that we strictly have to choose there either. we don’t need to rush this. can continue bumping until we feel the tradeoffs are right.
h
Continue bumping using a default? We could even have default be pex but still deprecate relying on the default
w
i think that for as long as
--enable-resolves
is not on by default, we can force people to make this decision as well, without defaulting.
h
We must have a default per the options system
I agree that enable resolves should not be on by default for now
w
sure. but by requiring them to set it explicitly, we effectively don’t have a default.
👍 1
h
Hmmm do we know if any large organizations using pex lock files? We're 0/3 for the repos I know of, beyond pantsbuild/pants
w
@bitter-ability-32190’s…? you alluded to maybe generating manually somewhere, but it sounds like you’re using the subsetting
b
Yup! Using them with pants pinned to rc1 (I think) At some point I need to use the version that supports, and use VCS reqs as well. Only good things to report with usage
🙌 1
"large" for our org is suggestive
👍 1