From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amirouche Boubekki Subject: Re: Guix as a Guile package manager Date: Sat, 09 Jan 2016 15:35:34 +0100 Message-ID: <138b89e2a7ca9e091727a331a416bd6a@hypermove.net> References: <5690E261.8000704@gnu.org> <569113EF.5060605@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <569113EF.5060605@gnu.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org To: Fabio Pesari Cc: guix-devel@gnu.org, guix-devel-bounces+amirouche=hypermove.net@gnu.org, guile-devel@gnu.org List-Id: guix-devel.gnu.org 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?