bug#15284: wish: make the (name) field optional

bug#15284: wish: make the (name) field optional

[Arne Babenhauserheide]

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

bug#15284: wish: make the (name) field optional

[Ludovic Courtès]

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

bug#15284: wish: make the (name) field optional

[Andreas Enge]

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

bug#15284: wish: make the (name) field optional

[Arne Babenhauserheide]

[-- 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 --]

bug#15284: wish: make the (name) field optional

[Ricardo Wurmus]

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