Hilton Chain <hako@ultrarare.space> writes:
Jason Conroy <jcon...@tscripta.net> writes:
Hilton Chain <hako@ultrarare.space> writes:
Hilton Chain <hako@ultrarare.space> writes:
Blog post sumbitted as:
https://codeberg.org/guix/artwork/pulls/1
Hilton, thank you for the nice writeup. I've been following the
discussion at a distance, so this is a somewhat naive question
about the developer workflow under your proposal.
When using Guix with other languages, I find "guix shell"
extremely convenient for setting up a project's
dependencies. The
produced environment gives me confidence that:
a) the lib dependencies have versions that the Guix community
has
already vetted and used successfully;
b) all transitive dependencies of those libs are available, and
also have known-good versions;
c) any work required to patch the libraries for Guix builds has
already been done, so there are no surprises later on.
Unfortunately, all existing approaches don't involve supporting
Rust
libraries in `guix shell`.
Hi Hilton, thanks for the response. I am aware that the existing
approaches have this feature gap in `guix shell`, but the question
is whether, in your opinion, the recent changes make it any easier
or harder to close the gap in the future.
Going back a while, Efraim shared a preliminary patch [1] that
generated a local cargo registry via a profile hook. It seemed
like a viable proof of concept: walking recursively through
cargo-inputs and cargo-development-inputs provided enough to
reconstruct the registry metadata and install the sources. Do you
think that this strategy is still possible with the new data
model?
Jason
[1]
https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00151.html
