unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Ivan Petkov <ivanppetkov@gmail.com>
Cc: 35318@debbugs.gnu.org, Chris Marusich <cmmarusich@gmail.com>
Subject: [bug#35318] [PATCH] Update cargo-build-system to expand package inputs
Date: Mon, 20 May 2019 21:38:36 +0200	[thread overview]
Message-ID: <87pnocq5kz.fsf@gnu.org> (raw)
In-Reply-To: <6A0A0108-A722-4D73-85B7-E61AB8230026@gmail.com> (Ivan Petkov's message of "Sun, 19 May 2019 18:00:01 -0700")

Hi Ivan!

Ivan Petkov <ivanppetkov@gmail.com> skribis:

> Please let me know if anything is unclear, I’m happy to elaborate if needed!

I’ll only comment superficially because I haven’t followed the rest of
the discussion and I know too little about Rust; hopefully Danny and
Chris can provide feedback.

> From 5457f60036ce1354b4b89b9c3c423cca14e3a777 Mon Sep 17 00:00:00 2001
> From: Ivan Petkov <ivanppetkov@gmail.com>
> Date: Tue, 16 Apr 2019 03:37:44 -0700
> Subject: [PATCH 1/8] build-system/cargo: expand transitive crate sources
>
> * guix/build/cargo: (package-cargo-deps): Add it.
> (package-cargo-dev-deps): Add it.
> (cargo-transitive-deps): Add it.
> (expand-crate-sources): Add it.
> (lower): New cargo-deps nd cargo-dev-deps keywords.
> Use expand-crate-sources.
> (private-keywords): Add new keywords.

[...]

> +(define (package-cargo-deps p)
> +  (apply
> +    (lambda* (#:key (cargo-deps '()) #:allow-other-keys)
> +      cargo-deps)
> +    (package-arguments p)))

It’s surprising style.  It seems redundant with the ‘inputs’ field, but
IIUC, the main difference here is that you can simply name dependencies,
even if there’s no Guix package for it, right?

> +(define (package-cargo-dev-deps p)
> +  (apply
> +    (lambda* (#:key (cargo-dev-deps '()) #:allow-other-keys)
> +      cargo-dev-deps)
> +    (package-arguments p)))

As a rule of thumb, please avoid abbreviations in identifiers (info
"(guix) Coding Style").  So that would be
‘package-development-dependencies’ or something like that.

> +(define (crate-transitive-deps inputs)
> +  "Return the closure of INPUTS when considering the 'cargo-deps' and
> +'cargod-dev-deps' edges.  Omit duplicate inputs, except for those
> +already present in INPUTS itself.
> +
> +This is implemented as a breadth-first traversal such that INPUTS is
> +preserved, and only duplicate extracted inputs are removed.
> +
> +Forked from ((guix packages) transitive-inputs) since this extraction
> +uses slightly different rules compared to the rest of Guix (i.e. we
> +do not extract the conventional inputs)."

Perhaps call it ‘crate-closure’?

> +(define (expand-crate-sources cargo-deps cargo-dev-deps)
> +  "Extract all transitive sources for CARGO-DEPS and CARGO-DEV-DEPS along their
> +'cargo-deps' edges.

Maybe s/cargo-deps/inputs/ and s/cargo-dev-deps/development-inputs/?

I’d prefer to stick to the same terminology as in the rest of the code
if we’re talking about the same sort of input lists.

That’s it.  :-)

Thank you for improving Rust support!

Ludo’.

  reply	other threads:[~2019-05-20 19:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-19  5:34 [bug#35318] [PATCH] Update cargo-build-system to expand package inputs Ivan Petkov
2019-05-04 16:40 ` Ivan Petkov
2019-05-04 18:31   ` Danny Milosavljevic
2019-05-04 21:09     ` Ivan Petkov
2019-05-06  8:00 ` Ludovic Courtès
2019-05-06 16:04   ` Ivan Petkov
2019-05-09 23:17     ` Ivan Petkov
2019-05-15  6:08       ` Ivan Petkov
2019-05-15 12:44         ` Ludovic Courtès
2019-05-20  1:00           ` Ivan Petkov
2019-05-20 19:38             ` Ludovic Courtès [this message]
2019-05-22  2:48               ` Ivan Petkov
2019-06-08 18:44             ` Chris Marusich
2019-06-08 23:33               ` Ivan Petkov
2019-06-09 23:53                 ` Ivan Petkov
2019-06-12  1:14                   ` bug#35318: " Chris Marusich

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=87pnocq5kz.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=35318@debbugs.gnu.org \
    --cc=cmmarusich@gmail.com \
    --cc=ivanppetkov@gmail.com \
    /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).