Thread re deprecating the option `[python].resolve...
# development
Thread re deprecating the option `[python].resolves_generate_lockfiles`:
Setting that to false indicates that Pants doesn't generate lockfiles for your user resolves, and instread you provide lockfiles externally (e.g., using poetry or pex to manually generate them). But that indication is only actually used in two places: 1) To not attempt to generate a lockfile when you call
without any
args, which means "generate for all resolves" 2) When deciding whether to validate the lockfile header (which we cannot do if we didn't generate the lockfile)
I propose that we deprecate this option, since it is very nuanced and not really necessary, and since we don't encourage using externally-generated lockfiles.
Instead, I propose that we add an option that explicitly enumerates the externally-generated lockfiles by resolve name.
This would get rid of one of the several awkward distinctions between tool and user lockfiles.
Or, we could use the existing
option for this, since it's a list value:
Copy code
resolve="-['external1', 'external2']"
Actually that might be tricky, since the option value is empty by default (which implies "all the resolves" but doesn't enumerate them) so there is nothing for the options system to subtract from, and we'd have to reach inside it to get these values
I am currently a user of
[python].resolves_generate_lockfiles = false
over in scie-pants. I'm happy with whatever spelling allows me to continue to generate my own lock files.
šŸ‘ 1
Why do you need any spelling at all for this? You can just not run
(assuming we know not to validate headers on those lockfiles, TBD exactly how)
I can't run generate-lockfiles ... because I generate the pants runner. I can't run Pants until I've built the scie-pants but the scie-pants needs the tools.pex to embed in its scie which needs the lock.
As soon as scie-pants is built, I dogfood it to run Pants which uses the lockfile I just generated to have it, amongst other things, also build the tools.pex and confirm bit for bit match.
So I have a very circular strange case.
I need to use the lockfile outside of Pants - and Pants puts in that damn invalid header. But that's cosmetic and I could work around. Its the bootstrap circularity that puts the nail in the coffin for scie-pants. I really don't want to check in an old
script in that repo!
You can just not run
I believe that's untrue. Pants then complains about lack of its invalid header in the lock.
I may be misremembering that though ... let me go back and check.
Copy code
$ git diff
diff --git a/pants.toml b/pants.toml
index fe9bd78..a2f3f9d 100644
--- a/pants.toml
+++ b/pants.toml
@@ -43,7 +43,7 @@ enable_resolves = true
 interpreter_constraints = [">=3.8,<3.10"]

 # We generate this via cargo run -p package -- --update-lock.
-resolves_generate_lockfiles = false
+#resolves_generate_lockfiles = false

 python-default = "tools/lock.json"
Copy code
$ dist/scie-pants-linux-x86_64 fmt lint check test package ::
18:20:12.06 [INFO] Completed: Format with isort - isort made no changes.
18:20:12.06 [INFO] Completed: Format with Black - black made no changes.

āœ“ black made no changes.
āœ“ isort made no changes.

āœ“ black succeeded.
āœ“ isort succeeded.
18:20:12.07 [ERROR] 1 Exception encountered:

Engine traceback:
  in `check` goal
  in Typecheck using MyPy - mypy

InvalidLockfileError: Could not find a Pants metadata block in the lockfile `tools/lock.json` for `python-default`. To resolve this error, you will need to regenerate the lockfile by running `dist/scie-pants-linux-x86_64 generate-lockfiles --resolve=python-default`.
Petards all the way down.
If that error didn't happen I'd be even happier!
I also set it to false and lock myself. Same idea as John, where is I don't see the error I'll take whatever means leads to the same end
Right, that is my caveat about knowing not to validate the header
Which I feel like we could also just do by detecting whether the header exists or not
And validating it if it does
Ah, yes. I did not read well.
I wish we had gone with a sidecar metadata file instead of front matter. Ah well.
We still can...
āž• 1
Yeah, we still can have a sidecar file:
The main thing I care about is letting you use manually generated lockfiles, including non-Pex i.e. requirements-style