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

distinguishing between applications and libraries

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