all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#15284: wish: make the (name) field optional
@ 2013-09-06  9:05 Arne Babenhauserheide
  2013-09-06 12:06 ` Ludovic Courtès
  2020-04-16 21:53 ` Ricardo Wurmus
  0 siblings, 2 replies; 5+ messages in thread
From: Arne Babenhauserheide @ 2013-09-06  9:05 UTC (permalink / raw)
  To: 15284

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#15284: wish: make the (name) field optional
  2013-09-06  9:05 bug#15284: wish: make the (name) field optional Arne Babenhauserheide
@ 2013-09-06 12:06 ` Ludovic Courtès
  2013-09-07 21:30   ` Andreas Enge
  2013-09-13 23:00   ` Arne Babenhauserheide
  2020-04-16 21:53 ` Ricardo Wurmus
  1 sibling, 2 replies; 5+ messages in thread
From: Ludovic Courtès @ 2013-09-06 12:06 UTC (permalink / raw)
  To: Arne Babenhauserheide; +Cc: 15284

Arne Babenhauserheide <arne_bab@web.de> skribis:

> 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’.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#15284: wish: make the (name) field optional
  2013-09-06 12:06 ` Ludovic Courtès
@ 2013-09-07 21:30   ` Andreas Enge
  2013-09-13 23:00   ` Arne Babenhauserheide
  1 sibling, 0 replies; 5+ messages in thread
From: Andreas Enge @ 2013-09-07 21:30 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Arne Babenhauserheide, 15284

On Fri, Sep 06, 2013 at 02:06:49PM +0200, Ludovic Courtès wrote:
> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#15284: wish: make the (name) field optional
  2013-09-06 12:06 ` Ludovic Courtès
  2013-09-07 21:30   ` Andreas Enge
@ 2013-09-13 23:00   ` Arne Babenhauserheide
  1 sibling, 0 replies; 5+ messages in thread
From: Arne Babenhauserheide @ 2013-09-13 23:00 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 15284

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

Am Freitag, 6. September 2013, 14:06:49 schrieb Ludovic Courtès:
> 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. 
      ( http://draketo.de/stichwort/zensur )


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#15284: wish: make the (name) field optional
  2013-09-06  9:05 bug#15284: wish: make the (name) field optional Arne Babenhauserheide
  2013-09-06 12:06 ` Ludovic Courtès
@ 2020-04-16 21:53 ` Ricardo Wurmus
  1 sibling, 0 replies; 5+ messages in thread
From: Ricardo Wurmus @ 2020-04-16 21:53 UTC (permalink / raw)
  To: 15284-done

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:

--8<---------------cut here---------------start------------->8---
[
  {
    "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"]
  }
]
--8<---------------cut here---------------end--------------->8---

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-04-16 21:54 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-06  9:05 bug#15284: wish: make the (name) field optional Arne Babenhauserheide
2013-09-06 12:06 ` Ludovic Courtès
2013-09-07 21:30   ` Andreas Enge
2013-09-13 23:00   ` Arne Babenhauserheide
2020-04-16 21:53 ` Ricardo Wurmus

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.