Re: Guix as a Guile package manager

[Amirouche Boubekki <amirouche@hypermove.net>]

On 2016-01-09 15:06, Fabio Pesari wrote:
> On 01/09/2016 02:05 PM, Amirouche Boubekki wrote:
>> There is a package manager https://github.com/ijp/guildhall with a
>> package
>> repository with automatic package publishing without review.
> 
> 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).
> 

That's one of the reason why I advocate for guix as package manager of 
guile.

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

Can you explain what a Guile specific fork of guix will bring over guix?

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

This is not how pypi works for instance.

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

I just checked the documentation [1] and it's possible to have third 
party
repositories but the policy is to not fork the effort and package guile
softwares in guix.

[1] 
https://www.gnu.org/software/guix/manual/guix.html#index-GUIX_005fPACKAGE_005fPATH

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

My question is: what must do a guix fork that guix doesn't have already?