https://pantsbuild.org/ logo
Join Slack
Powered by
Hypothesis: Python tools should not have default i...
# development
h
Hypothesis: Python tools should not have default interpreter constraints. Instead, if their ICs aren't specified we should fall back to the ICs of the repo. Discussion in thread.
We now require a repo to specify the ICs for its code (we no longer ship with a default for that option, which makes sense - how could we pick a sensible default?)
I believe that the same thing should be true for tools. And moreover, they should almost always be the same ICs, or certainly often enough that this should be the default behavior.
This has come up because now you can resolve tools from a regular resolve (and the special "tool lockfile" functionality is deprecated). And you may want to use a single resolve for code and tools (e.g., so you don't have to specify the pytest version in two places).
But if you try to do that now you have to manually set the tool ICs to match your existing resolve, which is really annoying to do across every tool you care about.
In the non-Pants world every tool expects to run on the interpreter that the code itself is compatible with.
I can't think of a counterexample, where you might need the tool to run on Python 3.x but operate on Python 3.y code
Does anyone have thoughts counter to this hypothesis?
(PS there is a stronger hypothesis, namely that tools should not have ICs at all, and should always use the code's ICs. Some tools already do this, and don't register the 
--interpreter-constraints
option, but the stronger hypothesis posits that they should all do this. However, for now, let's start with the easier thing.)
Note that this is unrelated to the ICs we use to generate the default tool lockfiles that ship with Pants. We can set those very wide, of course.
cc @hundreds-father-404 who has put the most thought into this
b
I think there are many examples of tools that can operate on code across a broader range of Python versions than what they can execute on, e.g.: ā€¢ pants ā€¢ black (runs with 3.7+, can format 3.3+ https://black.readthedocs.io/en/stable/faq.html#which-python-versions-does-black-support) ā€¢ mypy might (runs with 3.7+, can check 3.6+? https://github.com/python/mypy/issues/11974) However, if you're telling pants to resolving a tool from an existing resolve with its own ICs, that seems like opting in to "the tool uses the same universe of deps" and the python interpreter seems like a dep in that sense (specified via ICs rather than requirements).
āž• 2
h
That is an argument against the stronger hypothesis, but not the main one. With that you can still set ICs for the tool, but we just default to the repo-wide ones instead of to the ones Pants ships with (which I believe are pretty meaningless)
šŸ‘ 1
p
The only weird case in the ST2 repo was 
black
which required a higher minimum version than I specified for the default IC. So, I had to increase the minimum for black from 
>=3.6
to 
>=3.6.2
. So, I basically had to constrain that tool even more than everything else. So, I think there is value in allowing the user to override the IC for particular tools. But, I think the default should come from the user's explicit global default, not from the pants' default for that tool.
Stepping even farther - I think an IC should be more explicitly linked with a resolve. If you put a tool in a resolve, it should get the IC from that resolve.
So, you have a resolve+lockfile+IC that is provided by default in pants for each tool. Setting 
install_from_resolve
for a tool should take precedence for ALL of the requirements-related options, including IC. And, I think the same should apply in BUILD files - setting the resolve on a target should be sufficient to get that resolve's default IC. It's okay to further constrain the IC for a given target (parametrize ftw!), but the default comes from the resolve.
šŸ‘ 1
In other words, I think you're hypothesis is almost correct. The order of precedence of the settings needs to be tweaked so that the tool's default IC does not apply if the tool's resolve has changed.
h
The main motivation for default ICs in general was to make it easy to adopt Pants in a new repo. Pants Just Works Out Of The Box If we make you set ICs for each tool, that may be more boilerplate than other tools like Tox and Poetry
h
But now we make you set ICs for each tool if you need to change them for any reason
Instead of leaning on the repo-wide default
So we've actually made that worse
āž• 1
An initial step towards deprecating tool ICs: https://github.com/pantsbuild/pants/pull/18714
Just to slim down the blast radius
Open in Slack
PreviousNext
Powered by