Hello,
Pierre Neidhardt skribis:
> Thanks Nicolò, your feedback was very useful!
>
> So it's not program-not-found but command-not-found and it's define
> here:
>
>
> https://github.com/NixOS/nixpkgs/tree/master/nixos/modules/programs/command-not-found
>
> Then I found this
>
> https://gith
Thanks Nicolò, your feedback was very useful!
So it's not program-not-found but command-not-found and it's define
here:
https://github.com/NixOS/nixpkgs/tree/master/nixos/modules/programs/command-not-found
Then I found this
https://github.com/NixOS/nixos-channel-scripts
All this is pretty
Hi Pierre,
on NixOS, if you try to run the name of a program that you don't have
installed (eg: $ endlessh) you get:
The program ‘endlessh’ is currently not installed. You can install it by typing:
nix-env -iA nixos.endlessh
program-not-found is a perl script that uses an sqlite file placed
under
Pierre Neidhardt writes:
> Christopher Baines writes:
>
>>> Hmm, but this data relates to items in the store and online, they are
>>> global. Per-user would mean redundant packages and redundant (remote)
>>> queries.
>>
>> Yeah, maybe there's some way of optimising things for systems with
>>
Pierre Neidhardt writes:
> Christopher Baines writes:
>
>> Maybe sqlite is one to try initially. There's guile-sqlite3 for reading
>> and writing, and it can contain multiple tables as well as indexes for
>> fast searching.
>>
>>> Where would we store this database? In /var?
>>
>> Per user is
Pierre Neidhardt writes:
> Christopher Baines writes:
>
>> Not quite. As Ludo mentioned, you can trivially extract out the file
>> list from nar files already (like guix archive -t). So this new service
>> I'm thinking about which stores the nar files, would be able to read the
>> list of files
Pierre Neidhardt writes:
> Christopher Baines writes:
>
>> So, to elaborate a bit more on the architecture I've had in mind for
>> dealing with the actual nars…
>>
>> I see the scope of the Guix Data Service extending as far as what nars
>> are available for outputs, and what outputs are associ
On Thu, 9 Jan 2020 at 16:41, Pierre Neidhardt wrote:
>
> zimoun writes:
>
> >> The benefit of "/" is that it works _incidentally_. If you are looking
> >> for "bin/hg", then `guix search bin/hg` will do the right thing.
> >
> > I agree.
> >
> > To be clear, to search the binary 'hg', I find clea
On Thu, 9 Jan 2020 at 16:38, Pierre Neidhardt wrote:
> > I am looking for the file gmsh.h and I do not know nothing more.
>
> --8<---cut here---start->8---
> guix search /gmsh.h
> --8<---cut here---end--->8---
>
> would work.
Pierre Neidhardt writes:
>> I think the Guix Data Service is a good fit since it knows about
>> packages, derivations, commits, and how they map to each other. :-) It
>> could download nars and do the equivalent of ‘guix archive -t’ to get
>> the list of file names.
>
> Are you suggesting that
zimoun writes:
>> The benefit of "/" is that it works _incidentally_. If you are looking
>> for "bin/hg", then `guix search bin/hg` will do the right thing.
>
> I agree.
>
> To be clear, to search the binary 'hg', I find clearer "guix search bin/hg".
> However, to search any file which you do no
zimoun writes:
>> But for which benefit? It seems that this single example
>>
>> >> - guix search bin/gmsh gimp
>>
>> covers all your needs.
>
> No.
>
> For example:
>
>> >> - guix search file:gmsh.h gimp
>
> I am looking for the file gmsh.h and I do not know nothing more.
--8<---
On Thu, 9 Jan 2020 at 15:21, Pierre Neidhardt wrote:
> Why don't you like it?
You are like Haskellers or Perlers asking why ">>=" is not clear. :-)
I do not find meaningful "/.*gmsh.h" to search the file named "gmsh.h".
I find clearer "file:gmsh.h".
Taste of cheese and wine... :-)
> I don't l
On Thu, 9 Jan 2020 at 15:14, Pierre Neidhardt wrote:
> >> > I agree that explicit keywords, e.g., "file:" and "package:", avoid
> >> > confusion.
> >>
> >> I disagree. What about matching a path which contains "file:" or
> >> "package:"? Then you end up with confusing commands.
> >
> > About "
zimoun writes:
> Hi Pierre,
>
> On Thu, 9 Jan 2020 at 14:01, Pierre Neidhardt wrote:
>>
>> zimoun writes:
>
>> >> To avoid confusion, I think this should be an option/subcommand of
>> >> search. Something like -path and -name in find(1).
>> >
>> > I agree that explicit keywords, e.g., "file:" a
Hi again, :-)
On Thu, 9 Jan 2020 at 13:55, Pierre Neidhardt wrote:
> What I originally suggested is that we could equivalently do:
>
> guix search "/foo.*bar" python-
[...]
> > Time to time, I am looking for header C file or latex style but I do
> > not know the path. I would like to have so
Hi Pierre,
On Thu, 9 Jan 2020 at 14:01, Pierre Neidhardt wrote:
>
> zimoun writes:
> >> To avoid confusion, I think this should be an option/subcommand of
> >> search. Something like -path and -name in find(1).
> >
> > I agree that explicit keywords, e.g., "file:" and "package:", avoid
> > con
zimoun writes:
> On Thu, 9 Jan 2020 at 12:20, Pierre Neidhardt wrote:
>>
>> > … I agree. I think file search has to be a service providing access to
>> > a fast database.
>>
>> Good point. Let's go in that direction then.
>
> But it should be possible to build this database locally without usi
On Thu, 9 Jan 2020 at 12:20, Pierre Neidhardt wrote:
>
> > … I agree. I think file search has to be a service providing access to
> > a fast database.
>
> Good point. Let's go in that direction then.
But it should be possible to build this database locally without using
any network connection.
Dear,
On Fri, 3 Jan 2020 at 17:01, raingloom wrote:
> On Thu, 2020-01-02 at 23:50 +0100, zimoun wrote:
> > 2. because it allows (in the near future) mixed research: "guix
> > search bin/hg python" applying the "python" filter only to the
> > packages returned by "bin/hg". And "guix search pyt
On Thu, 2020-01-02 at 23:50 +0100, zimoun wrote:
> Hi,
>
> On Thu, 2 Jan 2020 at 18:12, Pierre Neidhardt
> wrote:
>
> > Last but not least: previously we suggested adding a subcommand
> > like
> > "guix which" or "guix filesearch". In another thread, Simon
> > suggested
> > that this would be a
Hello!
Christopher Baines skribis:
> Pierre Neidhardt writes:
>
>> Hello again!
>>
>> I'm resurrecting this since I've just started working on this as part of
>> the NGI application! :)
>>
> Internally it’d call ‘guix substitute’ to fetch the file index from
> the substitute server, che
Hi,
On Thu, 2 Jan 2020 at 18:12, Pierre Neidhardt wrote:
> Last but not least: previously we suggested adding a subcommand like
> "guix which" or "guix filesearch". In another thread, Simon suggested
> that this would be a bad idea and factoring the file search into "guix
> search" is probably
Pierre Neidhardt writes:
> Hello again!
>
> I'm resurrecting this since I've just started working on this as part of
> the NGI application! :)
>
Internally it’d call ‘guix substitute’ to fetch the file index from
the substitute server, check its signature, cache it locally, and then
>>
Pierre Neidhardt skribis:
> Ludovic Courtès writes:
[...]
>> The daemon could have a special RPC: you give it a file name and it
>> returns a store item (or package+version?) or #f.
>
> I think you meant "store itemS" (plural), no?
Yes.
>> Internally it’d call ‘guix substitute’ to fetch the
Hi!
Thanks for the details, Ludo!
Ludovic Courtès writes:
> An index could look like, say, a list of store item/file pairs. It
> would grow very quickly, which may not be very practical.
I think we might need some form of rotation and discard the old indexes
to avoid growing up indefinitely.
Hello,
Pierre Neidhardt skribis:
> I haven't though through the details, but I am under the impression that the
> file listing could be retrieve with the same mechanism as "guix size", i.e.
> from
> the substitute index. I think it would work well on the build farm, without
> more complexity t
27 matches
Mail list logo
