From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabio Pesari Newsgroups: gmane.comp.gnu.guix.devel,gmane.lisp.guile.devel Subject: Re: Guix as a Guile package manager Date: Sat, 9 Jan 2016 15:06:39 +0100 Message-ID: <569113EF.5060605@gnu.org> References: <5690E261.8000704@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1452348430 4585 80.91.229.3 (9 Jan 2016 14:07:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 14:07:10 +0000 (UTC) Cc: guix-devel@gnu.org, guix-devel-bounces+amirouche=hypermove.net@gnu.org, guile-devel@gnu.org To: Amirouche Boubekki Original-X-From: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sat Jan 09 15:07:02 2016 Return-path: Envelope-to: gcggd-guix-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aHuAX-0002PD-Fs for gcggd-guix-devel@m.gmane.org; Sat, 09 Jan 2016 15:07:01 +0100 Original-Received: from localhost ([::1]:40736 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHuAW-00083L-Db for gcggd-guix-devel@m.gmane.org; Sat, 09 Jan 2016 09:07:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHuAN-00082y-SM for guix-devel@gnu.org; Sat, 09 Jan 2016 09:06:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHuAM-0001E1-Ap for guix-devel@gnu.org; Sat, 09 Jan 2016 09:06:51 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHuAD-0001DK-7g; Sat, 09 Jan 2016 09:06:41 -0500 Original-Received: from [87.19.29.194] (port=53187 helo=[192.168.1.5]) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aHuAC-0004nP-HV; Sat, 09 Jan 2016 09:06:40 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.4.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Original-Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.comp.gnu.guix.devel:15036 gmane.lisp.guile.devel:18113 Archived-At: 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).