all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Proposal: Prefix language-name for language library packages
@ 2016-04-24 13:22 Hartmut Goebel
  2016-04-24 16:00 ` Danny Milosavljevic
                   ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Hartmut Goebel @ 2016-04-24 13:22 UTC (permalink / raw)
  To: guix-devel

Hi,

I propose to generalizing the specification [1,2] as we already have for
Perl, Python and Java for most programming languages. In short:

Package names should be prefixed with the name of the language and if
the package name already contains the name of the language, it gets
removed there.

I quickly scanned the current package definitions and found:

guile: 2 package to change
haskell: ca. 2 package to be changed
julia: 0
d (lcd.xscm): 0
nqc (lego.scm): 0 --> prefix "lego-"? OTOH this is a commercial brand
lua: 0
m4: 0
ocaml: 1
ruby: 0
r (statistics.scm): 0
scheme: 1 or 2
smalltalk: 0
tcl: 0

Maybe we should extend this even to frameworks like node.js?

Comments are welcome.

[1] http://git.savannah.gnu.org/cgit/guix.git/tree/doc/guix.texi#n11005
[2] https://lists.gnu.org/archive/html/guix-devel/2016-04/threads.html#00551

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

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

* Re: Proposal: Prefix language-name for language library packages
  2016-04-24 13:22 Hartmut Goebel
@ 2016-04-24 16:00 ` Danny Milosavljevic
  2016-04-24 18:57 ` Leo Famulari
  2016-04-28 11:56 ` Ludovic Courtès
  2 siblings, 0 replies; 20+ messages in thread
From: Danny Milosavljevic @ 2016-04-24 16:00 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: guix-devel

Hi,

I've always like the Gentoo approach most. Have a qualified package name like

  dev-java/ant

and if you try to install "ant" and it's unique: good.
If you try to install "ant" and there are multiple ones: you get a disambiguation error.
If you try to install "dev-java/ant" there's no ambiguity.

I'm aware that it's not implemented that way in "guix package" right now, however it would be easy to use the Guile module system for that end.  

Things like this are always easy to add later as long nobody make the package name "java-ant" which would make the qualified name

  dev-java/java-ant

which isn't so nice.

That said, Guix is not Gentoo. 

Directory hierarchies have never had a problem doing such categorization. Special-casing "xx-xxx" to be a poor man's directory feels... wrong.

That said, many package managers do it the "xx-xxx" way (and many don't).

Compare the input dependencies of a package

  (define java-maven
    (package
       (inputs '(("java-jvm" ,java-jvm)
                 ("java-xyz" ,java-xzy)
                 ("java-abc" ,java-abc)))))

Very redundant, no?

This kind of disambiguation is exactly what the module system can do best - and Guile's module system even allows you to add a prefix to all names when importing a module, so you can have the best of both choices.

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

* Re: Proposal: Prefix language-name for language library packages
  2016-04-24 13:22 Hartmut Goebel
  2016-04-24 16:00 ` Danny Milosavljevic
@ 2016-04-24 18:57 ` Leo Famulari
  2016-04-24 22:13   ` Hartmut Goebel
  2016-04-28 11:48   ` Ludovic Courtès
  2016-04-28 11:56 ` Ludovic Courtès
  2 siblings, 2 replies; 20+ messages in thread
From: Leo Famulari @ 2016-04-24 18:57 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: guix-devel

On Sun, Apr 24, 2016 at 03:22:03PM +0200, Hartmut Goebel wrote:
> Hi,
> 
> I propose to generalizing the specification [1,2] as we already have for
> Perl, Python and Java for most programming languages. In short:
> 
> Package names should be prefixed with the name of the language and if
> the package name already contains the name of the language, it gets
> removed there.
> 
> I quickly scanned the current package definitions and found:
> 
> guile: 2 package to change
> haskell: ca. 2 package to be changed
> julia: 0
> d (lcd.xscm): 0
> nqc (lego.scm): 0 --> prefix "lego-"? OTOH this is a commercial brand
> lua: 0
> m4: 0
> ocaml: 1
> ruby: 0
> r (statistics.scm): 0
> scheme: 1 or 2
> smalltalk: 0
> tcl: 0

What about C? Do we need c-linux-libre? ;)

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

* Re: Proposal: Prefix language-name for language library packages
  2016-04-24 18:57 ` Leo Famulari
@ 2016-04-24 22:13   ` Hartmut Goebel
  2016-04-28 11:48   ` Ludovic Courtès
  1 sibling, 0 replies; 20+ messages in thread
From: Hartmut Goebel @ 2016-04-24 22:13 UTC (permalink / raw)
  To: guix-devel

Am 24.04.2016 um 20:57 schrieb Leo Famulari:
> What about C? Do we need c-linux-libre? ;)

Oh, you hit the weak point of this proposal: I can not formulate a rule,
why e.g. libsodium does not need to be prefixed by "c-". And what about
c++ libraries? Maybe the main difference is that one can not (or only
hardly) use some (let's say) ruby package in C, whereas the other way
round is not much of a problem.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

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

* Re: Proposal: Prefix language-name for language library packages
@ 2016-04-28  8:45 alírio eyng
  2016-04-29 18:31 ` alírio eyng
  0 siblings, 1 reply; 20+ messages in thread
From: alírio eyng @ 2016-04-28  8:45 UTC (permalink / raw)
  To: guix-devel

Hartmut Goebel:
>Am 24.04.2016 um 20:57 schrieb Leo Famulari:
>> What about C? Do we need c-linux-libre?
...
>why e.g. libsodium does not need to be prefixed by "c-"
the c bias is unix heritage.

c-linux-libre-headers is good to contrast with cl-hurd[0] or pyhurd[1]
similarly there are cryptography libraries for other languages[2]

i agree to prefix every package which only interface is for a specific
programming language.

[0]http://www.gnu.org/software/hurd/user/flaviocruz.html
[1]http://savannah.nongnu.org/projects/pyhurd/
[2]https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries#Cryptography_libraries_and_their_origin

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

* Re: Proposal: Prefix language-name for language library packages
  2016-04-24 18:57 ` Leo Famulari
  2016-04-24 22:13   ` Hartmut Goebel
@ 2016-04-28 11:48   ` Ludovic Courtès
  1 sibling, 0 replies; 20+ messages in thread
From: Ludovic Courtès @ 2016-04-28 11:48 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

Leo Famulari <leo@famulari.name> skribis:

> On Sun, Apr 24, 2016 at 03:22:03PM +0200, Hartmut Goebel wrote:
>> Hi,
>> 
>> I propose to generalizing the specification [1,2] as we already have for
>> Perl, Python and Java for most programming languages. In short:
>> 
>> Package names should be prefixed with the name of the language and if
>> the package name already contains the name of the language, it gets
>> removed there.
>> 
>> I quickly scanned the current package definitions and found:
>> 
>> guile: 2 package to change
>> haskell: ca. 2 package to be changed
>> julia: 0
>> d (lcd.xscm): 0
>> nqc (lego.scm): 0 --> prefix "lego-"? OTOH this is a commercial brand
>> lua: 0
>> m4: 0
>> ocaml: 1
>> ruby: 0
>> r (statistics.scm): 0
>> scheme: 1 or 2
>> smalltalk: 0
>> tcl: 0
>
> What about C? Do we need c-linux-libre? ;)

Furthermore, what about multiple-language packages?  I’m thinking of
‘c+guile-guile’ and ‘c+siod+python-gimp’.

;-)

Ludo’.

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

* Re: Proposal: Prefix language-name for language library packages
  2016-04-24 13:22 Hartmut Goebel
  2016-04-24 16:00 ` Danny Milosavljevic
  2016-04-24 18:57 ` Leo Famulari
@ 2016-04-28 11:56 ` Ludovic Courtès
  2016-04-28 16:04   ` Leo Famulari
  2 siblings, 1 reply; 20+ messages in thread
From: Ludovic Courtès @ 2016-04-28 11:56 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: guix-devel

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> I propose to generalizing the specification [1,2] as we already have for
> Perl, Python and Java for most programming languages. In short:
>
> Package names should be prefixed with the name of the language and if
> the package name already contains the name of the language, it gets
> removed there.
>
> I quickly scanned the current package definitions and found:
>
> guile: 2 package to change
> haskell: ca. 2 package to be changed
> julia: 0
> d (lcd.xscm): 0
> nqc (lego.scm): 0 --> prefix "lego-"? OTOH this is a commercial brand
> lua: 0
> m4: 0
> ocaml: 1
> ruby: 0
> r (statistics.scm): 0
> scheme: 1 or 2

What do you mean by “scheme”?  Scheme packages are usually not
interchangeable among Scheme implementations, so we’d have
guile != racket != MIT Scheme, etc.

> smalltalk: 0
> tcl: 0

I’m all for it, especially given that this is pretty much the status
quo.  :-)

So, patches welcome for the 5-or-so packages above.

A common exception to the rule is packages that offer a CLI/GUI that is
a common entry point to the package–e.g., Guix, Unison, patches, Pius,
Xmonad, Awesome.  IOW, the rule would apply to libraries only.

There may be other cases where it’d be useful to make exceptions.

Thoughts?

Ludo’.

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

* Re: Proposal: Prefix language-name for language library packages
  2016-04-28 11:56 ` Ludovic Courtès
@ 2016-04-28 16:04   ` Leo Famulari
  0 siblings, 0 replies; 20+ messages in thread
From: Leo Famulari @ 2016-04-28 16:04 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

On Thu, Apr 28, 2016 at 01:56:15PM +0200, Ludovic Courtès wrote:
> Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:
> 
> > I propose to generalizing the specification [1,2] as we already have for
> > Perl, Python and Java for most programming languages. In short:
> >
> > Package names should be prefixed with the name of the language and if
> > the package name already contains the name of the language, it gets
> > removed there.
> >
> > I quickly scanned the current package definitions and found:
> >
> > guile: 2 package to change
> > haskell: ca. 2 package to be changed
> > julia: 0
> > d (lcd.xscm): 0
> > nqc (lego.scm): 0 --> prefix "lego-"? OTOH this is a commercial brand
> > lua: 0
> > m4: 0
> > ocaml: 1
> > ruby: 0
> > r (statistics.scm): 0
> > scheme: 1 or 2
> 
> What do you mean by “scheme”?  Scheme packages are usually not
> interchangeable among Scheme implementations, so we’d have
> guile != racket != MIT Scheme, etc.
> 
> > smalltalk: 0
> > tcl: 0
> 
> I’m all for it, especially given that this is pretty much the status
> quo.  :-)
> 
> So, patches welcome for the 5-or-so packages above.
> 
> A common exception to the rule is packages that offer a CLI/GUI that is
> a common entry point to the package–e.g., Guix, Unison, patches, Pius,
> Xmonad, Awesome.  IOW, the rule would apply to libraries only.

Yes, it makes sense for libraries that are "tied" to their language. Of
course:

> There may be other cases where it’d be useful to make exceptions.

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

* Re: Proposal: Prefix language-name for language library packages
  2016-04-28  8:45 Proposal: Prefix language-name for language library packages alírio eyng
@ 2016-04-29 18:31 ` alírio eyng
  2016-04-29 23:36   ` Leo Famulari
  0 siblings, 1 reply; 20+ messages in thread
From: alírio eyng @ 2016-04-29 18:31 UTC (permalink / raw)
  To: guix-devel

Ludovic Courtès:
>what about multiple-language packages?  I’m thinking of
>‘c+guile-guile’ and ‘c+siod+python-gimp’.
the ideal categorization would be one output for each interface.
so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
"gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
"emacs -batch -eval").
e.g. guile:c and emacs:tui are pretty useless for me, so i could not
install them.
it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
and "emacs:no-gui" (tui+elisp), linux-libre, ...

c nomenclature:
packages with c interface currently have nothing, "lib" (prefix or
postfix), "c-", "-c", "4c" or "-headers".
e.g. "readline" "libunistring" "htslib" "c-ares" "json-c" "icu4c"
"mesa-headers" "linux-libre-headers".
and lots of synopses with nothing, "C library for", "C library
providing", "C library to", "implementation in C" or "written in C".

this would be consistent with trisquel:
"libreadline-dev" "libunistring-dev" "libhts-dev" "libc-ares-dev"
"libjson-c-dev" "libicu-dev" "libmesa-dev" (and "libmesa")
"linux-libre-image" (and "linux-libre-libc-dev" or
"linux-libre-headers").

suggestions:
be consistent with other languages:
"c-readline" "c-unistring" "c-hts" "c-ares" "c-json" "c-icu" "c-mesa"
(hide the runtime) "linux-libre" (and "linux-libre:c"; actually the
system would use "linux-libre-old:c" to keep current semantics).
remove this information from synopses (or standardize to all).

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

* Re: Proposal: Prefix language-name for language library packages
  2016-04-29 18:31 ` alírio eyng
@ 2016-04-29 23:36   ` Leo Famulari
  2016-04-30  6:38     ` Ricardo Wurmus
  2016-05-01  3:00     ` alírio eyng
  0 siblings, 2 replies; 20+ messages in thread
From: Leo Famulari @ 2016-04-29 23:36 UTC (permalink / raw)
  To: alírio eyng; +Cc: guix-devel

On Fri, Apr 29, 2016 at 06:31:24PM +0000, alírio eyng wrote:
> Ludovic Courtès:
> >what about multiple-language packages?  I’m thinking of
> >‘c+guile-guile’ and ‘c+siod+python-gimp’.
> the ideal categorization would be one output for each interface.
> so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
> "gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
> "emacs -batch -eval").
> e.g. guile:c and emacs:tui are pretty useless for me, so i could not
> install them.
> it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
> and "emacs:no-gui" (tui+elisp), linux-libre, ...

I don't think we should split packages up unless there is a pressing
reason to do it. For example, some our packages have a rarely-used
component that uses a lot of disk space or has a very large dependency.
It makes sense to put those in different outputs.

But if we go too far, nobody will be able to tell which package to
install to accomplish their task.

> c nomenclature:
> packages with c interface currently have nothing, "lib" (prefix or
> postfix), "c-", "-c", "4c" or "-headers".
> e.g. "readline" "libunistring" "htslib" "c-ares" "json-c" "icu4c"
> "mesa-headers" "linux-libre-headers".
> and lots of synopses with nothing, "C library for", "C library
> providing", "C library to", "implementation in C" or "written in C".

Again, unless some package's headers take up a large amount of disk
space, or have some other onerous cost, I don't see a reason to put them
in a separate output.

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

* Re: Proposal: Prefix language-name for language library packages
  2016-04-29 23:36   ` Leo Famulari
@ 2016-04-30  6:38     ` Ricardo Wurmus
  2016-05-02  7:50       ` Ludovic Courtès
  2016-05-01  3:00     ` alírio eyng
  1 sibling, 1 reply; 20+ messages in thread
From: Ricardo Wurmus @ 2016-04-30  6:38 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel, alírio eyng


Leo Famulari <leo@famulari.name> writes:

> On Fri, Apr 29, 2016 at 06:31:24PM +0000, alírio eyng wrote:
>> Ludovic Courtès:
>> >what about multiple-language packages?  I’m thinking of
>> >‘c+guile-guile’ and ‘c+siod+python-gimp’.
>> the ideal categorization would be one output for each interface.
>> so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
>> "gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
>> "emacs -batch -eval").
>> e.g. guile:c and emacs:tui are pretty useless for me, so i could not
>> install them.
>> it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
>> and "emacs:no-gui" (tui+elisp), linux-libre, ...
>
> I don't think we should split packages up unless there is a pressing
> reason to do it. For example, some our packages have a rarely-used
> component that uses a lot of disk space or has a very large dependency.
> It makes sense to put those in different outputs.
>
> But if we go too far, nobody will be able to tell which package to
> install to accomplish their task.

I agree.  I’d like to only split up packages when the effort is
justified.

>> c nomenclature:
>> packages with c interface currently have nothing, "lib" (prefix or
>> postfix), "c-", "-c", "4c" or "-headers".
>> e.g. "readline" "libunistring" "htslib" "c-ares" "json-c" "icu4c"
>> "mesa-headers" "linux-libre-headers".
>> and lots of synopses with nothing, "C library for", "C library
>> providing", "C library to", "implementation in C" or "written in C".
>
> Again, unless some package's headers take up a large amount of disk
> space, or have some other onerous cost, I don't see a reason to put them
> in a separate output.

It also isn’t necessarily practical to do so.

~~ Ricardo

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

* Re: Proposal: Prefix language-name for language library packages
  2016-04-29 23:36   ` Leo Famulari
  2016-04-30  6:38     ` Ricardo Wurmus
@ 2016-05-01  3:00     ` alírio eyng
  1 sibling, 0 replies; 20+ messages in thread
From: alírio eyng @ 2016-05-01  3:00 UTC (permalink / raw)
  To: leo; +Cc: guix-devel

On 4/29/16, Leo Famulari <leo@famulari.name> wrote:
> On Fri, Apr 29, 2016 at 06:31:24PM +0000, alírio eyng wrote:
>> Ludovic Courtès:
>> >what about multiple-language packages?  I’m thinking of
>> >‘c+guile-guile’ and ‘c+siod+python-gimp’.
>> the ideal categorization would be one output for each interface.
>> so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
>> "gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
>> "emacs -batch -eval").
>> e.g. guile:c and emacs:tui are pretty useless for me, so i could not
>> install them.
>> it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
>> and "emacs:no-gui" (tui+elisp), linux-libre, ...
>
> I don't think we should split packages up unless there is a pressing
> reason to do it. For example, some our packages have a rarely-used
> component that uses a lot of disk space or has a very large dependency.
> It makes sense to put those in different outputs.
>
> But if we go too far, nobody will be able to tell which package to
> install to accomplish their task.
defining "too far" is a problem, but ok.
in the end splitting things (in packages or outputs) is just an
optimization; with unlimited resources we could just install
everything (ignoring security, untracked dependencies, ...).
note the difference between "ideal categorization" to answer about
multiple-language packages and "suggestions" (that i want
implemented).

>> c nomenclature:
>> packages with c interface currently have nothing, "lib" (prefix or
>> postfix), "c-", "-c", "4c" or "-headers".
>> e.g. "readline" "libunistring" "htslib" "c-ares" "json-c" "icu4c"
>> "mesa-headers" "linux-libre-headers".
>> and lots of synopses with nothing, "C library for", "C library
>> providing", "C library to", "implementation in C" or "written in C".
>
> Again, unless some package's headers take up a large amount of disk
> space, or have some other onerous cost, I don't see a reason to put them
> in a separate output.
note the "currently"; mesa and linux-libre (and emacs) are _already_
split in packages, so a reason should exist.
linux-libre-headers seems to avoid rebuilds.
i guess in mesa the runtime has some onerous cost (probably disk space).
splitting in outputs would be cleaner, and probably more efficient on hydra.
but mesa and linux-libre are corner cases, which my suggestion was
comprehensive enough to handle.

the point is trisquel has a standardized way to express c interface in
names (lib*-dev), guix doesn't; there's lot of evidence it would be
useful (eleven non-standardized ways).

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

* Re: Proposal: Prefix language-name for language library packages
  2016-04-30  6:38     ` Ricardo Wurmus
@ 2016-05-02  7:50       ` Ludovic Courtès
  2016-05-02  9:33         ` ng0
  2016-05-02 18:33         ` Leo Famulari
  0 siblings, 2 replies; 20+ messages in thread
From: Ludovic Courtès @ 2016-05-02  7:50 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, alírio eyng

Ricardo Wurmus <rekado@elephly.net> skribis:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Fri, Apr 29, 2016 at 06:31:24PM +0000, alírio eyng wrote:
>>> Ludovic Courtès:
>>> >what about multiple-language packages?  I’m thinking of
>>> >‘c+guile-guile’ and ‘c+siod+python-gimp’.
>>> the ideal categorization would be one output for each interface.
>>> so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
>>> "gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
>>> "emacs -batch -eval").
>>> e.g. guile:c and emacs:tui are pretty useless for me, so i could not
>>> install them.
>>> it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
>>> and "emacs:no-gui" (tui+elisp), linux-libre, ...
>>
>> I don't think we should split packages up unless there is a pressing
>> reason to do it. For example, some our packages have a rarely-used
>> component that uses a lot of disk space or has a very large dependency.
>> It makes sense to put those in different outputs.
>>
>> But if we go too far, nobody will be able to tell which package to
>> install to accomplish their task.
>
> I agree.  I’d like to only split up packages when the effort is
> justified.

Agreed.

FWIW, until recently Nixpkgs didn’t use multiple outputs much (info
"(guix) Packages with Multiple Outputs").  Lately they merged a change
to use them very aggressively.  So for instance, GNU libidn, which takes
800 KiB in total, has no less than 5 outputs:

  https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/libidn/default.nix

I think this is going a bit too far.  :-)

I think the approach should be to profile packages with ‘guix size’ and
to act mostly on a case-by-case basis.

Ludo’.

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

* Re: Proposal: Prefix language-name for language library packages
  2016-05-02  7:50       ` Ludovic Courtès
@ 2016-05-02  9:33         ` ng0
  2016-05-02 18:33         ` Leo Famulari
  1 sibling, 0 replies; 20+ messages in thread
From: ng0 @ 2016-05-02  9:33 UTC (permalink / raw)
  To: guix-devel

ludo@gnu.org (Ludovic Courtès) writes:

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Leo Famulari <leo@famulari.name> writes:
>>
>>> On Fri, Apr 29, 2016 at 06:31:24PM +0000, alírio eyng wrote:
>>>> Ludovic Courtès:
>>>> >what about multiple-language packages?  I’m thinking of
>>>> >‘c+guile-guile’ and ‘c+siod+python-gimp’.
>>>> the ideal categorization would be one output for each interface.
>>>> so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
>>>> "gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
>>>> "emacs -batch -eval").
>>>> e.g. guile:c and emacs:tui are pretty useless for me, so i could not
>>>> install them.
>>>> it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
>>>> and "emacs:no-gui" (tui+elisp), linux-libre, ...
>>>
>>> I don't think we should split packages up unless there is a pressing
>>> reason to do it. For example, some our packages have a rarely-used
>>> component that uses a lot of disk space or has a very large dependency.
>>> It makes sense to put those in different outputs.
>>>
>>> But if we go too far, nobody will be able to tell which package to
>>> install to accomplish their task.
>>
>> I agree.  I’d like to only split up packages when the effort is
>> justified.
>
> Agreed.
>
> FWIW, until recently Nixpkgs didn’t use multiple outputs much (info
> "(guix) Packages with Multiple Outputs").  Lately they merged a change
> to use them very aggressively.  So for instance, GNU libidn, which takes
> 800 KiB in total, has no less than 5 outputs:
>
>   https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/libidn/default.nix
>
> I think this is going a bit too far.  :-)
>
> I think the approach should be to profile packages with ‘guix size’ and
> to act mostly on a case-by-case basis.
>
> Ludo’.
>

To add my thoughts on this:

I think multiple language packages could be nice, but they could
also make getting into packaging incredible harder. Currently it
is very accessible and modular.
It would also introduce labeling problems and discussions, does
someone see it's mainly this and that language? Do we then decide
on the order of $lang in $lang+$lang+$lang-$package or do we
waste our times with individual package discussions and
preferences and also when to split up or not?
If we decide on something, it should be covering all
possibilities and minimize discussions which might arise from
it.


If we decide on one thing now we don't have to stick to it for
all eternity, it can change later if we see it doesn't work out
anymore.


Gentoo used to have herds, project groups for certain big or
themed projects. In the last council meeting they decided that
herds are no longer needed and wanted by the community, so they
are splitting them up.

-- 
♥Ⓐ ng0

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

* Re: Proposal: Prefix language-name for language library packages
  2016-05-02  7:50       ` Ludovic Courtès
  2016-05-02  9:33         ` ng0
@ 2016-05-02 18:33         ` Leo Famulari
  2016-05-06  2:45           ` alírio eyng
  1 sibling, 1 reply; 20+ messages in thread
From: Leo Famulari @ 2016-05-02 18:33 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, alírio eyng

On Mon, May 02, 2016 at 09:50:43AM +0200, Ludovic Courtès wrote:
> FWIW, until recently Nixpkgs didn’t use multiple outputs much (info
> "(guix) Packages with Multiple Outputs").  Lately they merged a change
> to use them very aggressively.  So for instance, GNU libidn, which takes
> 800 KiB in total, has no less than 5 outputs:
> 
>   https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/libidn/default.nix
> 
> I think this is going a bit too far.  :-)

I agree. The time spent by humans figuring out which output to use will
probably never be "earned back" by the bandwidth and disk savings in
that case.

> I think the approach should be to profile packages with ‘guix size’ and
> to act mostly on a case-by-case basis.

Case-by-case, as with most things!

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

* Re: Proposal: Prefix language-name for language library packages
  2016-05-02 18:33         ` Leo Famulari
@ 2016-05-06  2:45           ` alírio eyng
  2016-05-06  6:49             ` Ricardo Wurmus
  2016-05-06 20:12             ` Andreas Enge
  0 siblings, 2 replies; 20+ messages in thread
From: alírio eyng @ 2016-05-06  2:45 UTC (permalink / raw)
  To: guix-devel

i suggested renaming:
readline, libunistring, htslib, c-ares, json-c, icu4c, ...
to:
c-readline, c-unistring, c-hts, c-ares, c-json, c-icu, ...

no replies, is that implicit agreement?

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

* Re: Proposal: Prefix language-name for language library packages
  2016-05-06  2:45           ` alírio eyng
@ 2016-05-06  6:49             ` Ricardo Wurmus
  2016-05-06 10:20               ` Ludovic Courtès
  2016-05-06 20:12             ` Andreas Enge
  1 sibling, 1 reply; 20+ messages in thread
From: Ricardo Wurmus @ 2016-05-06  6:49 UTC (permalink / raw)
  To: alírio eyng; +Cc: guix-devel


alírio eyng <alirioeyng@gmail.com> writes:

> i suggested renaming:
> readline, libunistring, htslib, c-ares, json-c, icu4c, ...
> to:
> c-readline, c-unistring, c-hts, c-ares, c-json, c-icu, ...
>
> no replies, is that implicit agreement?

I strongly disagree with this as it makes things needlessly confusing,
in my opinion.

It was fine to discuss this for Java as we only had a handful of Java
packages, but I don’t think it’s reasonable to do this for C and C++
stuff at all.

~~ Ricardo

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

* Re: Proposal: Prefix language-name for language library packages
  2016-05-06  6:49             ` Ricardo Wurmus
@ 2016-05-06 10:20               ` Ludovic Courtès
  0 siblings, 0 replies; 20+ messages in thread
From: Ludovic Courtès @ 2016-05-06 10:20 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, alírio eyng

Ricardo Wurmus <rekado@elephly.net> skribis:

> alírio eyng <alirioeyng@gmail.com> writes:
>
>> i suggested renaming:
>> readline, libunistring, htslib, c-ares, json-c, icu4c, ...
>> to:
>> c-readline, c-unistring, c-hts, c-ares, c-json, c-icu, ...
>>
>> no replies, is that implicit agreement?
>
> I strongly disagree with this as it makes things needlessly confusing,
> in my opinion.

+1

We joked about adding this “c-” prefix earlier in this discussion, but
that’s really just a joke.

Thanks,
Ludo’.

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

* Re: Proposal: Prefix language-name for language library packages
  2016-05-06  2:45           ` alírio eyng
  2016-05-06  6:49             ` Ricardo Wurmus
@ 2016-05-06 20:12             ` Andreas Enge
  2016-05-07  0:32               ` John Darrington
  1 sibling, 1 reply; 20+ messages in thread
From: Andreas Enge @ 2016-05-06 20:12 UTC (permalink / raw)
  To: alírio eyng; +Cc: guix-devel

On Fri, May 06, 2016 at 02:45:48AM +0000, alírio eyng wrote:
> i suggested renaming:
> readline, libunistring, htslib, c-ares, json-c, icu4c, ...
> to:
> c-readline, c-unistring, c-hts, c-ares, c-json, c-icu, ...
> no replies, is that implicit agreement?

I did not follow the discussion in all its details, but thought this part
was an obvious joke to illustrate the limits of the suggestion...
C being the natural GNU language and C++ its extension, I see no reason
to emphasise that a package is written in C.

Part of why we added a language prefix (for perl, I think, or maybe python
came first?) was also that the libraries had rather generic names. There
is perl-error, perl-html-form, perl-json and so on (not to speak of
perl-xyz containing bindings to some C library called xyz); we feared there
would be many collisions with existing C libraries and tools or further
interpreted languages.

Andreas

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

* Re: Proposal: Prefix language-name for language library packages
  2016-05-06 20:12             ` Andreas Enge
@ 2016-05-07  0:32               ` John Darrington
  0 siblings, 0 replies; 20+ messages in thread
From: John Darrington @ 2016-05-07  0:32 UTC (permalink / raw)
  To: Andreas Enge; +Cc: guix-devel, al?rio eyng

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

On Fri, May 06, 2016 at 10:12:14PM +0200, Andreas Enge wrote:
     On Fri, May 06, 2016 at 02:45:48AM +0000, al?rio eyng wrote:
     > i suggested renaming:
     > readline, libunistring, htslib, c-ares, json-c, icu4c, ...
     > to:
     > c-readline, c-unistring, c-hts, c-ares, c-json, c-icu, ...
     > no replies, is that implicit agreement?
     
     I did not follow the discussion in all its details, but thought this part
     was an obvious joke to illustrate the limits of the suggestion...
     C being the natural GNU language and C++ its extension, I see no reason
     to emphasise that a package is written in C.
     
     Part of why we added a language prefix (for perl, I think, or maybe python
     came first?) was also that the libraries had rather generic names. There
     is perl-error, perl-html-form, perl-json and so on (not to speak of
     perl-xyz containing bindings to some C library called xyz); we feared there
     would be many collisions with existing C libraries and tools or further
     interpreted languages.
     
     
Some packages already have rediculously long names.  I don't see a need to make them 
longer.  In fact, I would like to make some of them shorter.  For example:

perl-moosex-emulate-class-accessor-fast 
perl-catalyst-plugin-authorization-roles
perl-catalyst-traitfor-request-proxybase
perl-moosex-types-datetime-morecoercions
perl-catalyst-plugin-session-state-cookie
perl-plack-middleware-removeredundantbody 
perl-catalyst-component-instancepercontext
perl-catalyst-plugin-session-store-fastmmap
perl-catalyst-authentication-store-dbix-class
perl-plack-middleware-fixmissingbodyinredirect


J'

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

end of thread, other threads:[~2016-05-07  0:33 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-28  8:45 Proposal: Prefix language-name for language library packages alírio eyng
2016-04-29 18:31 ` alírio eyng
2016-04-29 23:36   ` Leo Famulari
2016-04-30  6:38     ` Ricardo Wurmus
2016-05-02  7:50       ` Ludovic Courtès
2016-05-02  9:33         ` ng0
2016-05-02 18:33         ` Leo Famulari
2016-05-06  2:45           ` alírio eyng
2016-05-06  6:49             ` Ricardo Wurmus
2016-05-06 10:20               ` Ludovic Courtès
2016-05-06 20:12             ` Andreas Enge
2016-05-07  0:32               ` John Darrington
2016-05-01  3:00     ` alírio eyng
  -- strict thread matches above, loose matches on Subject: below --
2016-04-24 13:22 Hartmut Goebel
2016-04-24 16:00 ` Danny Milosavljevic
2016-04-24 18:57 ` Leo Famulari
2016-04-24 22:13   ` Hartmut Goebel
2016-04-28 11:48   ` Ludovic Courtès
2016-04-28 11:56 ` Ludovic Courtès
2016-04-28 16:04   ` Leo Famulari

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.