[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guix as a Guile package manager

From: Amirouche Boubekki
Subject: Re: Guix as a Guile package manager
Date: Sat, 09 Jan 2016 14:05:38 +0100
User-agent: Roundcube Webmail/1.1.2


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

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 ~

reply via email to

[Prev in Thread] Current Thread [Next in Thread]