Re: Guix as a Guile package manager

[Fabio Pesari <fabiop@gnu.org>]

On 01/09/2016 02:05 PM, Amirouche Boubekki wrote:
> Héllo,

Hi!

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

There are many package managers actually, and most of them were
abandoned by their maintainers and/or never gained any traction in the
community.

This one doesn't look like it's any different - last commit goes back to
June 22nd, 2015.

The reason CPAN, pip and gem are so successful is that they are bundled
with their language's interpreters and are officially maintained.

Asking users to install a separate package manager might work in some
cases (Leiningen, Composer) but it usually leads to fragmentation and
confusion (as it was the case with many Lisps, especially CLs).

> 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 called for a fork because having Guix as both a general-purpose
package manager and a Guile-specific package manager is very confusing
and doesn't follow the UNIX philosophy.

As I said before, there doesn't need to be any code duplication - Guix'
core can be abstracted into a library (e.g. guile-guix) and both Guix
and the Guile package manager can be implemented on top of it with a
minimal amount of code (since nearly all functionalities are implemented
in the library).

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

That's still better than nothing, I suppose, so I'm not against it if
it's the only way to make it happen (at least in the short term).

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

Yes, Guix should be in the official repos of other distros as soon as
possible. I understand that the devs are still working on Guix but
increasing the userbase (and the pool of potential testers) wouldn't hurt.

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

The lack of a web UI is a huge problem, and so is the fact that "it's
said to work".

The official repository server should also be hosted on GNU servers and
not by an independent developer like guildhall's:

http://shift-reset.com/doro/

how can I know for sure all those packages are 100% free?

User should be able to upload packages but each package should be
carefully reviewed (possibly by the community itself).

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

I agree with you that users should be able to submit packages easily -
that's why I called for a fork, so that the standards for package
inclusion can be much lower (except for freedom, which is imperative)
and the Guile packages are by default separated from all other software.

This could also be achieved with a separate repo (like "guile-contrib"
or something along these lines) for Guix, sure, but I'd still like a
separate repo with a separate database and site, so that important
things like user ratings can be implemented independently from the other
Guix repos.

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

I'm not against the idea of third party package repositories (I see no
reason why this functionality should not be implemented) but Guix should
focus on having every decent quality free program in its repositories,
so that people are not encouraged to use third-party repos.

I find it self-defeating that in distros like Parabola (or upstream,
Arch), fully functional and semi-popular programs like OpenArena,
pngquant and yuicompressor can only be found in the user repository (the
AUR), which also distribute proprietary software.

If people are encouraged to include third-party repos, freedom goes out
of the window pretty easily, so the official repositories should be as
complete as possible (I know it's easier said than done, but it should
be much easier for Guix compared to other package managers).