When updating the requirements for my tools (cover...
# general
h
When updating the requirements for my tools (coverage-py, black, mypy etc.) from the old style in
pants.toml
to the new style, they now no longer install based on the versions specified. And in the case of
extra_requirements
or type stubs these packages simply fail to be installed. What am I doing incorrectly?
Copy code
# old style
[coverage-py]
version = "coverage[toml]==7.2.7"
lockfile = "<none>"

# new style (for display purposes i've moved reqs from their file to be directly in config)
[coverage-py]
requirements = ['coverage[toml]==7.2.7']
Excerpt from pex output:
Copy code
pex: Downloading FileArtifact(url='<https://files.pythonhosted.org/packages/7c/f6/3c1715c27e3251baa578b469f3c266b48623d3bce4ea08509a636e11447c/coverage-7.2.1-cp39-cp39-macosx_11_0_arm64.whl>', fingerprint=Fingerprint(algorithm='sha256', hash='0f8318ed0f3c376cfad8d3520f496946977abde080439d6689d7799791457454'), verified=False, filename='coverage-7.2.1-cp39-cp39-macosx_11_0_arm64.whl')
g
h
I thought that may be the case, I may’ve misunderstood those docs but is it possible to specify resolves for these internal tools without having lockfiles for each of them?
g
I don't quite understand what that would mean. What does the resolve do in that case. Do you mean installing from a requirements file? In which case we're not using resolves at all.
h
Context: I had attempted to do the better thing and configure resolves for each of these tools (as well as source code) but was seeing issues with lockfile generation for certain packages. So I’m looking to replicate what I already have, which is just to specify reqs for these tools in a non-deprecated way. What does that config look like? With
version
,
extra_requirements
,
type_stubs
being deprecated in favour of resolves.
g
I honestly don't know if that is possible. Just looking at the configuration I can't see a way of doing it. I've never used Pants without resolves though, so there might be methods I'm not aware of. (Out of curiosity, what in the lockfile generation failed? Is it something that Pants could alleviate or fix for you? The closest I could find was https://github.com/pantsbuild/pants/issues/18532, but it sounds like that's a runtime failure)
h
It failed to install a version of
pyside6
that’s a part of my normal reqs, although I’m not sure whether that’s down to the right type of distribution not being available. So will attempt to debug the process but presumably
pants generate_lockfile
should be performing the same logic as any other internal pip install so it should work.
It seems that Pants wasn’t using the correct interpreter_constraints that I had set and was attempting to generate the lockfile with a wider range of Python version. After wiping all caches, this now seems to work as it should. 🙂