Re: Guix as a Guile package manager

[Amirouche Boubekki <amirouche@hypermove.net>]

Héllo,

On 2016-01-09 11:35, Fabio Pesari 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.

There is a package manager https://github.com/ijp/guildhall with a 
package
repository with automatic package publishing without review.

> 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?

I'm not a core developer, but I don't think it makes sens to fork. Most
if not all features of guix are required by language package manager.
This includes virtualenv since guix can do them via 'guix environment'.

I think what could/should/must be done is settle on guix being the 
package
manager of Guile *and* document how to create package recipes for pure 
and
non-pure guile non autotools modules. Maybe declare guix the optional 
official
package manager something like that..

> 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

This is not an issue since IIRC you can install guix as a user. Not sure
what the status of this mode of operation is.

Also binary installation of guix is trivial, so it's not like something
that can forbid people using it. Having guix in other distros would be
of great help too.

> 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

Again there is guildhall even if it doesn't have the polish (nice web 
ui)
of pypi or cpan, it's said to work.

> (something like Python's virtualenvs would also be useful).

This is supported by guix.

> 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.
> 
> 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.

To repeat myself, I think we need more guidance and incentive on how to
include guile modules that are not autotools ready. For my usecase and a
lot of other modules I don't think it makes sens to have autotools if 
you
have guix. People who happen to not want to use/install guix, can 
resolve
dependencies themself and I don't see how autotools help anyway.

Somewhat related: even if I never saw a package rejected in guix, I 
think
most contributors have some expectations regarding the quality of 
packages
included in guix *main* repository. Otherwise said, I don't mind pushing 
a
alpha software or snippet on pypi, but this is not the case with guix.

So maybe, it will be nice to have a guix repository dedicated to guile
modules where the expectations will much lower and where guilers
can freely share their small and not so small contributions.

Also, this will be a visible example of how to extend guix with third 
party
package repository which is a significant asset is some commercial 
situations.

-- 
Amirouche ~ amz3 ~ http://www.hypermove.net