Add env lock command to generate PEP compliant lock files.#2216
Conversation
|
Awesome! I think the only thing missing is some tests of the actual lockfile, unless I’m missing something. E.g. that |
|
@flying-sheep @cjames23 firstly, thank you for your work here. Are there plans to support 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. |
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. |
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 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 🙂 |
… UV/pip implementations, a shared lock coordinator (generate / in_sync / apply_lock), and new hatch dep lock, hatch dep sync, and hatch lock commands alongside existing hatch env lock.
ofek
left a comment
ofek
left a comment
There was a problem hiding this comment.
Thanks! Feel free to merge after addressing the docs issues.
| upgrade: bool = False, | ||
| upgrade_packages: tuple[str, ...] = (), | ||
| layered: bool = False, | ||
| lock_extras: tuple[str, ...] = (), | ||
| lock_groups: tuple[str, ...] = (), |
There was a problem hiding this comment.
I'm fine with merging but do you think we should hold off on adding so many options until we get feedback on the workflow?
* Add env lock command to generate PEP compliant lock files. * Fix formatting issues * Move to per environment config of lockfiles * Move to export-all, adjust docs, dedupe based on lock-filename * Change to usefixture for helpers for lock tests * Ensure all dependencies are included in lock * Fix list transformation * Fix formatting * Add regression tests that confirm functionality * dd pluggable dependency lockers (hatch_register_locker) with built-in UV/pip implementations, a shared lock coordinator (generate / in_sync / apply_lock), and new hatch dep lock, hatch dep sync, and hatch lock commands alongside existing hatch env lock. * Fix formatting and type issues * Remove links to github discussion * Fix link * Address issue with pip locker and apply_lock * Fix formatting * Fix docs, better mocking approach for locks. * Fix tests after rebase. 89fb3cb
|
It seems only the first of the linked issues was closed by the merge. |
5 participants
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
Includes AI generated content.