https://pantsbuild.org/ logo
Join Slack
Powered by
Bikeshed :bike: what to name the default for `[pyt...
# development
h
Bikeshed 🚲 what to name the default for 
[python].resolves
now that it will be Pex format.
✅ 1
It's currently 
3rdparty/python/default_lock.txt
. Pex lockfiles are JSON, but Pants messes it up by adding comments. Ending the file in 
.json
will make IDEs angry, although 
.jsonc
could work. Or instead, so far we've been using 
.lock
and then users have to can manually associate the file type in IDE with 
jsonc
or JSON5 in PyCharm if they want. I'm proposing 
3rdparty/python/user_requirements.lock
. Note that we call it "user lockfiles" in the new docs
@curved-television-6568 @bitter-ability-32190 you might Have Thoughts
To be clear: Pants and Pex don't care at all what you call the file. This is only the default convention
b
I don't think it matters all that much other than be consistent when you can. Consistency across other tools, or across time (as this evolves) Pants can't know or tell people easily to delete a default lock file from a previous version if it has a different name
👍 1
h
Oh hm that's a good point that us changing the default path breaks people. Pants will complain you don't have a lockfile Technically we should be deprecating not setting a default for both 
[python].lockfile_generator
and 
[python].resolves
. Oof
generally I think it's desirable that upgrading from Pants 2.10 to 2.11 does not involve you having to change your lockfiles
So, yeah, even though Poetry lockfile generation is ~broken, people are relying on it and we shouldn't change that without deprecation. Thoughts?
Oh alternative angle: change the default in Pants 2.10 to be 
3rdparty/python/user_lockfile.lock
. It isn't wrong to use that name. Because it's still an rc, we can still make that breaking change Then 2.11's only change is the lockfile generator, which we might not even change and instead only deprecate
b
Can we warn in today's version of you don't set the name? Then warn today and suggest setting it to the name of tomorrow's default
h
Yeah we can, we'd be deprecating not setting the default. But it means 2.11 still has to respect the old default of 
default_lock.txt
I'm putting up a PR targeted for 2.10 to change the default to 
user_requirements.lock
. Problem solved if we can do that
I guess we used 
default.lock
for JVM, so might as well be consistent here rather than 
user_requirements.lock
?
w
So long as it ends in 
.lock
🙂 The lockfile will be namespaced against the language, correct? Like, 
java/something.lock
and 
python/something.lock
h
yes, the defaults are 
3rdparty/python/default.lock
and 
3rdparty/jvm/default.lock
❤️ 1
➕ 1
👍 1
related: 
python-default
and 
jvm-default
for the resolve names. I think you might have weighed in on that, I was wondering if it should be 
py-default
w
I think either kinda make equal sense. 
jvm
is the VM it runs on, so maybe at the highest level of bike shedding, you could say something like "Well, 
py-default
could also apply to stuff like PyPy`, and it's fewer letters, which is nice.
Open in Slack
PreviousNext
Powered by