Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for local copy of dependency trees #20150

Closed

Conversation

moosichu
Copy link
Contributor

@moosichu moosichu commented Jun 1, 2024

This change is still in progress, currently by providing the argument --cache-dependencies-locally, you can have grabbed dependencies stored in a local zig-deps folder which theoretically should be viable for checking in to your VCS.

However - there are a few unsolved problems:

  • dependenices which are no longer depended on should probably be removed.
  • dependencies being stored flatly in the zig-deps folder by hash makes it non-obvious which dependency is which (from a user POV). Additionally, if you updated dependencies the hash (and by extension folder name) will change - this then makes tracking logical changes to dependencies in your version control system trickier.

I'm not entirely sure how to best solve these problems - one could be to have some kind of naming-resolution scheme, alongside a local lock file mapping names to hashes? This could be combined with a build option to force hashes to be recomputed to validate the contents of these folders have not changed (but having it as an option as it would be slower).

This would resolve #14283.

This change is still in progress, currently by providing the argument
`--cache-dependencies-locally`, you can have grabbed dependencies stored
in a local `zig-deps` folder which theoretically should be viable for
checking in to your VCS.

However - there are a few unsolved problems:
  - dependenices which are no longer depended on should probably be
    removed.
  - dependencies being stored flatly in the zig-deps folder by hash
    makes it non-obvious which dependency is which (from a user POV).
    Additionally, if you updated dependencies the hash (and by extension
    folder name) will change - this then makes tracking logical changes
    to dependencies in your version control system trickier.

I'm not entirely sure how to best solve these problems - one could be to
have some kind of naming-resolution scheme, alongside a local lock file
mapping names to hashes? This could be combined with a build option to
force hashes to be recomputed to validate the contents of these folders
have not changed (but having it as an option as it would be slower).
@moosichu moosichu force-pushed the feature/local-dependencies-cache branch from 01de893 to 7f38429 Compare June 1, 2024 18:15
@moosichu
Copy link
Contributor Author

moosichu commented Jun 1, 2024

Checklist of things to do:

@moosichu
Copy link
Contributor Author

moosichu commented Jun 2, 2024

OK - I'm fairly keen to iterate on this one, as it's already proving super useful for when I'm relying on dependencies that no longer build with newer versions of zig. So having a path to edit them and check those fixes in directly (whilst still enabling the ability to update the dependencies with zig fetch once they've updated upstream) is defo a use case worth supporting.

@moosichu
Copy link
Contributor Author

moosichu commented Jun 2, 2024

Linking some other discussions and problems that are relevant:

#943 (comment)
#16679

@andrewrk
Copy link
Member

andrewrk commented Sep 7, 2024

The proposal this implements was rejected.

@andrewrk andrewrk closed this Sep 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

use an additional, project-local copy of dependency trees
2 participants