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

generate-lockfiles

without any

--resolve=

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

--resolve=

option for this, since it's a list value:

[generate-lockfiles]
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

(assuming we know not to validate headers on those lockfiles, TBD exactly how)

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

./pants

script in that repo!

You can just not run

generate-lockfiles

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.

Yeah:

$ 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.resolves]
 python-default = "tools/lock.json"

Then:

$ 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!

Which I feel like we could also just do by detecting whether the header exists or not

And validating it if it does

The main thing I care about is letting you use manually generated lockfiles, including non-Pex i.e. requirements-style