I assume this is intentional but I m kind of puzzled as to w Pants #general

I assume this is intentional, but I'm kind of puzz...

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

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

curved-television-6568

01/12/2022, 3:28 PM

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)

bitter-ability-32190

01/12/2022, 3:33 PM

Yup in-repo plugin, and using

.run_against_entire_lockfile

for performance

bitter-ability-32190

01/12/2022, 3:38 PM

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 🤔

bitter-ability-32190

01/12/2022, 3:39 PM

(Guess I'll turn off my plugin for my demo to my org later today 🤡 )

bitter-ability-32190

01/12/2022, 3:47 PM

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.

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

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 😄

bitter-ability-32190

01/13/2022, 4:13 PM

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.

bitter-ability-32190

01/13/2022, 4:37 PM

https://github.com/pantsbuild/pants/issues/14160

bitter-ability-32190

01/13/2022, 8:14 PM

Annnd now I cant seem to reproduce 😬

👀 1

bitter-ability-32190

01/13/2022, 8:19 PM

Ah OK I see it for

check

Whew

2 Views

Open in Slack

Previous Next