Re: Call for project proposals: Guix and Outreachy

[Alex Sassmannshausen]

Hey,

Ricardo Wurmus writes:

> Hi Alex,
>
>> I have read through the documentation and I believe I would be able to
>> commit to the duties of being a mentor / co-mentor.
>
> Wonderful!
>
>> I would be happy to send more details of where I believe my relative
>> strengths and weaknesses in this project would be.  I couldn't see an
>> appropriate place for that on the outreachy website — would it be best
>> to discuss this by email with you two?  Or on list?
>
> Either way is fine.  You’re welcome to send me email off-list if you
> think it shouldn’t be public.

OK, will do!

>>> Feel free to discuss project ideas right here before submitting an
>>> official proposal.  Project ideas for the Google Summer of Code are
>>> equally valid for an Outreachy internship.
>>
>> Wrt to project ideas, if I understand the target audience right, I would
>> propose perhaps as one project a strengthening of the Guile tooling
>> around Guix.
>>
>> Starter tasks could be helping to package and review existing packages
>> of Guile software for Guix.
>>
>> Actual project tasks could revolve around developing a nice Guile build
>> system for Guix.
>
> Thank you for this proposal.
>
> I wonder if that’s a project that would be big enough for a three month
> internship.  Adding support for existing build systems in Guix usually
> isn’t very difficult, because much of the work has already been done in
> the form of the gnu-build-system.
>
> I worry that the actual implementation would be little more than walking
> down the directory tree, compiling every Scheme file, and then copying
> files over to a target location.
>
> On the other hand, this project could become more comprehensive if we
> looked at the earlier potluck proposal and adopted a few more tasks from
> there.  What do you think?

I like this idea.  It feels like we'd have a nice learning curve here,
that also touches a significant chunk of guix build tooling here.

So:
- pre-project tasks: package Guile (and other) packages, to get familiar
  with problems around packaging, and basic concepts.
- project 1): extend gnu-build-system for a guile-build-system that
  "does the right thing", when full autotools support is present in the
  project. [difficulty: easy: just customise/add gnu-build-system
  phase].
- project 2): simple-guile-build-system that installs guile only modules
  without autotools present. [difficulty: medium: write a build-system
  from scratch]
- project 3) and onward: potluck.  This project would take the candidate
  beyond the confines of Guile projects specifically, focusing on the
  user journey of "new contributors" to Guix in general.  The work
  optimising for Guile, and their own user journey, should be
  informative for this. [difficulty: ?]

The latter will need to be broken down further: ideally we want to be
able to present a well-defined project with discrete steps that could be
added to Guix incrementally to avoid a large chunk of code outside
master to be merged "at some point…"

>> First steps would be perhaps to enhance the gnu-build-system with
>> additional phases for Guile specific tasks (setting the Guile site path
>> correctly, ensuring guile dependencies are propagated inputs…)
>>
>> A second step might be a simplified Guile build system, which does not
>> rely on autotools infrastructure.  I believe this was discussed in the
>> past: it would be a "beginners build system" for *Guile only* packages
>> for quick and easy sharing in the Guix community.
>
> These seem like reasonable steps.  What are the assumptions that we
> would make about Guile-only projects?  It might help to have a list of
> Guile packages that don’t use a proper build system and compare their
> file layout to figure out the kind of work the build system would have
> to perform.

Agreed.  I think the following assumptions are fairly uncontroversial:
- a guile project has at least one source file
- but no more than one source file in the "root" of the modules
  directory layout
- if the project has more than one source file, these are located in
  subdirectories of the "root" of the modules directory layout
- there should be a directory of .scm files that contains tests,
  generally called "tests"
- there could be a directory containing .texi files, generally called
  "doc"

e.g.
foo-project/foo.scm
foo-project/foo/bar.scm
foo-project/foo/baz.scm
foo-project/fan/bot.scm
foo-project/tests/....scm
foo-project/doc/....texi

But as you say, it probably makes more sense looking at existing
Guile-only projects to confirm/falsify this.

>> Finally we might look at first steps to generate guix package recipes
>> from guile projects.  A first step might be a well-defined script that
>> generates a new project filetree, and writes a guix.scm file within it
>> that contains a Guix recipe using the beginners guile build system.
>
> Would this still be needed even if the guile-build-system were robust
> enough to deal with different kinds of file layouts?

You are right — this may not be necessary.  Additionally, if we progress
down the potluck road, then that might provide a more general tool for
this.

Alex