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
next prev 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).