https://pantsbuild.org/ logo
#general
Title
# general
b

bitter-ability-32190

01/12/2022, 3:25 PM
I assume this is intentional, but I'm kind of puzzled as to why:
Copy code
09:16:23.41 [WARN] The constraints file requirements.txt does not contain entries for the following requirements: pantsbuild-pants.

Ignoring `[python_setup].resolve_all_constraints` option.
09:16:23.46 [ERROR] 1 Exception encountered:

  ValueError: [python].run_against_entire_lockfile was set, but could not find a lockfile or constraints file for this target set. See <https://www.pantsbuild.org/v2.9/docs/python-third-party-dependencies> for details.
Doesn't the version in my
pants.toml
act like a pin for pants' version? Do I have to keep both in lockstep? Should
pantsbuild-pants
be special-cased for
run_against_entire_lockfile
?
c

curved-television-6568

01/12/2022, 3:27 PM
I noticed this one the other day as well. I guess you are developing a plugin, and using the
pants_requirements
target?
1
If so, I think we’d like to handle this gracefully so that it works as expected (or document in
pants_requirements
what it is we’re missing to do properly)
b

bitter-ability-32190

01/12/2022, 3:33 PM
Yup in-repo plugin, and using
.run_against_entire_lockfile
for performance
Oh oof:
Could not find a version that matches pyyaml<5.4,<7.0,>=3.0,>=3.10,>=3.13,>=6.0 (from -r <http://requirements.in|requirements.in> (line 148))
pantsbuild-pants
and its deps are coming from the bootstrapped env right? So really pinning it is a bad idea 🤔
(Guess I'll turn off my plugin for my demo to my org later today 🤡 )
This seems relevant, but I can't piece the two together in my mind:
Copy code
The version of Pants is more useful now. If you're using a dev release, the version will be the exact release you're on, like before, to reduce the risk of a Plugin API change breaking your plugin. But if you're using a release candidate or stable release, the version will now be any non-dev release in the release series, e.g. any release candidate or stable release in Pants 2.9. This allows consumers of your plugin to use different patch versions than what you release the plugin with.
c

curved-television-6568

01/12/2022, 4:09 PM
What that tells you is merely a hint to what requirement constraints you’ll be given when using the
pants_requirements
. If you’re using a Pants dev release in your
pants.toml
then the requirement will copy that https://github.com/pantsbuild/pants/blob/a2346e5c180a8438f0cf27bf7ab71e9fbcae4df4/src/python/pants/backend/plugin_development/pants_requirements_test.py#L21-L26
b

bitter-ability-32190

01/13/2022, 4:08 PM
So I think I'm going to open an issue for this, and then see if I can't just dump my plugin into the wild and consume it with the
plugins
option. Then I've completely sidestepped the issue 😄
Actually seems like on this page: https://www.pantsbuild.org/docs/plugins-overview This section: "pants_requirements cannot update a constraints file" is somewhat noting this issue.
Annnd now I cant seem to reproduce 😬
👀 1
Ah OK I see it for
check
Whew
2 Views