Re: Parameterized packages
Pierre Neidhardt writes:
> Any thought on this, anyone?
Having used Gentoo for some years, I'm not sure a "global" parameter
system is desirable. It could encourage enabling feature "foo", even
for packages that have experimental or broken support for "foo".
But I see how it could be useful to parameterize packages nevertheless.
I imagine adding a 'parameters' field to the package type, and write
definitions along these lines.
(package
(parameters
'((pulseaudio . #t)))
(arguments
`(#:configure-flags ,(match parameters
((('pulseaudio . #t)
'("--enable-pulseaudio" "--enable-dbus"))
(_ '()
(inputs
`(("foo" ,foo)
,@(match parameters
((('pulseaudio . #t)
`(("pulseaudio" ,pulseaudio
(_ '()))
And perhaps a "with-parameters" procedure for toggling it:
(inputs
`(("foo" ,foo))
("bar" ,(with-parameters ((pulseaudio . #f)) bar)))
We could have a similar procedure that recursively toggles supported
parameters of all given packages.
Actually we can abuse the 'properties' field for this purpose without
having to change anything.
Well, food for thought, thanks for driving this :-)
signature.asc
Description: PGP signature
Re: TeX Live 2019 wanted
Andreas Enge writes: > On Mon, Dec 16, 2019 at 11:41:57PM +0100, Marius Bakke wrote: >> Errh, the patch only works if you already have Poppler 0.83.0. For the >> current 'core-updates' branch, I believe you can use the same approach >> but fetch poppler-0.76.0.cc instead (or take Arch's patch[0]). > > Ah, this is rocket science! I guessed so much as to use the 0.76.0 file; > however, the build now fails with the following: > > /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash > ./libtool --tag=CXX --mode=link g++ -Wreturn-type -Wno-write-strings -g > -O2 -o pdftex pdftexdir/pdftex-pdftexextra.o synctexdir/pdftex-synctex.o > pdftex-pdftexini.o pdftex-pdftex0.o pdftex-pdftex-pool.o libpdftex.a > -L/gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/lib > -L/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11/lib -lpng16 -lz -lz > -L/gnu/store/18q4r8bpwmpm4w15zipf66l3bvdjzfbs-poppler-0.79.0/lib -lpoppler > libmd5.a lib/lib.a > /tmp/guix-build-texlive-bin-20190410.drv-0/build/texk/kpathsea/libkpathsea.la > -lm > libtool: link: g++ -Wreturn-type -Wno-write-strings -g -O2 -o pdftex > pdftexdir/pdftex-pdftexextra.o synctexdir/pdftex-synctex.o pdftex-pdftexini.o > pdftex-pdftex0.o pdftex-pdftex-pool.o libpdftex.a > -L/gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/lib > -L/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11/lib > /gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/lib/libpng16.so -lz > -L/gnu/store/18q4r8bpwmpm4w15zipf66l3bvdjzfbs-poppler-0.79.0/lib -lpoppler > libmd5.a lib/lib.a > /tmp/guix-build-texlive-bin-20190410.drv-0/build/texk/kpathsea/.libs/libkpathsea.a > -lm -Wl,-rpath > -Wl,/gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/lib -Wl,-rpath > -Wl,/gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/lib > ld: libpdftex.a(libpdftex_a-writeimg.o): in function `readimage': > /tmp/guix-build-texlive-bin-20190410.drv-0/build/texk/web2c/../../../texlive-20190410-source/texk/web2c/pdftexdir/writeimg.c:320: > undefined reference to `read_pdf_info' > ld: libpdftex.a(libpdftex_a-writeimg.o): in function `undumpimagemeta': > /tmp/guix-build-texlive-bin-20190410.drv-0/build/texk/web2c/../../../texlive-20190410-source/texk/web2c/pdftexdir/writeimg.c:546: > undefined reference to `read_pdf_info' > collect2: error: ld returned 1 exit status > > read_pdf_info is defined precisely in the pdftoepdf-poppler*.cc > > And using "strings" on libpdftex.a shows that the function name occurs. This turned out to be because poppler0.83.0.cc depends on another revision, which changed the read_pdf_info function signature: https://github.com/TeX-Live/texlive-source/commit/371f874f0945435b9b577a130bb97368311e981a I was able to build it with Poppler 0.84 by taking the Arch patches, and forking their poppler-0.83 patch: From 4278c74b3ad87e6b6df5b2cca8bdd906d61ff097 Mon Sep 17 00:00:00 2001 From: Marius Bakke Date: Thu, 9 Jan 2020 18:36:50 +0100 Subject: [PATCH 1/5] gnu: poppler: Update to 0.84.0. * gnu/packages/pdf.scm (poppler): Update to 0.84.0. --- gnu/packages/pdf.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/pdf.scm b/gnu/packages/pdf.scm index 3b6829c4bc..78f652164b 100644 --- a/gnu/packages/pdf.scm +++ b/gnu/packages/pdf.scm @@ -90,14 +90,14 @@ (define-public poppler (package (name "poppler") - (version "0.79.0") + (version "0.84.0") (source (origin (method url-fetch) (uri (string-append "https://poppler.freedesktop.org/poppler-; version ".tar.xz")) (sha256 (base32 - "1j18jlv1q6h21azb939gqjsgcbsh5qcd8dwxdmad54p5ixha91gr" + "0ccp2gx05cz5y04k5pgbyi4ikyq60nafa7x2yx4aaf1vfkd318f7" (build-system cmake-build-system) ;; FIXME: ;; use libcurl:no -- 2.24.1 From 3b1ceabd25651952aee0834985770538a313b734 Mon Sep 17 00:00:00 2001 From: Marius Bakke Date: Thu, 9 Jan 2020 22:36:40 +0100 Subject: [PATCH 2/5] build-system/texlive: Update to texlive-2019.3, revision 51265. * guix/build-system/texlive.scm (%texlive-tag): Change to "2019.3". (%texlive-revision): Change to 51265. --- guix/build-system/texlive.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/guix/build-system/texlive.scm b/guix/build-system/texlive.scm index ad99d1e2d0..8bbca0ccb7 100644 --- a/guix/build-system/texlive.scm +++ b/guix/build-system/texlive.scm @@ -42,8 +42,8 @@ ;; These variables specify the SVN tag and the matching SVN revision. They ;; are taken from https://www.tug.org/svn/texlive/tags/ -(define %texlive-tag "texlive-2018.2") -(define %texlive-revision 49435) +(define %texlive-tag "texlive-2019.3") +(define %texlive-revision 51265) (define (texlive-origin name version locations hash) "Return an object for a TeX Live package consisting of multiple -- 2.24.1 From 9fc158fc135ab718cb767f5eecb16cd81d4847f6 Mon
Re: Proposal for a blog contribution on reproducible computations
Hi Konrad,
Thank you! It is very interesting!!
Below questions.
And suggestions which I can Pull-Request with Github. :-)
Hope it is readable: indented text is your text; non-indented one is question.
Cheers,
simon
--
#+TITLE: Reproducible computations with Guix
#+STARTUP: inlineimages
* Dependencies: what it takes to run a program
Move this section title below.
This post is about reproducible computations, so let's start with a
computation. A short, though rather uninteresting, C program is a good
starting point. It computes π in three different ways:
#+begin_src c :tangle pi.c :eval no
#include
#include
int main()
{
printf( "M_PI : %.10lf\n", M_PI);
printf( "4 * atan(1.) : %.10lf\n", 4.*atan(1.));
printf( "Leibniz' formula (four terms): %.10lf\n",
4.*(1.-1./3.+1./5.-1./7.));
return 0;
}
#+end_src
Align ':' for easier looking.
This program uses no random element, such as a random number generator
or parallelism. It's strictly deterministic. It is reasonable to expect
it to produce exactly the same output, on any computer and at any point
in time. And yet, many programs whose results /should/ be perfectly
reproducible are in fact not. Programs using floating-point arithmetic,
such as this short example, are particularly prone to seemingly
inexplicable variations.
My goal is to explain why deterministic programs often fail to be
reproducible, and what it takes to fix this. The short answer to that
question is "use Guix", but even though Guix provides excellent support
for reproducibility, you still have to use it correctly, and that
requires some understanding of what's going on. The explanation I will
give is rather detailed, to the point of discussing parts of the Guile
API of Guix. You should be able to follow the reasoning without knowing
Guile though, you will just have to believe me that the scripts I will
show do what I claim they do. And in the end, I will provide a
ready-to-run Guile script that will let you explore package dependencies
right from the shell.
* Dependencies: what it takes to run a program
One keyword in discussions of reproducibility is "dependencies". I will
revisit the exact meaning of this term later, but to get started, I will
define it loosely as "any software package required to run a program".
Running the π computation shown above is normally done using something
like
#+begin_src sh :exports code :eval no
gcc pi.c -o pi && ./pi
#+end_src
Missing '&&'. It does not work without on my machine.
C programmers know that =gcc= is a C compiler, so that's one obvious
dependency for running our little program. But is a C compiler enough?
That question is surprisingly difficult to answer in practice. Your
computer is loaded with tons of software (otherwise it wouldn't be very
useful), and you don't really know what happens behind the scenes when
you run =gcc= or =pi=.
** Container is good
A major element of reproducibility support in Guix is the possibility to
run programs in well-defined environments that contain exactly the
software packages you request, and no more. So if your program runs in
an environment that contains only a C compiler, you can be sure it has
no other dependencies. Let's create such an environment:
#+begin_src sh :session C-compiler :results output :exports both
guix environment --container --ad-hoc gcc-toolchain
#+end_src
#+RESULTS:
The option =--container= ensures the best possible isolation from the
standard environment that your system installation and user account
provide for day-to-day work. This environment contains nothing but a C
compiler and a shell (which you need to type in commands), and has
access to no other files than those in the current directory.
Side note: the option =--container= requires support from the Linux
kernel that is not available on all systems. If it doesn't work for you,
use =--pure= instead. It provides a less isolated environment, but it is
usually more than good enough.
By default, I get:
--8<---cut here---start->8---
guix environment: error: cannot create container: unprivileged user
cannot create user namespaces
guix environment: error: please set
/proc/sys/kernel/unprivileged_userns_clone to "1"
--8<---cut here---end--->8---
Or a sentence explaining what to do. For example, "The =--container= option
requires allowing the kernel to clone for the unprivileged user, i.e., as
=root= just run the command
=echo 1 >
Re: Scicloj web meeting about Guix-Jupyter today
Hi Ludo, Thank you! It was interesting. :-) Cheers, simon
Re: Proposal for Outreachy (May-August 2020)
Don't know if this is a good place, but gnome-color-manager in this commit: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=29ae18db0578bbdbc0119703f7412fe91927e80e has GPL2 license in the "license" field and the COPYING file also tells the license is GPL2, but if you check a random source file, for example https://gitlab.gnome.org/GNOME/gnome-color-manager/blob/master/src/gcm-brightness.c Then files are licensed under GPL2 or any later. > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License as published by > * the Free Software Foundation; either version 2 of the License, or > * (at your option) any later version. I guess the license is GPLV2 then, but I'm not sure, can someone confirm this? Jan Wielkiewicz
Re: Package file indexing
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 clearer "guix search bin/hg". > > However, to search any file which you do not the path, I find clearer > > "guix search file:foo.h". > > To be clear, you don't need to know the path. It's enough to know the > basename, e.g. `guix search /foo.h`. I do not find "/foo.h" clear. I prefer "file:foo.h". What I naturally do is: - guix search bin/hg - guix search file:hg It appears to me awkward to type "guix search /hg". But I can live with. :-) > >> What I meant is that we already have a subcommand that outputs a > >> property of the given packages, i.e. "guix size". If I'm not mistaken, > >> there is no "guix package" flag that displays any property for the given > >> packages. > > > > You are suggesting "guix size emacs --list-files", right? > > No, I'm saying that if we follow the current approach for printing our > package properties, we should have > > guix list-files emacs Sorry to be slow but I do not understand why a complete subcommand is required? To me, it seems better to add an "--list-files" to "guix package" or "guix show". Cheers, simon
Re: Package file indexing
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. You don't need the full path. I do not like because it is not meaningful. It appears to me more confusing than the rare case of "file:file:". ;-) > >> >> - guix search file:ieee*.sty bin/gmsh latex > > > > I know nothing about the path of the file ieee*.sty and it does not > > belong to the package gmsh. > > I don't understand what you are trying to search. Is it the 'bin/gmsh' > file or the files matching 'ieee*.sty'? In this (virtual and non-sensical) example, I am looking for packages that contains any file matching ieee*.sty *and* any file matching "bin/gmsh" *and* any package that matches latex in its name/synopsis/description. I do not see why the both syntax can live together. To me, sometimes "file:" is clearer, sometimes instead "/" is. All the best, simon
Re: Another update on the Guix Data Service
Pierre Neidhardt writes: >> Channel news entries are recorded in the database, you can see all that >> are present in a revision [3], but the comparison page should show new >> news entries as well. >> >> 3: >> http://data.guix.gnu.org/revision/06c8e87224decebc0a3d5bdc7d2ca13cb2b08299/news > > Is there a link to the news page from > > http://data.guix.gnu.org/revision/06c8e87224decebc0a3d5bdc7d2ca13cb2b08299 > > ? No, but there probably should be one. >> - Automated code review for Guix patches, which I was working on when I >>started working on the Guix Data Service, and most of the >>functionality can be beneficial there. > > Some time ago you did some work on Patchwork. > > https://patchwork.cbaines.net/project/guix-patches/list/ > > I haven't followed very closely, so I wonder what your plans are > regarding patchwork and Guix Data Service. So I'd like to resurrect my slightly clunky but somewhat working Patchwork + Laminar + Git repo + Guix Data Service (+ Cuirass?) setup for testing patches. Here, the Guix Data Service would process the Guix revision with the patches under test having been applied. This would reveal the lint warning changes. It would also reveal the new derivations, which can be built to check what the effect of the patches are. > Last, is there any documentation on how to _use_ it? (I don't mean the > setup.) So the only documentation currently is the README file, which is available at http://data.guix.gnu.org/README . I haven't considered writing standalone documentation yet, but I have been considering incorporating more in to the web interface. Is there a specific thing you're interested in/unsure about? Chris signature.asc Description: PGP signature
Re: Package file indexing
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 guix "filesearch" polls a specific instance of > the Guix Data Service (e.g. data.guix.gnu.org) to download the file > index fro the current Guix revision? 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 associated with each revision, but I don't think it should store the actual nar files. What you could have is another service, which subscribes to the Guix Data Service to find out about new revisions and nars (from build servers). When this new service finds out about Guix revisions, it would ask this Guix Data Service for all the outputs, and store this away in a database. When it finds out about nars, it would download them, and maybe extract out the list of files. I think this setup would allow this new service to construct a file containing information about all files in all the outputs for a revision, which it has nars available for. This file could then be downloaded, and searched through when you want to find which output contains a file. > What if the file index for a specific Guix commit (e.g. a very recent > one) is not yet available? I suggest we fall back to the first older > index that's available, with a warning. Thoughts? Sounds sensible. signature.asc Description: PGP signature
Re: Package file indexing
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 not the path, I find clearer > "guix search file:foo.h". To be clear, you don't need to know the path. It's enough to know the basename, e.g. `guix search /foo.h`. >> What I meant is that we already have a subcommand that outputs a >> property of the given packages, i.e. "guix size". If I'm not mistaken, >> there is no "guix package" flag that displays any property for the given >> packages. > > You are suggesting "guix size emacs --list-files", right? No, I'm saying that if we follow the current approach for printing our package properties, we should have guix list-files emacs -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Package file indexing
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<---cut here---start->8--- guix search /gmsh.h --8<---cut here---end--->8--- would work. You don't need the full path. >> >> - guix search file:ieee*.sty bin/gmsh latex > > I know nothing about the path of the file ieee*.sty and it does not > belong to the package gmsh. I don't understand what you are trying to search. Is it the 'bin/gmsh' file or the files matching 'ieee*.sty'? >> For advanced search, we could provide "explorable" features with a >> graphical user interface (which I plan to work on later) or Emacs (a big >> like `guix-packages-by-name', but more general). Those interface would >> allow the user to chain searches by narrowing down lists. What you >> print in the end is irrelevant since you can have an interactive >> presentation (unlike the shell). > > ...but at some point you need some semantic for filtering, at least for > regexp. We can have regexp of course, that's not a problem. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Scicloj web meeting about Guix-Jupyter today
Ludovic Courtès skribis: > I’ll be presenting Guix-Jupyter today in a web meeting of Scicloj, at > 3PM UTC (4PM CET): > > https://scicloj.github.io/pages/web_meetings/ > > This will be happening through Jitsi¹ (exact URL will be announced > later), which I found to work well with our ‘ungoogled-chromium’ > package. It's starting! https://meet.jit.si/scicloj-guix-jupyter Ludo'.
Re: Package file indexing
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 like "file:" because: > > - It can make for ambiguous command line to the human read > (e.g. "file:file:"). Bad faith? ;-) I do not know how many user will search for the term "file:". > - It's a new arbitrary syntax which the user must learn to use it, which > means they probably won't. Hum? I am not convinced. > 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 not the path, I find clearer "guix search file:foo.h". Well, it is enough of bikeshedding, isn't it? :-) > > What is the purpose of this "list-files" for you? > > Listing the files of a package like in the example you gave. Ok. > What I meant is that we already have a subcommand that outputs a > property of the given packages, i.e. "guix size". If I'm not mistaken, > there is no "guix package" flag that displays any property for the given > packages. You are suggesting "guix size emacs --list-files", right? > I am just thinking about keeping consistency across the various > subcommands of Guix. I do not have a strong opinion. :-) To me, the right place is "guix package --list-files" but I am not convinced. :-) Cheers, simon
Re: Package file indexing
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 "file:", no issue: > > guix search file:file: > > It might not be ambiguous for the machine, but it is to the human > reader! :) > > --8<---cut here---start->8--- > guix search /file: > --8<---cut here---end--->8--- > > is more readable in my opinion. I disagree. Ah cheese and wine taste... ;-) As I said, I am suggesting to have the both syntax. > >> Simon, regarding your examples: > >> > >> > - guix search bin/gmsh gimp > >> > - guix search file:ieee*.sty bin/gmsh latex > >> > - guix search file:bin/gmsh > >> > >> why mixing both the "file:" prefix and the "/"? > > > > Yes, I am suggesting to mix both. > > > > I would like to have all this syntax: > > > >> - guix search file:gmsh.h gimp > >> - guix search bin/gmsh gimp > >> - guix search file:ieee*.sty bin/gmsh latex > >> - guix search file:bin/gmsh > >> - guix search package:gimp > > 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. > >> - guix search bin/gmsh gimp I need to know the name of the file and the path. > >> - guix search file:ieee*.sty bin/gmsh latex I know nothing about the path of the file ieee*.sty and it does not belong to the package gmsh. Whatever! To summary, I think: - the syntax '/' is cool to turn on the "file-search" feature - I find more meaningful the syntax "file:" to turn on "file-search" - I find more meaningful to have "file:foo.h package:bar" than "/.foo.h bar" > > Now, if we speak about the "search" command-line syntax, today the way > > is to write a regexp and then to filter with 'recsel'. It is UNIX > > philosophy to compose via pipes but the drawback is: one *has to* > > first (read the Guix manual [1] to) know the existence of 'recsel' and > > second read the documentation of 'recutils' for complex filtering. So, > > long time ago, I was thinking to add more syntax [2]. Today, the > > syntax is: > > > >guix search "" | recsel -C -e 'name ~ "agda" && !(name ~ "mode")' > > -p synopsis > > > > and I find more welcoming something avoiding the pipe, e.g., > > > > guix search 'name ~ "agda" && !(name ~ "mode") -p synopsis' > > This is still rather arcanic (understand: too hard to be useful to the > general user) in my opinion. Every time I use a program that has some > search semantic, I need to look up the manual because I forgot the > syntax and other intricacies. So I end up not doing it often. I agree... > For advanced search, we could provide "explorable" features with a > graphical user interface (which I plan to work on later) or Emacs (a big > like `guix-packages-by-name', but more general). Those interface would > allow the user to chain searches by narrowing down lists. What you > print in the end is irrelevant since you can have an interactive > presentation (unlike the shell). ...but at some point you need some semantic for filtering, at least for regexp. Graphical presentation does not change the issue. > Example: > > - Display list of all packages. > - Run "agda" search against names. > - Narrow down. > - Run "mode" search against names. > - Narrow down to the complement. > - Run a general search against "foo bar". > - Print the result. > - Display synopsis only of the result. Well you did kind of some semantic. ;-) (You have right that it is more easy to remember how to do when it is graphical and step by step. :-)) > For the general case, a "do what I mean" search field that works like > Internet search engines is a better approach in my opinion. I agree. On my side, as I explained elsewhere I would like to try to improve the 'relevance' function by applying well-known NLP stuff. :-) Cheers, simon
Re: Package file indexing
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:" and "package:", avoid >> > confusion. >> >> I disagree. What about matching a path which contains "file:" or >> "package:"? Then you end up with confusing commands. > > About "file:", no issue: > guix search file:file: It might not be ambiguous for the machine, but it is to the human reader! :) --8<---cut here---start->8--- guix search /file: --8<---cut here---end--->8--- is more readable in my opinion. >> Simon, regarding your examples: >> >> > - guix search bin/gmsh gimp >> > - guix search file:ieee*.sty bin/gmsh latex >> > - guix search file:bin/gmsh >> >> why mixing both the "file:" prefix and the "/"? > > Yes, I am suggesting to mix both. > > I would like to have all this syntax: > >> - guix search file:gmsh.h gimp >> - guix search bin/gmsh gimp >> - guix search file:ieee*.sty bin/gmsh latex >> - guix search file:bin/gmsh >> - guix search package:gimp But for which benefit? It seems that this single example >> - guix search bin/gmsh gimp covers all your needs. > Now, if we speak about the "search" command-line syntax, today the way > is to write a regexp and then to filter with 'recsel'. It is UNIX > philosophy to compose via pipes but the drawback is: one *has to* > first (read the Guix manual [1] to) know the existence of 'recsel' and > second read the documentation of 'recutils' for complex filtering. So, > long time ago, I was thinking to add more syntax [2]. Today, the > syntax is: > >guix search "" | recsel -C -e 'name ~ "agda" && !(name ~ "mode")' > -p synopsis > > and I find more welcoming something avoiding the pipe, e.g., > > guix search 'name ~ "agda" && !(name ~ "mode") -p synopsis' This is still rather arcanic (understand: too hard to be useful to the general user) in my opinion. Every time I use a program that has some search semantic, I need to look up the manual because I forgot the syntax and other intricacies. So I end up not doing it often. For advanced search, we could provide "explorable" features with a graphical user interface (which I plan to work on later) or Emacs (a big like `guix-packages-by-name', but more general). Those interface would allow the user to chain searches by narrowing down lists. What you print in the end is irrelevant since you can have an interactive presentation (unlike the shell). Example: - Display list of all packages. - Run "agda" search against names. - Narrow down. - Run "mode" search against names. - Narrow down to the complement. - Run a general search against "foo bar". - Print the result. - Display synopsis only of the result. For the general case, a "do what I mean" search field that works like Internet search engines is a better approach in my opinion. What do you think? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Package file indexing
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 something like: > > > > guix search gmsh.h > > or > > guix search ieee*.sty > > That's OK, if you know the basename then "/gmsh.h" will match. > If you only know a substring of the basename, then "/.*gmsh.h" will > match too. My point is just I do not like the key '/' to turn on the file-search and I prefer "file:". As said elsewhere. :-) Otherwise, I am on the same wavelength about you are proposing and it is really cool! > > IMHO, it should be included under "guix package", i.e., > > > > guix package gmsh --list-files > > Why not, but then this does not match the interface we have with "guix > size". Maybe we not not talking about the same thing. What is the purpose of this "list-files" for you? To me, it should return all the files of the package gmsh. For example with Debian, when I install the package gmsh, the package manager adds all these files [1]. [1] https://packages.debian.org/buster/amd64/gmsh/filelist Nothing similar exists in Guix, right? If yes, cool, please tell me. :-) Because I am not aware of such thing, then I use "ls -l" and "which" to locate them, which is not friendly. > Could we also have "guix package gmsh --size"? Would we deprecate "guix > size" then? No. It seems better to keep "guix size", IMHO. > If not, then for the sake of consistency I'd prefer to have "guix list-files". I think it is a bad idea to add another subcommand. Because it is not so common, I guess. Well, could you elaborate on what this "list-files" will do? All the best, simon
Re: Package file indexing
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 > > confusion. > > I disagree. What about matching a path which contains "file:" or > "package:"? Then you end up with confusing commands. About "file:", no issue: guix search file:file: However, yes there is an ambiguous behaviour of: guix search package: Currently, the command guix search returns an error. Does "guix search package:" return an error as "guix search"? Meaning search about 'empty'. Or does it return the packages matching the term "package:"? For example the package "perl-package-stash-xs" containing "Package:" in its description or the package "r-vctrs" containing "package:" in its description too. Note it is the only two packages. For backward compatibility, the ambiguity needs to be fixed by the latter. > Using "/" as a filter makes sense because it's the only character that's > not allowed in filenames (with \0) and it's safe to assume that it's not > useful to match against "/" in description / synopsis. > > Simon, regarding your examples: > > > - guix search bin/gmsh gimp > > - guix search file:ieee*.sty bin/gmsh latex > > - guix search file:bin/gmsh > > why mixing both the "file:" prefix and the "/"? Yes, I am suggesting to mix both. I would like to have all this syntax: > - guix search file:gmsh.h gimp > - guix search bin/gmsh gimp > - guix search file:ieee*.sty bin/gmsh latex > - guix search file:bin/gmsh > - guix search package:gimp Now, if we speak about the "search" command-line syntax, today the way is to write a regexp and then to filter with 'recsel'. It is UNIX philosophy to compose via pipes but the drawback is: one *has to* first (read the Guix manual [1] to) know the existence of 'recsel' and second read the documentation of 'recutils' for complex filtering. So, long time ago, I was thinking to add more syntax [2]. Today, the syntax is: guix search "" | recsel -C -e 'name ~ "agda" && !(name ~ "mode")' -p synopsis and I find more welcoming something avoiding the pipe, e.g., guix search 'name ~ "agda" && !(name ~ "mode") -p synopsis' Cheers, simon [1] http://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html#Invoking-guix-package [2] https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00480.html
Re: Proposal for Outreachy (May-August 2020)
> Yes! I don't think I'm alone in frustration over unnecessary packages > installed systemwide. :-) signature.asc Description: This is a digitally signed message part
Re: Package file indexing
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 using > any network connection. Yes, a bit like "guix size" permits. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Package file indexing
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. Something like: "guix search --build-database" and also "guix pull --build-search-db". And using an external database fetched from ci.guix.gnu.org or data.guix.gnu.org should work as the substitutes do. All the best, simon
Re: Scicloj web meeting about Guix-Jupyter today
Hi Ludo, On Thu, 9 Jan 2020 at 09:57, Ludovic Courtès wrote: > I’ll be presenting Guix-Jupyter today in a web meeting of Scicloj, at > 3PM UTC (4PM CET): Cool! > This will be happening through Jitsi¹ (exact URL will be announced > later), which I found to work well with our ‘ungoogled-chromium’ > package. Yes, let us know! :-) Here or on IRC if you can. Cheers, simon
Re: Another update on the Guix Data Service
Hi Christopher! Nice update as usual! A few questions: > Channel news entries are recorded in the database, you can see all that > are present in a revision [3], but the comparison page should show new > news entries as well. > > 3: > http://data.guix.gnu.org/revision/06c8e87224decebc0a3d5bdc7d2ca13cb2b08299/news Is there a link to the news page from http://data.guix.gnu.org/revision/06c8e87224decebc0a3d5bdc7d2ca13cb2b08299 ? > - Automated code review for Guix patches, which I was working on when I >started working on the Guix Data Service, and most of the >functionality can be beneficial there. Some time ago you did some work on Patchwork. https://patchwork.cbaines.net/project/guix-patches/list/ I haven't followed very closely, so I wonder what your plans are regarding patchwork and Guix Data Service. Last, is there any documentation on how to _use_ it? (I don't mean the setup.) Cheers, and thanks again with the great work! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Looking for Mentor(s)
Hello Guix! For Outreachy's May-August 2020 round, I have proposed some ideas (https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00102.html). I am looking for folk(s) to be a mentor(s) for those topics. Please let me know if you are interested. Thank you! Regards, Raghav Gururajan.
Scicloj web meeting about Guix-Jupyter today
Hello Guix! I’ll be presenting Guix-Jupyter today in a web meeting of Scicloj, at 3PM UTC (4PM CET): https://scicloj.github.io/pages/web_meetings/ This will be happening through Jitsi¹ (exact URL will be announced later), which I found to work well with our ‘ungoogled-chromium’ package. Ludo’. ¹ https://jitsi.org/jitsi-meet/
