From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Sassmannshausen Subject: Re: Call for project proposals: Guix and Outreachy Date: Mon, 29 Jan 2018 12:11:25 +0100 Message-ID: <874ln4ncma.fsf@gmail.com> References: <87fu6y27re.fsf@elephly.net> <874ln896pq.fsf@gmail.com> <87a7wyszo1.fsf@elephly.net> Reply-To: alex.sassmannshausen@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eg7La-00053Z-1s for guix-devel@gnu.org; Mon, 29 Jan 2018 06:11:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eg7LV-0004xN-K0 for guix-devel@gnu.org; Mon, 29 Jan 2018 06:11:34 -0500 Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]:53893) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eg7LV-0004vw-AF for guix-devel@gnu.org; Mon, 29 Jan 2018 06:11:29 -0500 Received: by mail-wm0-x230.google.com with SMTP id t74so13453991wme.3 for ; Mon, 29 Jan 2018 03:11:29 -0800 (PST) In-reply-to: <87a7wyszo1.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org 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