Guix Shows Us The Executable Binaries
wdyt if we show the bin folder in `guix show` output like in fedora? $ guix show sbase name: sbase version: 0-0.2c2a7f5 outputs: + out: everything bin: + cols ed head md5sum paste sed sleep tftp unlink basename + comm env hostname mkdir pathchk seq sort time uudecode cal cp + expand install mkfifo printenv setsid split touch uuencode cat + cron expr join mknod printf sha1sum sponge tr wc chgrp cut + false kill mktemp pwd sha224sum strings true which chmod date + find link mv readlink sha256sum sync tsort whoami chown dd + flock ln nice renice sha384sum tail tty xargs chroot dirname + fold logger nl rev sha512 224sum tar uname yes cksum du + getconf logname nohup rm sha512 256sum tee unexpand cmp echo + grep ls od rmdir sha512sum test uniq systems: x86_64-linux i686-linux dependencies: location: gnu/packages/suckless.scm:1022:4 homepage: https://core.suckless.org/sbase/ license: Expat synopsis: Collection of UNIX tools description: `sbase' is a collection of UNIX tools similar to those of GNU Coreutils, containing utilities + commands such as `grep', `cp', `rm', etc.
Re: [Guix Website] A Search Page for Packages
Hi Chris, Really cool! Thank you Felipe and Chris for this new packages.guix.gnu.org. :-) On Sat, 19 Nov 2022 at 10:51, Christopher Baines wrote: > It's really nice to have multiple things now (packages.guix.gnu.org, > qa.guix.gnu.org, bordeaux.guix.gnu.org, ...) that are made possible by > the Guix Data Service! Chris, what do you mean by «that are made possible by the Guix Data Service»? Cheers, simon
Re: guix open
Hi, On Fri, 18 Nov 2022 at 13:49, jgart wrote: > what do you think of having a `guix open` command that opens the projects > home-page in your $BROWSER? It is already possible, thanks Unix composability. :-) $BROWSER $(guix show hello | recsel -P homepage) Well, ’recsel’ from the package recutils is unusual and appears a bit weird at first but it is very powerful once RTFM. :-) Cheers, simon
Re: guix open
Hi,
On Fri, 18 Nov 2022 at 20:25, "(" wrote:
> On Fri Nov 18, 2022 at 8:22 PM GMT, Tobias Geerinckx-Rice wrote:
>> Yes — as ‘guix open’ — but it would make a nice addition to ‘guix
>> show’.
>
> How would that interact with ``guix package --show''? Perhaps it might
> be better to add a ``guix package --open'' option?
Currently “guix show” is an alias of “guix package --show=” and we could
start to do the contrary, “guix package --show=” would be using “guix
show”. Mainly for maintaining backward compatibility. But “guix show”
could evolve this own way supporting options that would not be supported
by legacy “guix package --show=”. WDYT?
It would avoid some headache. ;-)
Cheers,
simon
Re: foreign-distro?
Le Sun, 20 Nov 2022 14:54:40 -0600,
jgart a écrit :
> Does Guix have a declarative Guix API way of knowing if it is
> installing a package into foreign distro versus Guix System?
>
> I'm thinking of a function like `foreign-distro?`:
>
> ```
> (define-public peek
> (package
>(name "peek")
>...
> (inputs
> `(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
> ```
>
> The above includes ffmpeg in the inputs only if installing peek on a
> foreign distro. It could additionally patch the ffmpeg executable in
> a peek package phases if foreign-distro? returns #t.
>
> WDYT
>
Guix doesn't have a notion of foreign distro, it's all in your head,
and there's no difference between Guix System and other distros in the
Guix package manager's point of view :)
To be more specific, Guix only knows what you current system is (that's
captured by %current-system). It's probably x86_64-linux right know. As
you can see, there's no place in there to tell it whether you're on a
foreign distro or not.
Lastly, I don't think I would want to differentiate the two cases,
especially since it would mean that somehow Guix packages depend on
something external. There's this idea that Guix packages should somehow
be self-sufficient.
foreign-distro?
Does Guix have a declarative Guix API way of knowing if it is installing
a package into foreign distro versus Guix System?
I'm thinking of a function like `foreign-distro?`:
```
(define-public peek
(package
(name "peek")
...
(inputs
`(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
```
The above includes ffmpeg in the inputs only if installing peek on a
foreign distro. It could additionally patch the ffmpeg executable in
a peek package phases if foreign-distro? returns #t.
WDYT
Re: guix open
On Sun, 20 Nov 2022 07:45:31 + Mekeor Melire wrote: > what's the advantage over this one-liner? > > guix show recutils | recsel -P homepage | xargs xdg-open too many characters to type but I think I will turn that one-liner into a script, add it to my dots, and consider this feature completed ;() Thanks for sharing!
Re: Layout of ‘define-configuration’ records
Hi Katherine, Katherine Cox-Buday writes: > Maxim Cournoyer writes: > >>> Moving the field last is problematic as we’ve seen for any user that >>> uses ‘match’ on records—something that’s not recommended but still >>> used a lot. > > Some feedback I hope is useful: > > I'm one such newbie, and had to stumble my way into discovering why some > of my services suddenly broke. All I had to go on was with "invalid > G-expression input" at a location in an `operating-system` declaration. > > Initially, because of the reference to gexps, I thought something had > changed with `local-file` which I am using to deploy source code off of > a local branch. Through trial and error and reading git logs, I > discovered this was not the case, and saw that `define-configuration` > had changed. From there I was able to discover the problem. > >> Yep. I had that on mind when I made the change, though I still missed >> a few occurrences. > > I came looking for an announcement of this change somewhere on a mailing > list (info-guix maybe?) or the Guix blog but couldn't find anything. I > understand the focus is on in-repo code, but could we consider > announcing changes which might affect channels and such? I don't always > have time to stay up to date with the changes to the project :( Apologies for causing grief! Ironically, the change was motivated by going through such pain myself when attempting to migrate the mcron-configuration from a define-record-type* to a define-configuration produced record, that's why I wanted to standardize their layout. I'm taking yours and Ludovic's feedback into account for the future and will reach out to guix-devel with heads-up when introducing breaking changes to Guix APIs. A side-note, it seems that Ludovic has been working toward eliminating the use of match patterns matching the fields directly, instead encouraging the use of 'match-record', see https://issues.guix.gnu.org/59390. I haven't checked if this is compatible with define-configuration records though. -- Thanks, Maxim
