wish: make the (name) field optional

  • Open
  • quality assurance status badge
Details
5 participants
  • Andreas Enge
  • Arne Babenhauserheide
  • Ludovic Courtès
  • Tobias Geerinckx-Rice
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Arne Babenhauserheide
Severity
wishlist
Merged with
A
A
Arne Babenhauserheide wrote on 6 Sep 2013 11:05
(address . bug-guix@gnu.org)
8761ueqq09.wl%arne_bab@web.de
Hi Guix Hackers,

Currently when defining a package, I have to write the name at least
twice:

(define-public NAME
(name "NAME"))

This gives the flexibility to use different names for the visual
output and the technical name. But for most packages it likely just
adds useless duplication.

So I think the (name) field should be optional, and if it is not
present, the packages technical name should be used automatically.

Best wishes,
Arne
L
L
Ludovic Courtès wrote on 6 Sep 2013 14:06
(name . Arne Babenhauserheide)(address . arne_bab@web.de)(address . 15284@debbugs.gnu.org)
87k3iu2lye.fsf@gnu.org
Arne Babenhauserheide <arne_bab@web.de> skribis:

Toggle quote (13 lines)
> Currently when defining a package, I have to write the name at least
> twice:
>
> (define-public NAME
> (name "NAME"))
>
> This gives the flexibility to use different names for the visual
> output and the technical name. But for most packages it likely just
> adds useless duplication.
>
> So I think the (name) field should be optional, and if it is not
> present, the packages technical name should be used automatically.

As discussed on IRC, the main issue is that package objects exist
whether or not the exist a variable bound to them; and really there can
be any number of variables whose value is a given package object. IOW,
there is no direct connection between the variable name and the package
name.

That said, for cases like the above, we could have:

(define-syntax-rule (define-package package-name fields ...)
(define-public package-name
(package
(name (symbol->string 'package-name))
fields ...)))

However, I prefer treating packages just like any other Scheme object,
and to avoid introducing “magic” with macros like this.

WDYT?

Ludo’.
A
A
Andreas Enge wrote on 7 Sep 2013 23:30
(name . Ludovic Courtès)(address . ludo@gnu.org)
20130907213045.GC27881@debian
On Fri, Sep 06, 2013 at 02:06:49PM +0200, Ludovic Courtï¿œs wrote:
Toggle quote (6 lines)
> As discussed on IRC, the main issue is that package objects exist
> whether or not the exist a variable bound to them; and really there can
> be any number of variables whose value is a given package object. IOW,
> there is no direct connection between the variable name and the package
> name.

This is what happens with the python package rewriting I just implemented:
Inputs are rewritten as packages inside a list, and are not associated
to a variable name.

Having a special syntax just for avoiding to write the package name a second
time is not really needed in my opinion.

Andreas
A
A
Arne Babenhauserheide wrote on 14 Sep 2013 01:00
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 15284@debbugs.gnu.org)
1942738.pvRsuMxUva@fluss
Am Freitag, 6. September 2013, 14:06:49 schrieb Ludovic Courtès:
Toggle quote (3 lines)
> However, I prefer treating packages just like any other Scheme object,
> and to avoid introducing “magic” with macros like this.

I prefer not having to repeat stuff, and being able to do stuff like this is one of the big advantages of scheme.

But to see whether it actually helps a lot, it would be necessary to know how many packages will be available in multiple versions (so the package name and the variable have to differ).

Best wishes,
Arne
--
Ein Mann wird auf der Straße mit einem Messer bedroht.
Zwei Polizisten sind sofort da und halten ein Transparent davor.

"Illegale Szene. Niemand darf das sehen."

Der Mann wird ausgeraubt, erstochen und verblutet,
denn die Polizisten haben beide Hände voll zu tun.

Willkommen in Deutschland. Zensur ist schön.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iJwEAAEIAAYFAlIzmPQACgkQ3M8NswvBBUhMGwP/S81/O5wiCgF1J7dCsamw41WP
fQnHfiS5kTRKIAjXlkMjg3T8Sgzhkcg3HEmCToXdIyJgD/Lrt7wnYn5JsoFAc26l
hoONj28NS1ZYXtN9u6BKWyXKFKns71vZmXQMlKay35HdQ9W17HVz1Geaxs7WUaRg
zXzDSgSyV9EXQrV+gZA=
=kBek
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 23 Sep 2013 17:59
control message for bug #15284
(address . control@debbugs.gnu.org)
87hadbsf5g.fsf@gnu.org
severity 15284 wishlist
R
R
Ricardo Wurmus wrote on 16 Apr 2020 23:53
wish: make the (name) field optional
(address . 15284-done@debbugs.gnu.org)
878sivm71e.fsf@elephly.net
I agree with Ludo and Andreas that we better shouldn’t make the
name field optional.

That said, I just pushed a series of patches that happens to address
this wishlist item in a very roundabout way. It is now possible to
build packages from JSON files like this:

Toggle snippet (33 lines)
[
{
"name": "myhello",
"version": "2.10",
"source": "mirror://gnu/hello/hello-2.10.tar.gz",
"build-system": "gnu",
"arguments": {
"tests?": false
}
"home-page": "https://www.gnu.org/software/hello/",
"synopsis": "Hello, GNU world: An example GNU package",
"description": "GNU Hello prints a greeting.",
"license": "GPL-3.0+",
"native-inputs": ["gettext"]
},
{
"name": "greeter",
"version": "1.0",
"source": "https://example.com/greeter-1.0.tar.gz",
"build-system": "gnu",
"arguments": {
"test-target": "foo",
"parallel-build?": false,
},
"home-page": "https://example.com/",
"synopsis": "Greeter using GNU Hello",
"description": "This is a wrapper around GNU Hello.",
"license": "GPL-3.0+",
"inputs": ["myhello", "hello"]
}
]

As you can see, there is no variable assignment, because this is JSON.
The “name” field is the only identifier, and its value can be used as an
input in other packages (see the reference to “myhello” in the “greeter”
package definition).

It’s really only tangentially related to what this issue is about, but
it’s as close as we can get to duplication-free syntax — even though
it’s JSON and not Scheme. Look, there are also no labels for inputs!
Because there are no custom phases either…

--
Ricardo
Closed
T
T
Tobias Geerinckx-Rice wrote on 4 Sep 2021 12:17
(no subject)
(name . GNU Debbugs)(address . control@debbugs.gnu.org)
874kb0bq69.fsf@nckx
unarchive 15284
reopen 15284
merge 15284 50349
T
T
Tobias Geerinckx-Rice wrote on 4 Sep 2021 12:19
(name . GNU Debbugs)(address . control@debbugs.gnu.org)
871r64bq0t.fsf@nckx
severity 50349 wishlist
reassign 50349 guix
merge 15284 50349
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 15284@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 15284
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch