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!
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: