Cacheable Processes do not play well with non-lockfile resolves.

[jsirois]

Currently Python requirement resolution is implemented via a cached Process (a Pex command line). Say there is exactly one un-pinned requirement and no lockfile: "ansicolors". Once the resolve completes, "ansicolors" will not be re-resolved until:

1. The lmdb store is blown away.
2. The remote cache is blown away.
3. Some combination of Pants flags is used to turn off both local and remote caching.

Note that approach 3 is ephemeral, and the old cached version of "ansicolors" will come right back when the flags are no longer used.

It appears coursier_fetch has the same issue.

[jsirois]

@Eric-Arellano lock files are one way to solve this. If you re-generate a lock file, that will find the new versions and all is well. The problem, though, is lockfiles are not required.

[jsirois]

@patricklaw this affects coursier rules as well. I'm pretty sure its not an important problem, but it does seem like a logical one and I'm not sure of the best way to solve it if we eventually need to.

[stuhood]

We're headed in the direction of lockfiles for all languages, so I'm going to close this in favor of those tickets:

• Python: Redesign Python 3rdparty dependency management (lockfiles) #12314
• JVM: jvm: inject coursier_lockfile dependency for java targets #12784
• Go: already supported via go.mod+go.sum