Hm, I've been adding an option `[python].resolves_...
# development
h
Hm, I've been adding an option
[python].resolves_to_constraints_file
to let you hook up constraints files when generating a lockfile. Unlike before, this option lets you specify tool "resolves" like
pytest
and
black
in the
[python]
option. Whereas our conventional modeling would be
[black].constraints_file
and so on. Thoughts on what is preferable? This decision will apply to migrating
[python].only_binary
to be
[python].resolves_to_only_binary
I think it's easier for me to implement this all belonging to
[python].resolves_to_constraints_file
And probably it results in less boilerplate? Let's say your only constraint is "don't use this bad version of requests" -- you may want to hook up every resolve, including tools, to use that same constraints file. It's nice to have it all in one place, i think?
Note that we do already have some precedent for
[python]
options impacting how a tool lockfile is generated: •
[python].lockfile_generator = {pex,poetry}
[python].only_binary
[python-repos].{indexes,repos}
@happy-kitchen-89482 @ancient-vegetable-10556 any opinions? https://github.com/pantsbuild/pants/pull/16420 is ready using the approach of only the
[python]
option
Related: I had the idea of introducing an
<all>
special value to mean that every resolve should use the same constraints. That could be useful when moving
[python].only_binary
, and maybe
[python-repos]
, to be per-resolve options
a
I don’t immediately have an opinion, but could come up with one if you needed me to
👍 1
h
I think that'd be helpful, please. We've had lots of thrash on Python 3rd-party dependencies, so I want to get this right
Hm I'll whip up a google doc
h
This sounds like a level of indirection solves all known problems...
h
(Almost done w/ google doc which collates ~4-5 questions related to this idea of "config per resolve")
A design doc proposing moving config for Python dependencies to be per-resolve, w/ shortcut to specify for all. PTAL https://docs.google.com/document/d/1HAvpSNvNAHreFfvTAXavZGka-A3WWvPuH0sMjGUCo48/edit#heading=h.ym0ps9y27lla
❤️ 1
@happy-kitchen-89482 do you agree with the general gist of the design doc, it sounds like? If so, I'd like to merge https://github.com/pantsbuild/pants/pull/16420 right now and start doing follow ups In particular, this confirms tool config should live in
[python]
, not the tool subsystems. I'm pretty confident now that's correct
🚢 1
h
I have a request for a fix in the followups, in that PR.
👍 1
h
@happy-kitchen-89482 @enough-analyst-54434 I came up with the strategy for when you're not using resolves/lockfiles, along with deprecation plan. PTAL at bottom 2 sections https://docs.google.com/document/d/1HAvpSNvNAHreFfvTAXavZGka-A3WWvPuH0sMjGUCo48/edit#heading=h.n451mfzergzm