From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leandro Doctors Subject: [GSoC 2020] [Proposal draft #1] Clojars importer for Guix Date: Fri, 27 Mar 2020 01:09:33 -0300 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:56843) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jHgJh-0004oR-No for guix-devel@gnu.org; Fri, 27 Mar 2020 00:09:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jHgJZ-0002Ub-Fh for guix-devel@gnu.org; Fri, 27 Mar 2020 00:09:52 -0400 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]:36573) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jHgJY-0002Re-4j for guix-devel@gnu.org; Fri, 27 Mar 2020 00:09:48 -0400 Received: by mail-lf1-x135.google.com with SMTP id s1so6738781lfd.3 for ; Thu, 26 Mar 2020 21:09:46 -0700 (PDT) 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-mx.org@gnu.org Sender: "Guix-devel" To: Guix Devel Dear all, Below, I share my second draft. 1. Overview: still needs to be completed with material from the unfinished sections. 2. Problem Statement: fully developed, only need to add some data (you will note [the placeholders]) 3. Solution Overview: this is definitely the less developed section. I still need to add much more details (which options I see, which one I will implement, why...) Even though I have a stub for the remaining sections (mainly, the implementation stages and planning), their content will be defined once I have stabilized the content for these sections. Again, you will notice a few placeholders for data [note: marked with notes like this one :-)]. Looking forward for your feedback! Best, Leandro *************************** Clojars importer for Guix Leandro Doctors 1 Overview Guix supports importing packages from multiple, diverse sources. All this offering of software platforms enables Guix as a competitive option to a wide variety of users. Whereas the array of supported Guix sources is indeed vast and diverse, there is a major source yet to be supported: JVM packages. JVM comprise a major source of software: as of March 2020, there are more than LLL[note: TODO: add number (with source). ] languages that run on the JVM, with more than PPP[note: TODO: add number (with source). ] packages. The main de facto repository for JVM packages is =E2=80=9CThe Central Repository=E2=80=9D (formerly known as =E2=80=9CMaven Central=E2=80=9D). Ho= wever, as TCR does not support license metadata and explicit repository linking, supporting it does not seem to be an ethical choice for Guix. Fortunately, Clojars, the de facto repository for Clojure packages, supports the features Guix requires. Considering that Clojure (a libre, modern LISP dialect) is among the most popular JVM languages, Clojars would be a very valuable addition to the list of Guix importers. Finally, as Guix is also written in a LISP dialect, this would have the additional benefit of bringing together a kindred functional programming community. [note: TODO: add list of deliverables] 2 Problem Statement Guix supports importing packages from multiple, diverse sources. They range from metadata from the GNU System, repositories such as the Python Package Index and the Comprehensive R Archive Network, down to plain JSON metadata files. Supporting a broad offering of package sources does not only provide Guix with a broad catalog of packages, it also enriches it with a plethora of languages to choose from. All this offering of software platforms enables Guix as a competitive option to a wide variety of users. Whereas the array of supported Guix sources is indeed vast and diverse, there is a major source yet to be supported: JVM packages[footnote: Guix does include many Java packages, but none of them support their dependencies]. The Java Virtual Machine is one of the most popular platforms for software development, comprising around DDD[note: TODO: add number (with source).] of estimated developers worldwide. Whereas initially intended for a single language (Java), the JVM has been used as a platform to develop new languages. The only requirement that any language hosted on the JVM platform has to comply with is to generating bytecode artifacts compliant with the JVM specifications. In this way, as of March 2020, there are more than LLL[note: TODO: add number (with source).] languages that run on the JVM. JVM packages are distributed via .jar files -compressed files containing bytecode files. The main de facto repository for JVM packages is =E2=80=9CThe Central Repository=E2=80=9D (formerly known as =E2= =80=9CMaven Central=E2=80=9D)[footnote: The Central Repository Search Engine: https://search.maven.org/]. TCR mainains a network of over PPP[note: TODO: add number (with source).] JVM packages, mainly written in Java. Every package from TCR also specifies on which other packages it depends on. As with any client-server architecture, TCR takes care of maintaining the dependency graph and any tool that wants to fetch packages from TCR takes care of defining the best way of traversing it, according to its user's commands. There are many tools used to access TCR and manage package dependencies according to different heuristics. Depending on the programming language used, the most popular include Ant, Maven, Gradle, Ivy... However, supporting TCR does not seem to be an ethical choice for Guix. To begin with, TCR does not encourage package maintainers to publish their packages under a free software license (nor to even publish their sources). Moreover, even though a considerable number of TCR-hosted packages do use a free software license, TCR fails to provide any explicit licensing metadata, nor an explicit link to their repository. These two points force the user to use a third-party search engine with respect to both license compliance and package auditing. Therefore, whereas it is definitely possible reconciling Guix freedom-respecting values with using TCR-hosted packages, supporting TCR as a Guix import source (unless TCR adds license metadata and explicit repository linking) seems extremely difficult, if not impossible. Whereas supporting JVM languages that rely on TCR as a primary package repository source may be unfeasible at this point, nothing prevents supporting any other JVM package repository, as long as it supports both license compliance and repository linking metadata. Fortunately, Clojars, the de facto repository for Clojure packages, supports the features Guix requires. Considering that Clojure (a libre, modern LISP dialect) is among the most popular JVM languages, Clojars would be a very valuable addition to the list of Guix importers. Finally, as Guix is also written in a LISP dialect, this would have the additional benefit of bringing together a kindred functional programming community. 3 Solution Overview Clojars[footnote: Clojars: https://clojars.org], the de facto repository for Clojure packages, would be a very valuable addition to the list of Guix importers. Firstly, Clojure (a libre, modern LISP dialect) is the third most popular JVM language[footnote:Source: the 2020 JVM Ecosystem Report https://snyk.io/blog/jvm-ecosystem-report-2020/]. Moveover, as the main Guix language, Scheme, is another LISP dialect, it would be certainly beneficial for Guix developers to bring together a kindred functional programming community: it is very likely that among the new Clojure users we may find new potential contributors to Guix. Considering that many Clojure packages are replicated across Clojars and TCR, the importer could work in the following way[footnote: Thanks to Julien Lepiller for the first draft of this mechanism.]: when requesting a package, first, it would try importing it from Clojars. If this fails, it would import the package from TCR, without source nor licensing information. In short, to try multiple repositories, from the most desirable to the least desirable. In all cases, it would use the existing dependency information. 4 Implementation Plan 4.1 Stages & Deliverables 4.2 Timeline & Milestones A About the Applicant *******************