[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guix as a Guile package manager
Re: Guix as a Guile package manager
Sat, 09 Jan 2016 14:05:38 +0100
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
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
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
manager of Guile *and* document how to create package recipes for pure
non-pure guile non autotools modules. Maybe declare guix the optional
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
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
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
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
have guix. People who happen to not want to use/install guix, can
dependencies themself and I don't see how autotools help anyway.
Somewhat related: even if I never saw a package rejected in guix, I
most contributors have some expectations regarding the quality of
included in guix *main* repository. Otherwise said, I don't mind pushing
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
package repository which is a significant asset is some commercial
Amirouche ~ amz3 ~ http://www.hypermove.net
Re: Guix as a Guile package manager, Thompson, David, 2016/01/09
Re: Guix as a Guile package manager, Leo Famulari, 2016/01/09