guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call for project proposals: Guix and Outreachy


From: Ricardo Wurmus
Subject: Re: Call for project proposals: Guix and Outreachy
Date: Sun, 28 Jan 2018 17:42:22 +0100
User-agent: mu4e 1.0-alpha3; emacs 25.3.1

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.

>> 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?

> 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.

> 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?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net





reply via email to

[Prev in Thread] Current Thread [Next in Thread]