Re: Guix as a Guile package manager

[Thompson, David]

On Sat, Jan 9, 2016 at 5:35 AM, Fabio Pesari <address@hidden> wrote:
> Package managers have been immensely successful in increasing the
> popularity of programming languages - think about Perl's CPAN or Ruby's
> Gem. But Guile doesn't a package manager, and that in my opinion slows
> down its adoption.

Many of us in the Guile community, including myself, are not very
interested in language-specific package managers because they are
problematic:

- They put burden on the user to make sure the right toolchain is
  available to build/install things (GCC and co.)

- They cannot describe the full dependency graph for things that
  aren't completely written in that language or use a foreign-function
  interface (for example, a Guile library that talks to a C library
  via the dynamic FFI, or one that uses the Guile C API)

- They encourage new users to conflate the build system with the
  package manager, leading to software that cannot be built without a
  network connection and a specific package manager.  Java software is
  notorious for this, as are Ruby and Python to a lesser degree.

That said, I see the desire to have a tool for easily sharing pure
Guile modules.

> The Guix repos distribute a lot of useful Guile libraries (like
> guile-json or guile-opengl) which can't be found on most distro
> repositories and it already provides Guile APIs and package management
> capabilities...my question is, can Guix be forked into a full-blown
> Guile package manager like gem from Ruby?

You can install Guix right now and use it to help you develop with
Guile, or any other language.  I use it for all of my Guile projects
and it works great.

> I know that an argument could be made that Guix can already be used in
> this way, but there are many Scheme coders who don't need a system-wide
> package manager and would rather use a program that can manage Guile
> packages under a user root like ~/.guile and allow them to easily
> distribute their packages (something like Python's virtualenvs would
> also be useful).

This is what the Guildhall[0] is for, but it needs some love.  I
really do not encourage the use of language-specific package managers
for the above-mentioned problems, but if you *really* want that,
contributing to the Guildhall seems to be the best thing to do.
People ask about it somewhat frequently, but so far no one has seemed
willing to roll up their sleeves and make it work for them.

> Perhaps some of the Guix code can be moved to a library, so that both
> the Guix and the Guile package manager binaries can reuse the same code.
> Moving Guix' core to a library would also facilitate its inclusion in
> things like PackageKit, as well as make it easier to create front-ends.

This would be a bad idea, because it creates a divide between the Guix
core and the rest of Guix, which would force us to make currently
internal APIs into external, public APIs and worry about backwards
compatibility and other issues.  Our development of Guix models that
of Linux.  In Linux, the kernel is maintained in conjuction with the
kernel modules, in the same source tree.  In Guix, the core modules
are maintained in conjunction with the user interfaces and package
recipes, in the same source tree.  Thus, if we change the packaging
API, or something else, we can update the relevant code in the source
tree and be done with it.  We don't have to worry about breaking
compatibility with an older version of libguix or something.  This was
a deliberate decision made to deal with problems that the Nix
community have when their version of Nix doesn't work with their
version of nixpkgs.

On the topic of PackageKit, it's been discussed in the past, but
PackageKit is incompatible with functional package managers because it
does not support important features like unprivileged package
management. [1]

> I'm not a package management expert so I'm not sure this idea is
> feasible but I would really like Guile to become more
> popular, and this I think would be a step in the right direction.

I don't think Guix is a good fit here, because there's simply no way
around the fact that Guix packages *must* contain the full dependency
graph for build-time and runtime dependencies.  There's no way that
you could use, say, the Guile or GCC from your host system because
doing so invalidates the entire purpose and design of Guix.  Thus, a
Debian user that tried to use a Guile-specific package manager based
on Guix would be surprised when it starts compiling its own glibc,
GCC, Guile, etc.  So, I don't see anything worth extracting from Guix
to use to build a Guile-specific package manager.

I encourage you to hack on Guildhall to make it more usable for your
needs.

Happy hacking,

- Dave

[0] https://github.com/ijp/guildhall
[1] https://lists.gnu.org/archive/html/bug-guix/2014-03/msg00018.html