[GSoC 2020] [Proposal draft #1] Clojars importer for Guix

[Leandro Doctors]

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<sec: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 “The Central
Repository” (formerly known as “Maven Central”). However, 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<sec: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 “The Central Repository” (formerly known as “Maven
Central”)[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<sec: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<sec:Implementation-Plan>

4.1 Stages & Deliverables

4.2 Timeline & Milestones<sec:Timeline-&-Milestones>

A About the Applicant<sec:Personal-background>




*******************