Hi Jonathan,

I'll only address the first part, because we already have a nice
solution to that.

Jonathan Frederickson <jonathan@terracrypt.net> writes:

> Hello Guix,
>
> I recently had a discussion in #spritely on Libera.Chat about Guix and
> Nix, and in particular a (relatively) new feature of Nix called flakes
> that Guix doesn't currently have an analogue for.
>
> I've been a Guix user for a while, but I've only recently started
> looking at using Guix for development via ~guix shell~ as in this blog
> post by David Thompson[0]. The Guile port of Spritely has been using it,
> so I've been trying it out for one of my own projects as a result. And
> it seems pretty nice; you're using the same package definitions you
> might use when contributing a package upstream to Guix, which feels
> pretty natural as someone already pretty familiar with Guix as a user.
>
> However, I noticed something about the resulting dependency graph that
> feels somewhat unsatisfying. When you define a package, the
> dependencies you provide in e.g. ~inputs~ are references to
> packages. And the way you get those is, of course, by importing
> modules containing those packages.
>
> But the package you end up with each time you do that... depends on
> which revision of Guix you're running when you run ~guix shell~! So if
> I point someone to a project with a ~guix.scm~ file, they might not be
> able to use it if their Guix revision is too old. (Or too new, if
> packages have been renamed or removed.) More generally, it means that
> they do not end up with the same dependency graph that I do. This
> makes troubleshooting potentially tricky, because if something breaks
> you have to check the resulting profile to see which versions of your
> package's dependencies (and transitive dependencies) are actually
> installed.

But we do have a nice solution for this problem: `guix time-machine`!
You can use a Guix from any commit you want alongside other channels, by
just knowing what commits people are using. If projects do rely on
specific versions of dependencies, they can distribute a channels.scm
file to be consumed by `guix time-machine`.

Now my personal opinion: you should note that it's a very bad idea in
general to rely on specific versions of dependencies. Downstream
consumers of your software should be able to use it with up-to-date
dependencies, because they can provide security benefits, bugfixes,
etc. Having version pinning like in go leads to dependency hell, and
should be frowned upon.

Best,
-- 
Josselin Poiret