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 16:29:13 +0100 Message-ID: <56912749.5030501@gnu.org> References: <5690E261.8000704@gnu.org> <569113EF.5060605@gnu.org> <138b89e2a7ca9e091727a331a416bd6a@hypermove.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1452353384 13421 80.91.229.3 (9 Jan 2016 15:29:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 15:29:44 +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 16:29:37 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 1aHvSR-0007W6-VO for gcggd-guix-devel@m.gmane.org; Sat, 09 Jan 2016 16:29:36 +0100 Original-Received: from localhost ([::1]:40929 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHvSR-000317-F6 for gcggd-guix-devel@m.gmane.org; Sat, 09 Jan 2016 10:29:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHvSL-0002xy-6t for guix-devel@gnu.org; Sat, 09 Jan 2016 10:29:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHvSH-00069e-Pw for guix-devel@gnu.org; Sat, 09 Jan 2016 10:29:29 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHvS5-00065k-Fe; Sat, 09 Jan 2016 10:29:13 -0500 Original-Received: from [87.19.29.194] (port=56162 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 1aHvS4-0004Zb-Sk; Sat, 09 Jan 2016 10:29:13 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.4.0 In-Reply-To: <138b89e2a7ca9e091727a331a416bd6a@hypermove.net> 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:15040 gmane.lisp.guile.devel:18115 Archived-At: On 01/09/2016 03:35 PM, Amirouche Boubekki wrote: > > Can you explain what a Guile specific fork of guix will bring over guix? See the last part of this post. >> 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. But that doesn't mean Guix should follow suit. Implementing approval like Savannah does is a bad idea, because packages get stuck there for ages and there's a lot of centralized power, but putting packages in a public queue which users can vote and allow packages to be reported for being nonfree and let maintainers be moderators is a better idea. > 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 Where's the bit about forking? The page is too long and I couldn't find it. > My question is: what must do a guix fork that guix doesn't have already? It's not about functionality, it's about purpose. The "fork" is not really a fork, but rather a separate program which uses the same core library as Guix (which I defined as guile-guix earlier). In practical terms, it would use a different repo and have different defaults tuned to Guile development rather than system maintenance. If the Guile devs decided to adopt Guix as it is right now as the official package manager like Perl's CPAN or Ruby's Gem, they would have to ship Guix with Guile, but that doesn't sound right in my opinion because Guix has a much larger scope and different purpose than CPAN and Gem and users could perceive this as adding bloat and/or a tool that is largely unrelated to Guile development - much like bundling Emacs because it has good Guile editing capabilities. It would also make more sense to distribute Guix as a separate program rather than require users to run a command like "pacman -S guile" to install Guix, but the same does not apply to the Guile package manager obviously because package management for Guile can be seen as part of the Guile environment (like it is for Ruby, Perl, Python, Go, Chicken, Racket, Emacs, etc.) The way I see it: * Guile ships with guile-guix (a library that implements much of Guix' package management capabilities, but not the Guix program) and a (very small) Guile package manager which depends on guile-guix * Guix is distributed separately as a (very small) program which depends on guile-guix Just to be clear, Guile does not depend on guile-guix, it just is a library that is shipped along with Guile and on which the package manager (also shipped with Guile) depends. The only side effect from doing this is that Guile's size in bytes would go up a bit, however it'd still be smaller than Python and it would gain package management capabilities. If that is not acceptable, I think that distributing the Guile package manager as a standalone package (like npm or composer) would still be a good thing, but I'd make it a separate program from Guix anyway for the reasons mentioned above.