unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Attila Lendvai <attila@lendvai.name>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: importers and input package lookup
Date: Mon, 03 Jan 2022 15:40:49 +0100	[thread overview]
Message-ID: <87pmp8khla.fsf@gnu.org> (raw)
In-Reply-To: <FuW4JzMDHtW5MwswUgdcTYQOEM47BZ8_kIz0UBbgx2pPxGDEb4vZKDMb30dWoI8NDnygsL7NfMwcQvlV1z6-HjnZ5k56Zw3XsBXCOAHAoz0=@lendvai.name> (Attila Lendvai's message of "Mon, 20 Dec 2021 21:14:11 +0000")

Hi!

Attila Lendvai <attila@lendvai.name> skribis:

> there are two, independent namespaces:
> 1) the scheme one, and
> 2) the guix package repository.
>
> when i work on an importer (golang), it skips the packages that are already available in 2), but then it has no clue under what variable name they are stored in 1), and in which scheme module.

Does the variable name matters though?  In general what matters for the
importer is whether the package/version exists, regardless of the
variable name.

> should the dependency lists in the package forms be emitted as (specification->package "pkgname@0.1.0") forms?

No, not for packages in Guix proper.

[...]

> a bit of a tangent here, and a higher-level perspective, but... shouldn't the package definition DSL have support for this? then most package descriptions could be using package specifications instead of scheme variables, and 1) could be phased out. or would that be more error prone? maybe with a tool that warns for the equivalent of undefined variable warnings?

Package specs are ambiguous compared to variable references (they depend
on external state, on the set of chosen channels, etc.) so in general we
want to refer to variables.

HTH!

Ludo’.


  reply	other threads:[~2022-01-03 14:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-20 21:14 importers and input package lookup Attila Lendvai
2022-01-03 14:40 ` Ludovic Courtès [this message]
2022-01-03 15:01   ` Jelle Licht

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=87pmp8khla.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=attila@lendvai.name \
    --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).