6 ms·

> nix-pkg -i github.com/my/project What you describe would be fairly easy to script. I'm playing around with similar ideas. It's not exposed by default, but th

> nix-pkg -i github.com/my/project What you describe would be fairly easy to script. I'm playing around with similar ideas. It's not exposed by default, but the included script `nix-prefetch-git` dumps a git repo into the nix store, and when you run it from your shell, you have access to ssh keys and ssl certs (that are unavailable within a normal nix build). The next step is harder like you say, you'd either need to include nix expressions for all dependencies on down through libc and gcc, or just assume/hope that "whatever happens to be in the local nixpkgs" is appropriate, but then you kinda lose out on a lot of the point of nix. It'd be nice if there were some way to reference a version of nixpkgs from which the expressions for "ruby20" and its dependencies would be drawn (but then you'd end up with hundreds of slightly different versions of nixpkgs tarballs from every github project with no easy way to update).

sparkie 12y ago
Perhaps the easy way to update already exists - just that barely anyone uses it (properly). The feature is submodules - they provide exactly what we need for Nix - they give each commit a list of exact identities to commits in specific branches of submodules (ie, exact dependencies). If we imagine a scenario where our bootstrap package already contains a .nixpkg in its root directory, and we augmented git with a pre-commit hook which mechanically extracted nixpkgs from all submodules, and we introduced a chain of git repositories where submodules are ubiquitously used for our entire system, maybe we could automatically produce the required .nixpkg for each commit (might require us to insert a "package template" into the root of each repository).