unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* GSOC Draft Proposal
@ 2020-03-31  2:45 Steven vanZyl
  0 siblings, 0 replies; only message in thread
From: Steven vanZyl @ 2020-03-31  2:45 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

Hello all,

I am a prospective Google Summer of Code student who would like to
work on improving the Guix importer system and writing some new ones
for the Go Modules and Arch Linux PKGBUILD formats.

I admit that I am a rather late with this, but the last month has been
a bit more hectic than we'd all anticipated and there is still some
time left before the deadline.

Linked below is my proposal as a Notion document, and the same
proposal is attached in the Markdown format.
https://www.notion.so/rushsteve1/GNU-Guix-Proposal-d13dd543c5224ca395a9cad849bbe0db

Any and all feedback is greatly appreciated! And thank you for your
patience for this late submission.

Thank you,
Steven vanZyl

[-- Attachment #2: GNU Guix Proposal.md --]
[-- Type: text/markdown, Size: 6354 bytes --]

# GNU Guix Proposal

Steven vanZyl <rushsteve1@rushsteve1.us>

Please submit feedback as a Notion comment (requires account) or email me at the address above. All questions and criticisms welcome!

## Name of Project: GNU Guix

# Summary

Improve the existing Guix package importers and write new importers for the `[PKGBUILD](https://wiki.archlinux.org/index.php/PKGBUILD)` and [Go Modules](https://github.com/golang/go/wiki/Modules) formats so that the software available in this sources is more readily available on Guix-based systems.

# Benefits

The importers are, in my opinion, one of the many selling features of the Guix package manager. The ability to easily import existing packages into the Guix ecosystem greatly reduces the friction of adoption and increases the number of packages available to the user.

A Go Modules importer would improve support for the [Go programming language](https://golang.org/) ecosystem with Guix, expanding the software catalog and offering the superior dependency management of Guix for the language.

The `PKGBUILD` importer has the key benefit of vastly increasing software selection and availability, as well as opening up the possibility of importing packages from the [Arch User Repository](https://aur.archlinux.org/). [Arch Linux](https://www.archlinux.org/) is well known for their bleeding-edge software repositories, so an importer would allow many users to try newer versions of software easily. 

# Deliverables

- Improve existing importers and attempt to reach a feature parity between them.
- A basic importer of the `[PKGBUILD](https://wiki.archlinux.org/index.php/PKGBUILD)` format commonly used by Arch Linux, including recursive importing.
- An importer of Go 1.11 modules including using the `go.sum` versions and hashes, as well as recursive importing.

# Initial Research

Both file formats and their ecosystems are stable and standardized, with thorough documentation available from their primary sources.

## [Go Modules](https://github.com/golang/go/wiki/Modules)

Prior to the introduction and later [stabilization of modules in Go 1.14](https://golang.org/doc/go1.14) it was difficult, of not impossible, to automatically import a Go module in a reproducible manner. However with the introduction of modules and the [Go Checksum Database](https://sum.golang.org/) it is now far more feasible.

## `[PKGBUILD](https://wiki.archlinux.org/index.php/PKGBUILD)`

`PKGBUILD` is simply put, a complex format. It is even Turing Complete in some scenarios. However the vast majority of `PKGBUILD` files are relatively simple, containing only a source and a basic set of build instructions, making them largely no different from Guix `package` declarations.

Therefore I believe that in the interest of simplicity, security, and best practices, it is better to only implement a large subset of the `PKGBUILD` format, with room left to expand into full support if desired.

# Plan

Following the [official GSOC timeline](https://summerofcode.withgoogle.com/dashboard/timeline/) I have come up with the following three checkpoints in line with the evaluations.

## First Checkpoint (June 19)

Dive headfirst into the Guix codebase and try and get up and running. This is also a good opportunity to find places where the [Contributing](https://guix.gnu.org/manual/en/html_node/Contributing.html#Contributing) section of the Guix Manual can be improved for new developers.

Specifically during this period I would like to explore the existing importers to fix bugs and attempt to get all of them to roughly the same feature-parity, as [according to the documentation](https://guix.gnu.org/manual/en/html_node/Invoking-guix-import.html#Invoking-guix-import) they do not all support the same features and options as each other.

## Second Checkpoint (July 17)

During this time period I would like to work on the Go module importer. If functional I would also like to contribute a number of packages to the Guix repositories and generally expand support for Golang-based sofware.

## Final Checkpoint (August 17)

Create an initial importer of a subset of the `PKGBUILD` file format that allows users to import software intended for Arch Linux. This will likely become an ongoing effort due to the complexity of the `PKGBUILD` format, however I hope to have an initial implementation that works on a wide variety of simpler package definitions.

# Communication

IRC, Discord, Matrix, or any other chat platform is agreeable to me. I consider keeping in regular contact with mentors important, regardless of the platform.

I will likely attempt to engage the wider community as well to get feedback and ideas via the Guix mailing list, which I am already subscribed to.

I also believe that weekly check-ins would be very beneficial, preferably via a [Jitsi](https://jitsi.org) video call. Face-to-face communication is very beneficial for remote work, and I personally believe that a weekly check-in would help me to keep on track and maintain momentum.

# Qualifications

I am a rising senior (completed third year, not start fourth year) University student with a major in computer science.

I have a deep interest in LISP languages, with moderate experience in Racket and Clojure. I have explored GNU Guile somewhat, though I am admittedly not a Scheme Guru (yet).

I have wanted to contribute to GNU Guix for some time now, and I have been thinking about this importer project for quite a while. GSOC has provided me the perfect opportunity to finally explore and contribute to this amazing project.

# About Me

Thank you for reading this far!

My name is Steven vanZyl, I am a rising Senior at Rensselaer Polytechnic University in Troy, New York (near Albany). I'm a Computer Science and Information Technology and Web Sciences dual-major.

I've been interested and involved with Open Source Software for years now, and I am one of the leaders of the Rensselaer Center for Open Source, a student-run organization that promotes contribution to open source projects.

I've been avidly following the progress of the Guix package manager and Guix System GNU/Linux distribution for quite a long time now, and I have considered contributing on numerous occasions before now. The Summer of Code provides me the perfect opportunity to really dive into Guix and hopefully become a repeat contributor!

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-03-31  2:45 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-03-31  2:45 GSOC Draft Proposal Steven vanZyl

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).