@hundreds-father-404: what would block enabling tool lockfiles by default (

default='default'

) in 2.7.x? are we concerned that those won’t be resolvable on some platforms?

Great question! 1. Test that our defaults actually work for everything https://github.com/pantsbuild/pants/issues/12601 2. Improve

./pants tool-lock

semantics to let you only generate for certain lockfiles 3. Further improve our staleness check error message to e.g. explain

<default>

4. Determine if we are okay with lockfile generation changing between 2.6 and 2.7: is that a breaking change? 5. Determine if it's safe to set

default="<default>"

without a deprecation? I think that's achievable this week if Chris and I sprint on 1-3, and we decide 4-5 are fine! It means not working on multiple lockfiles for now, tho

Determine if we are okay with lockfile generation changing between 2.6 and 2.7: is that a breaking change?

there are no lockfiles for tools in 2.6… to be clear, i’m only talking about tools right now

2.6 behavior is use

[python-setup].requirement_constraints

🤢 I don't know how to go from that to default lockfiles Key note w/ default lockfile: Chris's invalidation mechanism will warn/error if the default doesn't work with your settings, like you've changed

--version

or

--interpreter-constraints

Yeah, I think we can be aggressive about ditching the broken behavior

@happy-kitchen-89482 @witty-crayon-22786 so, shall @ancient-vegetable-10556 sprint to stabilize tool lockfiles to be enabled by default in Pants 2.7? Put multiple lockfiles on a temporary hold. (I'd vote yes)

I think the path forward is fix tool PEXes to never use the constraints file. Only way to lock is 

[tool].lockfile

. And we default to 

<default>

, which will be breaking but we make an exception and document it well because things were so broken before. cc @happy-kitchen-89482, thoughts?

yea, definitely.

Cool, sounds great! thanks for talking that through

and given that this is the last thing that 2.7.x is really waiting for, determining how much of that is fine as cherrypickable followup vs blocking cutting rc0 would be good too

FYI: our lockfile generation does not handle any of

[python-repos]

, which will impact generating tool lockfiles for some orgs. I think we can not let perfect be the enemy of good, though. Some orgs will have to manualy provide their lockfile or disable the feature Let's do the right thing for everyone else by default

if they’re all named, i think it could just be one goal?

ah to clarify, yes. this is temporary because user-lock won't be stable enough in 2.7. I want it feature gated I won't be able to implement named resolves for user lockfiles in time we remove user-lock in 2.8

can feature gate via unions i think. but yea.