Re: Guix as a Guile package manager

[Amirouche Boubekki]

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?