From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: Guix as a Guile package manager Date: Sat, 9 Jan 2016 10:30:37 -0500 Message-ID: References: <5690E261.8000704@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHvTU-0003Sw-On for guix-devel@gnu.org; Sat, 09 Jan 2016 10:30:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHvTT-0006cY-E3 for guix-devel@gnu.org; Sat, 09 Jan 2016 10:30:40 -0500 Received: from mail-yk0-x22c.google.com ([2607:f8b0:4002:c07::22c]:36013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHvTT-0006bo-9g for guix-devel@gnu.org; Sat, 09 Jan 2016 10:30:39 -0500 Received: by mail-yk0-x22c.google.com with SMTP id v14so298533803ykd.3 for ; Sat, 09 Jan 2016 07:30:38 -0800 (PST) In-Reply-To: <5690E261.8000704@gnu.org> 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 Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Fabio Pesari Cc: guix-devel , guile-devel On Sat, Jan 9, 2016 at 5:35 AM, Fabio Pesari wrote: > Package managers have been immensely successful in increasing the > popularity of programming languages - think about Perl's CPAN or Ruby's > Gem. But Guile doesn't a package manager, and that in my opinion slows > down its adoption. Many of us in the Guile community, including myself, are not very interested in language-specific package managers because they are problematic: - They put burden on the user to make sure the right toolchain is available to build/install things (GCC and co.) - They cannot describe the full dependency graph for things that aren't completely written in that language or use a foreign-function interface (for example, a Guile library that talks to a C library via the dynamic FFI, or one that uses the Guile C API) - They encourage new users to conflate the build system with the package manager, leading to software that cannot be built without a network connection and a specific package manager. Java software is notorious for this, as are Ruby and Python to a lesser degree. That said, I see the desire to have a tool for easily sharing pure Guile modules. > The Guix repos distribute a lot of useful Guile libraries (like > guile-json or guile-opengl) which can't be found on most distro > repositories and it already provides Guile APIs and package management > capabilities...my question is, can Guix be forked into a full-blown > Guile package manager like gem from Ruby? You can install Guix right now and use it to help you develop with Guile, or any other language. I use it for all of my Guile projects and it works great. > I know that an argument could be made that Guix can already be used in > this way, but there are many Scheme coders who don't need a system-wide > package manager and would rather use a program that can manage Guile > packages under a user root like ~/.guile and allow them to easily > distribute their packages (something like Python's virtualenvs would > also be useful). This is what the Guildhall[0] is for, but it needs some love. I really do not encourage the use of language-specific package managers for the above-mentioned problems, but if you *really* want that, contributing to the Guildhall seems to be the best thing to do. People ask about it somewhat frequently, but so far no one has seemed willing to roll up their sleeves and make it work for them. > Perhaps some of the Guix code can be moved to a library, so that both > the Guix and the Guile package manager binaries can reuse the same code. > Moving Guix' core to a library would also facilitate its inclusion in > things like PackageKit, as well as make it easier to create front-ends. This would be a bad idea, because it creates a divide between the Guix core and the rest of Guix, which would force us to make currently internal APIs into external, public APIs and worry about backwards compatibility and other issues. Our development of Guix models that of Linux. In Linux, the kernel is maintained in conjuction with the kernel modules, in the same source tree. In Guix, the core modules are maintained in conjunction with the user interfaces and package recipes, in the same source tree. Thus, if we change the packaging API, or something else, we can update the relevant code in the source tree and be done with it. We don't have to worry about breaking compatibility with an older version of libguix or something. This was a deliberate decision made to deal with problems that the Nix community have when their version of Nix doesn't work with their version of nixpkgs. On the topic of PackageKit, it's been discussed in the past, but PackageKit is incompatible with functional package managers because it does not support important features like unprivileged package management. [1] > I'm not a package management expert so I'm not sure this idea is > feasible but I would really like Guile to become more > popular, and this I think would be a step in the right direction. I don't think Guix is a good fit here, because there's simply no way around the fact that Guix packages *must* contain the full dependency graph for build-time and runtime dependencies. There's no way that you could use, say, the Guile or GCC from your host system because doing so invalidates the entire purpose and design of Guix. Thus, a Debian user that tried to use a Guile-specific package manager based on Guix would be surprised when it starts compiling its own glibc, GCC, Guile, etc. So, I don't see anything worth extracting from Guix to use to build a Guile-specific package manager. I encourage you to hack on Guildhall to make it more usable for your needs. Happy hacking, - Dave [0] https://github.com/ijp/guildhall [1] https://lists.gnu.org/archive/html/bug-guix/2014-03/msg00018.html