Re: distinguishing between applications and libraries

2019-07-05 Thread Ludovic Courtès
Hi, Robert Vollmert 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’.

Re: distinguishing between applications and libraries

2019-07-02 Thread Jakob L. Kreuze
Ricardo Wurmus 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 “gc

Re: distinguishing between applications and libraries

2019-07-02 Thread zimoun
Hi, On Tue, 2 Jul 2019 at 15:35, Robert Vollmert wrote: > > On 1. Jul 2019, at 23:48, Ricardo Wurmus 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

Re: distinguishing between applications and libraries

2019-07-02 Thread Robert Vollmert
> On 1. Jul 2019, at 23:48, Ricardo Wurmus 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 wou

Re: distinguishing between applications and libraries

2019-07-02 Thread Ricardo Wurmus
Pierre Neidhardt writes: > Ricardo Wurmus 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

Re: distinguishing between applications and libraries

2019-07-02 Thread 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 th

Re: distinguishing between applications and libraries

2019-07-01 Thread Jakob L. Kreuze
Hi, Robert and Pierre, Robert Vollmert writes: >> On 30. Jun 2019, at 20:01, Pierre Neidhardt 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. > >

Re: distinguishing between applications and libraries

2019-07-01 Thread Pierre Neidhardt
Ricardo Wurmus 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/ signature.asc Description: PGP signature

Re: distinguishing between applications and libraries

2019-07-01 Thread 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 executab

Re: distinguishing between applications and libraries

2019-07-01 Thread Ricardo Wurmus
Pierre Neidhardt writes: > Robert Vollmert 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 s

Re: distinguishing between applications and libraries

2019-07-01 Thread Pierre Neidhardt
> In fact, why not *use* Debian's command-not-found handler. I like it! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature

Re: distinguishing between applications and libraries

2019-07-01 Thread Danny Milosavljevic
Hi, On Sun, 30 Jun 2019 19:33:55 +0200 Robert Vollmert 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 bo

Re: distinguishing between applications and libraries

2019-06-30 Thread Pierre Neidhardt
Robert Vollmert 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

Re: distinguishing between applications and libraries

2019-06-30 Thread Robert Vollmert
> On 30. Jun 2019, at 20:01, Pierre Neidhardt 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

Re: distinguishing between applications and libraries

2019-06-30 Thread Pierre Neidhardt
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