Draft
Conversation
The store path isn't yet useful but will eventually be useufl for accessing the prefetched content for further processing later on.
Just like with the nix_prefetch_git changes this will allow us to access the unpacked store path while updating the lockfile.
This allows us to do further processing of the content of the pinned project such as including additional build metadata in our lockfile.
This is an experiment that includes Cargo.lock metadata in our
lockfiles for all added pins. The idea is outlined in [an issue] and
this is just a quick hack to get this going.
Currently the GitLab tests are failing as I didn't bother fixing them
given that they are currently being changed.
To test this initialize a new bare npins folder:
$ npins -d /tmp/foo init --bar
Then you can add a rust project (e.g. npins):
$ npins -d /tmp/foo add github andir npins
Now you should have a regular pin entry but also the JSON equivalent
of the Cargo.lock (TOML) file in a sub attribute.
$ less /tmp/foo/sources.json
This in itself isn't particular helpful yet but with a bit more
work (on our Nix shim and a variant of import-cargo) we can implement
the vision of the linked issue experimentally.
Open tasks:
* [ ] Is there a better way to handle the prefetched source path?
* [ ] Add some CLI options to opting into some kind of metadata
inclusion, right now we just include it unconditionally.
* [ ] Ergonomics, ergonomisc and ergonomics of the feature. It must
not suck!
* [ ] Unit tests
* [ ] Integration tests (maybe we can also dogfood this with npins?)
[an issue]: #37
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
HACK: introduce metadata for newly added pins
This is an experiment that includes Cargo.lock metadata in our
lockfiles for all added pins. The idea is outlined in [an issue] and
this is just a quick hack to get this going.
Currently the GitLab tests are failing as I didn't bother fixing them
given that they are currently being changed.
To test this initialize a new bare npins folder:
$ npins -d /tmp/foo init --bar
Then you can add a rust project (e.g. npins):
$ npins -d /tmp/foo add github andir npins
Now you should have a regular pin entry but also the JSON equivalent
of the Cargo.lock (TOML) file in a sub attribute.
$ less /tmp/foo/sources.json
This in itself isn't particular helpful yet but with a bit more
work (on our Nix shim and a variant of import-cargo) we can implement
the vision of the linked issue experimentally.
Open tasks:
inclusion, right now we just include it unconditionally.
not suck!