Add env lock command to generate PEP compliant lock files.

[cjames23]

This PR replaces #2174 which had been closed due to having to delete my fork to get back to a clean state for creating a release.

The latest changes made ensure dependency-groups and extras are passed through for lockfile generation as well.

Closes #716 #749 #2176

[flying-sheep]

Awesome! I think the only thing missing is some tests of the actual lockfile, unless I’m missing something. E.g. that envs.some-env.dependencies end up in it and that that f14a893 works as expected.

[gabrielsimoes]

@flying-sheep @cjames23 firstly, thank you for your work here.

Are there plans to support generate_lockfile as a method in EnvironmentInterface so that plugins can implement custom behavior (e.g. populate [tool] with custom metadata)?

If this is not in the plans, would you be open to a contribution here? (once this PR merges of course) I can open another issue if this is best tracked separately.

[cjames23]

Awesome! I think the only thing missing is some tests of the actual lockfile, unless I’m missing something. E.g. that envs.some-env.dependencies end up in it and that that f14a893 works as expected.

Nope not missing anything. I am working on those tests right now :) I was just getting the PR back open for us to continue discussing and iterating over it.

[ofek]

Are there plans to support generate_lockfile as a method in EnvironmentInterface so that plugins can implement custom behavior (e.g. populate [tool] with custom metadata)?

Perhaps useful for @cjames23 to know, there are other ways to go about implementing pluggable lock file support. I proposed a potential design in #355. The read/write methods would no longer be required though because I landed on a much better (imo) abstraction with the FileSystemContext as returned by an environment's EnvironmentInterface.fs_context method.

The idea was that if an environment interface exposed filesystem synchronization primitives then dependency lockers could merely use that and be its own type of plugin. I thought that it would be nice to have them decoupled, to a certain extent. Lockers would also call other environment methods that are part of the public API but I view that as way cleaner and easier to implement than a locker having to subclass an environment interface just to change a bit of logic.

This was years ago when I was in peak Hatch design mode so my gut instinct tells me that paradigm is directionally correct. However, I would prefer providing value to users sooner rather than later so it's totally your call! Whatever you do is fine by me; just let me know when to review 🙂