distinguishing between applications and libraries

distinguishing between applications and libraries

[Robert Vollmert]

Hi,

I’m currently packaging some tools that would add a decent
amount of source-only dependencies. (Some from npm, some for
elm).

Clearly they should somehow be packaged properly in order
to track licensing information and refer to upstream. On the
other hand, it doesn’t feel particularly useful to add a
number of packages that no user is ever going to want to
install (or even search for) by hand.

Has it been considered to track applications and libraries
separately? Along the lines of:

- package definitions could have a `type` field, or a `library`
  flag or similar
- `guix search` would ignore library packages by default
- maybe there’s some other simplifications to make in library
  package definitions? I’d be happy to not copy over a
  long description that no-one’s ever going to read. :)

Cheers
Robert

Re: distinguishing between applications and libraries

[Pierre Neidhardt]

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

Hi Robert!

`guix search` and other user-facing tools ignore non-exported packages.

So you can simply use `define` instead of `define-public` to declare a
package.

For instance:

--8<---------------cut here---------------start------------->8---
(define my-package
  ...
  )
--8<---------------cut here---------------end--------------->8---

> - maybe there’s some other simplifications to make in library
>   package definitions? I’d be happy to not copy over a
>   long description that no-one’s ever going to read. :)

The description does not have to be long, in fact it can be just one
line, but it just explain what the package is here for.  Even if it is
not exposed to the user, package maintainers will want to know why it's
here.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: distinguishing between applications and libraries

[Robert Vollmert]

> On 30. Jun 2019, at 20:01, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> 
> Hi Robert!
> 
> `guix search` and other user-facing tools ignore non-exported packages.
> 
> So you can simply use `define` instead of `define-public` to declare a
> package.

Good point, but that breaks down once a library is used by a package
outside that module. E.g. consider the various ghc-* packages. Running
“guix search clock” returns `ghc-clock` and `ocaml-mtime`. The first
needs to be public since it’s used elsewhere, the second is defined
as public anyway. Should that change?

>> - maybe there’s some other simplifications to make in library
>>  package definitions? I’d be happy to not copy over a
>>  long description that no-one’s ever going to read. :)
> 
> The description does not have to be long, in fact it can be just one
> line, but it just explain what the package is here for.  Even if it is
> not exposed to the user, package maintainers will want to know why it's
> here.

Well the real reason why it’s there lies in its reverse dependencies, no?

Robert

Re: distinguishing between applications and libraries

[Pierre Neidhardt]

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

Robert Vollmert <rob@vllmrt.net> writes:

> Good point, but that breaks down once a library is used by a package
> outside that module. E.g. consider the various ghc-* packages. Running
> “guix search clock” returns `ghc-clock` and `ocaml-mtime`. The first
> needs to be public since it’s used elsewhere, the second is defined
> as public anyway. Should that change?

If you need to depend on a non-exported package, you can still
access it with

  (@@ (gnu packages my-module) my-package)

> Well the real reason why it’s there lies in its reverse dependencies, no?

A library always does something, so this is what you need to explain in
the description.  Unfortunately some authors don't always provide any
description for their work, in which case you might have to look at the
source :p

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: distinguishing between applications and libraries

[Danny Milosavljevic]

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

Hi,

On Sun, 30 Jun 2019 19:33:55 +0200
Robert Vollmert <rob@vllmrt.net> wrote:

> Has it been considered to track applications and libraries
> separately? Along the lines of:
> 
> - package definitions could have a `type` field, or a `library`
>   flag or similar

There are also a lot of packages which provide both a library and an
application.

> - `guix search` would ignore library packages by default

Well in the end it just depends whether the derivation has things in "bin" or
not, right?

Long term, we should have something like Debian's command-not-found handler
which automatically searches for the packages that would contain the command
if trying to invoke one which isn't installed.

In fact, why not *use* Debian's command-not-found handler.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: distinguishing between applications and libraries

[Pierre Neidhardt]

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

> In fact, why not *use* Debian's command-not-found handler.

I like it!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: distinguishing between applications and libraries

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Robert Vollmert <rob@vllmrt.net> writes:
>
>> Good point, but that breaks down once a library is used by a package
>> outside that module. E.g. consider the various ghc-* packages. Running
>> “guix search clock” returns `ghc-clock` and `ocaml-mtime`. The first
>> needs to be public since it’s used elsewhere, the second is defined
>> as public anyway. Should that change?
>
> If you need to depend on a non-exported package, you can still
> access it with
>
>   (@@ (gnu packages my-module) my-package)

Nah, it’s not good to do this.  The use of @@ is an anti-pattern.

To completely hide a package from the UI use “hidden-package” or
“(properties ((hidden . #t)))”.

-- 
Ricardo

Re: distinguishing between applications and libraries

[Ricardo Wurmus]

Hi Robert,

> Has it been considered to track applications and libraries
> separately? Along the lines of:
>
> - package definitions could have a `type` field, or a `library`
>   flag or similar

This dichotomy falls apart with many bioinformatics packages that
provide both libraries and executables, where neither of the two types
is prioritized.

> - `guix search` would ignore library packages by default

I think it’s valid for users to want to install libraries.  For Python,
for example, installing modules that don’t provide any executables
appears to be the norm.

--
Ricardo

Re: distinguishing between applications and libraries

[Pierre Neidhardt]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> To completely hide a package from the UI use “hidden-package” or
> “(properties ((hidden . #t)))”.

This is great, didn't know that!  Is it in the manual?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: distinguishing between applications and libraries

[Jakob L. Kreuze]

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

Hi, Robert and Pierre,

Robert Vollmert <rob@vllmrt.net> writes:

>> On 30. Jun 2019, at 20:01, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
>> 
>> Hi Robert!
>> 
>> `guix search` and other user-facing tools ignore non-exported
>> packages.
>> 
>> So you can simply use `define` instead of `define-public` to declare
>> a package.
>
> Good point, but that breaks down once a library is used by a package
> outside that module. E.g. consider the various ghc-* packages. Running
> “guix search clock” returns `ghc-clock` and `ocaml-mtime`. The first
> needs to be public since it’s used elsewhere, the second is defined as
> public anyway. Should that change?

I took a shot at packaging bettercap[1] this weekend but decided to
finish it later after realizing how many dependencies would need to be
packaged... Ah, how I long for a 'go' importer.

But since we're having this conversation now, I'd like to ask: does it
make sense to use 'define-public' for dependencies like that? I'd be
adding a lot of 'go-github-com-...' packages like those in
'gnu/packages/syncthing.scm'.

[1]: https://www.bettercap.org/

Regards,
Jakob

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: distinguishing between applications and libraries

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> To completely hide a package from the UI use “hidden-package” or
>> “(properties ((hidden . #t)))”.
>
> This is great, didn't know that!  Is it in the manual?

Sadly, there are a lot of Guix API things missing from the manual.  I’d
love to see them all added.

-- 
Ricardo

Re: distinguishing between applications and libraries

[Ricardo Wurmus]

Hi Jakob,

> But since we're having this conversation now, I'd like to ask: does it
> make sense to use 'define-public' for dependencies like that? I'd be
> adding a lot of 'go-github-com-...' packages like those in
> 'gnu/packages/syncthing.scm'.

I’d use define-public for all packages unless there are good reasons not
to.  A good reason would be that the package *cannot* be used for
anything else (e.g. when it’s a custom variant of a library that would
otherwise be bundled but we decided to build it separately).

We hid “gcc” because users would install it instead of “gcc-toolchain”
and be surprised that it didn’t work.

I would not hide a package just because it is a less popular dependency
of some more popular tool.

--
Ricardo

Re: distinguishing between applications and libraries

[Robert Vollmert]

> On 1. Jul 2019, at 23:48, Ricardo Wurmus <rekado@elephly.net> wrote:
>> - `guix search` would ignore library packages by default
> 
> I think it’s valid for users to want to install libraries.  For Python,
> for example, installing modules that don’t provide any executables
> appears to be the norm.

The idea would be that

`guix search <topic>`

would find applications related to topic, while e.g.

`guix search [-l|--include-libraries] <topic>`

would include library packages. So installing libraries would still
be possible.

(It needn’t be a “application vs library” distinction either, it could
be “graphical vs command line” or “user vs development” or whatever.)

Robert

Re: distinguishing between applications and libraries

[zimoun]

Hi,

On Tue, 2 Jul 2019 at 15:35, Robert Vollmert <rob@vllmrt.net> wrote:
> > On 1. Jul 2019, at 23:48, Ricardo Wurmus <rekado@elephly.net> wrote:
> >> - `guix search` would ignore library packages by default
> >
> > I think it’s valid for users to want to install libraries.  For Python,
> > for example, installing modules that don’t provide any executables
> > appears to be the norm.
>
> The idea would be that
>
> `guix search <topic>`
>
> would find applications related to topic, while e.g.
>
> `guix search [-l|--include-libraries] <topic>`
>
> would include library packages. So installing libraries would still
> be possible.
>
> (It needn’t be a “application vs library” distinction either, it could
> be “graphical vs command line” or “user vs development” or whatever.)

I am always uncomfortable with the distinctions because there is
always corner cases. And where set the boundary?
For instance, is VLC graphical or command-line? I use both ways.

IMHO, a nice feature about `search` should to be able to use output
packages (binary name, library name, doc, etc.).
It has already been discussed here in the list (or the variant
proposed above by Danny).
To summary what I understood, the naive approach by adding a new field
containing the outputs name is too much work and prone error. It
should be better to collect automatically the outputs name. Therefore,
at build time, but then this kind of search is not local anymore---in
general we search something to install it, or at least it is not in
the store yet. It would remotely search with the substitutes.


All the best,
simon

Re: distinguishing between applications and libraries

[Jakob L. Kreuze]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> A good reason would be that the package *cannot* be used for anything
> else (e.g. when it’s a custom variant of a library that would
> otherwise be bundled but we decided to build it separately).

Ah, that's good to know for something else I'm packaging. :)

> We hid “gcc” because users would install it instead of “gcc-toolchain”
> and be surprised that it didn’t work.
>
> I would not hide a package just because it is a less popular
> dependency of some more popular tool.

Noted, thanks!

Regards,
Jakob

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: distinguishing between applications and libraries

[Ludovic Courtès]

Hi,

Robert Vollmert <rob@vllmrt.net> skribis:

> - `guix search` would ignore library packages by default

I don’t think that’s a viable approach: sometimes people search for
libraries, too.

Now ‘guix search’ could rates leaves of the graph higher, though I’m not
sure if it should be the default.

Thanks,
Ludo’.