unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: alex.sassmannshausen@gmail.com
Cc: guix-devel@gnu.org
Subject: Re: Call for project proposals: Guix and Outreachy
Date: Sun, 28 Jan 2018 17:42:22 +0100	[thread overview]
Message-ID: <87a7wyszo1.fsf@elephly.net> (raw)
In-Reply-To: <874ln896pq.fsf@gmail.com>


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

  parent reply	other threads:[~2018-01-29  8:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-21 21:59 Call for project proposals: Guix and Outreachy Ricardo Wurmus
2018-01-26 11:53 ` Alex Sassmannshausen
2018-01-27  2:01   ` pelzflorian (Florian Pelz)
2018-01-27 11:45     ` Alex Sassmannshausen
2018-01-28 16:42   ` Ricardo Wurmus [this message]
2018-01-29 11:11     ` Alex Sassmannshausen
2018-02-06 22:05 ` Ricardo Wurmus
2018-02-07  7:51   ` Gábor Boskovits
2018-02-07  9:58     ` Ricardo Wurmus
2018-02-07 10:45       ` Gábor Boskovits
2018-02-08 13:47       ` Ludovic Courtès
2018-02-07 10:57     ` Andreas Enge
2018-02-08 13:48       ` Ludovic Courtès
2018-02-08 16:23         ` Ricardo Wurmus
2018-02-08 19:26           ` Gábor Boskovits
2018-02-08 19:58             ` Ricardo Wurmus
2018-02-10  7:08               ` Gábor Boskovits
2018-02-10  3:06     ` Chris Marusich
2018-02-10  6:52       ` Gábor Boskovits
2018-02-10 10:12       ` Ricardo Wurmus
2018-02-07 10:52   ` Andreas Enge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a7wyszo1.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=alex.sassmannshausen@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).