Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!
Pierre, Pierre Neidhardt 写道： I'm happy to let your know that my application to the NLNet "Next Generation Internet -- Search & Discovery" grant for Guix has been accepted! Yay! The second joyful announcement on guix-devel this week. 1. Parameterized packages (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html) Gentoo’s package manager, Portage, exposes a “USE flags” feature which allows users to customize packages in a way that composes (e.g. “disable the GUI elements of all packages” for a headless server). This essentially subdivides packages into smaller “components.” Since those components form the smallest atoms a user could search for, this is a prerequisite for the rest of the searchability improvements. Very curious to see where this goes. Do you have any other examples of distributions that attack this problem in (more) interesting ways than Gentoo? The inevitable “oooh, you mean like USE flags” mental shortc(irc)ut that this subject inevitably triggers seems stifling to me… but it affects me as well and I don't have any better ideas. Thank you, and good luck! T G-R signature.asc Description: PGP signature
Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!
That is great news Pierre :) On Fri, Dec 13, 2019 at 03:48:37PM +0100, Pierre Neidhardt wrote: > Dear Guix community! > > I'm happy to let your know that my application to the NLNet "Next > Generation Internet -- Search & Discovery" grant for Guix has been > accepted! > > See https://nlnet.nl/project/GUIX/ (the description is misleading, see below). > See also the European Union initiative website: https://www.ngi.eu/. > > This will allow me to work on Guix for a flexible period, probably between 6 > months and 1 year. > > The bad news: Nope, IPFS is not part of the grant! :p So I won't be working > on > it myself in the context of NGI. But who knows, if I get extra time... (Or > anyone else ;p). > > Here follows the current plan (subject to change). Ideas are welcome! > > > > /The main goal is to enhance search and discovery of Guix packages and > services > via a catalogue. The subgoal is to complete what “packages” and “services” > are in > Guix by completing them and broadening their domain./ > > 1. Parameterized packages >(Previous discussion: > https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html) > >Gentoo’s package manager, Portage, exposes a “USE flags” feature which > allows >users to customize packages in a way that composes (e.g. “disable the GUI >elements of all packages” for a headless server). This essentially > subdivides >packages into smaller “components.” Since those components form the > smallest >atoms a user could search for, this is a prerequisite for the rest of the >searchability improvements. > >Milestone(s) >* Implement parameterized package support (mostly Guile code). >* Write tests. >* Document. >* Community review. > > 2. File search >(Previous discussion: > https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html) > >Many package managers support looking up packages by the file paths they >include. This feature is missing in Guix while being crucial for search, >e.g. when the user knows the executable name which happens to be different >from the package name. > >Milestone(s) >* Implement file paths caching in the daemon (mostly C++). >* Implement high-level command line interface for file search (mostly > Guile). >* Write tests. >* Document. >* Community review. >* Deploy on the build farms. > > 3. User services > >Previous discussions: >- Guix shepherd user services: > https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00128.html >- Julien's home manager: > https://lists.gnu.org/archive/html/guix-devel/2019-09/msg00185.html >- Nix Home Manager: https://nixos.wiki/wiki/Home_Manager >I believe there were many more discussion on user services on the >mailing list, feel free to share them! > >Guix provides excellent integration with GNU Shepherd for system services > (all >configurations are programmable and composable using Guile). But it lacks >integration for user services. User services can be used to replace much > of the >traditional “dotfiles” which are often ad-hoc hacks (e.g. environment > variables, >scripts, various program configurations such as GnuPG). The benefit is as > for >packages: the work of one can be redistributed to many. Finally, services > are >not searchable with Guix. We could fix this issue. > >Milestone(s) >* Integrate Guix with GNU Shepherd to support user services. A user > service > should then automatically require the necessary packages, just like a > system service does. For instance if the user sets up a GnuPG service, > they don’t have to install GnuPG explicitly, Guix+Shepherd will take care > of that. >* Implement service search. >* Write tests. >* Document. >* Community review. > > 4. Graphical user interface (GUI) > >*Question*: I recently read an email about someone (an intern?) working on > a >graphical installer. Can't find the email back though. Is someone still >working on it? There could be a lot of work to factor here. > >Guix comes with a command line interface and some Emacs interfaces. None > of >them are particularly newcomer-friendly. Besides, much of the > configuration is >done by editing Guile files. The goal of this task is to make Guix more >accessible to non-tech users by providing an intuitive user interface to > most of >Guix actions. > >Milestone(s) >* Discuss with the Accessibility Group for the requirements. >* Implement the GUI using Gobject-Introspection (Guile). > 1. Live fuzzy-search. > 2. Search packages. > 3. Search file paths. > 4. Search system/user services. > 5. Configuration editor (generates a Guile configuration). >* Write tests. >* Document. >* Community review. > > 5. Social integration with the Guix catalogue > >Previous
Re: When to add rust packages?
On Fri, Dec 13, 2019 at 02:57:00PM +, John Soo wrote: > Hi Guix, > > I packaged a number of Rust programs that I use everyday (ripgrep, > alacritty) or I found useful when learning Rust (racer). With the > instability of the rust build system and package definition they are a lot > to maintain. I would love to send patches for them but I don't want to > burden you all with the maintenance of the packages. When do you think > would be the best time to send patches? > Also once you send them we have more packages to test out changes to the rust system against. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: When to add rust packages?
Thanks, I’ll be sending some patches as soon as I can. As you all know, rust packages have a lot of dependencies so it could take some time. - John
Fwd: GNU Guix POWER9 OpenStack application (was: New POWER9 machines for the Guix build farm?)
Tobias Geerinckx-rice 写道： PS: For the shorter term, I've applied for an 8-core POWER9 LE instance (with 16 GiB of RAM) for Guix at OSUOSL[1]. Assuming that it's accepted, it should be available within a week. Lance Albertson via RT 写道： On Thu Dec 12 17:21:37 2019, Tobias Geerinckx-Rice wrote: Hullo, Back in November I submitted a request[0] for a POWER9 OpenStack instance for the GNU Guix project. I landed on the ‘form_submitted’ page, but don't think I ever received a confirmation e-mail. Before I submit another form request: is there any chance my application somehow fell between the cracks? Thanks in advance, T G-R [0]: https://osuosl.org/services/powerdev/request_hosting/ Grr, I see it but it didn't get processed on our end. I'll manually import it and close this ticket. Sorry it was missed! Kind regards, T G-R signature.asc Description: PGP signature
Re: Guix mirror: sourceware discussion report
Zimoun, I've replied on IRC as well, apologies if I repeat myself. :-) zimoun 写道： Currently "guix pull" from Savannah and issues can arise. As we recently experimented. Tobias and Ricardo recently discussed how to mirror the repo. IMHO, it is a good idea to mirror but not a good idea to locate it on Ricardo infrastructure, again. :-) I disagree. I think berlin is the best place to create a simple ‘main’ mirror at this point in time. It's a simple git one-liner to keep it up to date. In the extremely unlikely event that it breaks, many people can fix it. Ricardo works hard but isn't responsible for all of Berlin on his own. Well, I propose to see if we can mirror on sourceware.org which are GNU friends. ;-) I took the liberty to contact them on IRC. See below. What I see is: we still "guix pull" from Savannah as usual. Then if Savannah is down, we catch the error and we try (transparently for the user) the sourceware url. By ‘we’, you mean the ‘guix pull’ command itself, correct? Something akin to (channel (name 'guix) (url (list "https://savannah…; "https://sourceware…;)) …) ? I'd like to see that added to the channels.scm format for selfish reasons. However, I'd still like the first or second URL to start with ‘guix.gnu.org’. I have nothing against Sourceware, but guix.gnu.org has been pretty solid (AFAIK) and, more importantly, does not require users to trust yet another party by default. [‘Trustable Guix pull’ rears its head again :-) …] As a first contact, they agree on the principle. Even they ask numbers about traffic etc. :-) I know that about 1,000 unique IPs requested substitutes on Berlin during the month of November. You'll have to ask Savannah for the git stats (roughly how many IPs ran ‘guix pull’), which may wildly differ (but I doubt that). Thanks! T G-R signature.asc Description: PGP signature
Re: The Guix Days: stream?
Hi Pjotr, On Thu, 12 Dec 2019 at 19:40, Pjotr Prins wrote: > > If yes, second question: will the ICAB network be strong enough? How > > can we test? > > Nope. Going by other years you should not rely on that. It is > unstable. So it is a no go to stream, isn't it? I mean, how could we cast without network? Ideas very welcome... :-) All the best, simon
Guix mirror: sourceware discussion report
Dear,
Currently "guix pull" from Savannah and issues can arise. As we
recently experimented. Tobias and Ricardo recently discussed how to
mirror the repo. IMHO, it is a good idea to mirror but not a good idea
to locate it on Ricardo infrastructure, again. :-)
Well, I propose to see if we can mirror on sourceware.org which are
GNU friends. ;-)
I took the liberty to contact them on IRC. See below.
What I see is: we still "guix pull" from Savannah as usual.
Then if Savannah is down, we catch the error and we try (transparently
for the user) the sourceware url.
As a first contact, they agree on the principle. Even they ask numbers
about traffic etc. :-)
What do you think?
All the best,
simon
--
[Fri Dec 13 2019]
I am working with Guix and we discussed mirroring the GNU Guix repo
on sourceware. [17:56]
The best before doing plan is to ask if it should be possible, on the
principle. [17:57]
is this a source code repo or somethign else?
(sorry, not familiar)
Also, what would be the reason for a mirror on sourceware if you already
have a repo? [17:58]
To be more concrete, and if you are not familiar with Guix, there is
command named "guix pull" which basically "git pull". Currently, the
main repo is on Savannah.
And everything is fine with Savannah. :-)
However, when Savannah is down; which happens, really rarely, but
happens, then all Guix is kind-of broken. [17:59]
so how big is this repo, what form is it, ? [18:00]
Broken means that the users cannot update their system. And it is not
related to development but related on normal usage. Well, "guix pull"
is kind-of equivalent to "apt-get update".
accessed via git or what?
we're not set up to host large binaries e.g. [18:01]
Yes, via Git. And it is only for source.
Maybe hold off on this until new sourceware is online?
The mirror of https://git.savannah.gnu.org/cgit/guix.git/
And if it is too big, maybe even only the master branch [18:02]
hm, I can't git-clone that bad boy here
ah never mind starting [18:03]
What I have in mind, and I speak for myself and not on the behalf of
the Guix project.
not that big apparently, some 170MB of content, that's not a problem
sorry, my browser returns me the wrong URL [18:04]
https://git.savannah.gnu.org/cgit/guix.git/
https://git.savannah.gnu.org/git/guix.git
yeah
do you have a personal sourceware presence already?
Just to be on the same wavelength, currently, each time an user run
"guix pull" then they "git pull" from
https://git.savannah.gnu.org/git/guix.git. However, when Savannah is
down which rarely happens, everybody is annoyed. So I would like that
"guix pull" catch the error and then try to use a mirror. Which
means, that sourceware.org/your-convention-guix will be the default
mirror. So the traffic pull will be very low (when Savannah is
[18:11]
down or unreachable) and the traffic push a bit more.
guix is awesome! But savannah often is overloaded :{
No I do not have a personnal sourceware presence already. [18:12]
* fche has no objection
how do you plan to make the local git repo a fresh enough mirror?
Then, I can ask to Savannah admin to have a hook to automatically
mirror to sourceware
or you can run a cron job on sourceware to auto git-pull periodically
[18:13]
yes, I have not think too much about the details. Because I would
like first if it was even possible. :-)
do you expect the repo to seriously grow over time ? [18:14]
No. But I can do some stats with Git to answer you more
precisely. Currently, Guix is around 13000 commits per
years. However, I do not know how many addition lines it represents
[18:16]
It guix.git is ~124MB currently. It normally sees multiple commits a
day, but most of them are fairly small (a couple of lines to a handful
of files). [18:18]
I mean it's not going to grow from 120MB to 1GB or 10G in the
forseeable future?
those are the levels at which we might get concerned
Who knows ;-) But I do not think so. And in case, you can say: stop,
it is too much for our infrastructure. [18:20]
Well, if we have a first agreement on an hostage (mirror), can I save
this conversation and post it on the mailing list guix-devel. Collect
feedback; especially from the maintainers. Then come back to you with
more concrete details. [18:21]
'forseeable' doesn't ask for infinite prophecy powers :)
:-)
yeah, I think we can do it.
thank you for your help.
but how much load on sourceware will this cause?
do you want to be CC of the email?
guix is very much pure GNU, and very much sources should produce
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello Zimoun, zimoun ezt írta (időpont: 2019. dec. 13., P, 17:32): > > Hi Gábor, > > Sorry to be slow. :-) I probably just did not express myself clearly enough. > > On Fri, 13 Dec 2019 at 17:28, Gábor Boskovits wrote: > > > > So in a more algorithmic manner: > > 1. if ad-hoc and inputs-of is present at the same invocation: fail > > hard. (With an error like incompatible options present) > > 2. if only ad-hoc is present, then print a deprecation warning (yes, > > we could make this suspendable with an environment variable, like you > > described) > > 3. if only inputs-of present, then do the new behaviour. > > 4. if neither ad-hoc nor inputs-of present then > > a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > > b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > > new behaviour. > > > > This would minimze friction, as there will be a few scripts falling under 4. > > This would also allow mirgating such scripts one by one. be defining > > GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using > > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that are > > fixed to use the new syntax. > > > > > > What do you think? > > I am perfectly aligned! :-) Great! > It is exactly what I have tried to describe. > Sorry again for being slow. I am sorry for the confusion, my communication tends to slugghish, an I am also a bit bound to do some hand-waving :) I hope to improve on that > > Thank you. > Do you plan to implement it? Do I give a try? I would like to hear something from Ludo, as he was also a participant of the IRC discussion. After that I would not mind if you gave it a try, if you would like. Otherwise I will implement it. > > > All the best, > simon Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Gábor, Sorry to be slow. :-) On Fri, 13 Dec 2019 at 17:28, Gábor Boskovits wrote: > So in a more algorithmic manner: > 1. if ad-hoc and inputs-of is present at the same invocation: fail > hard. (With an error like incompatible options present) > 2. if only ad-hoc is present, then print a deprecation warning (yes, > we could make this suspendable with an environment variable, like you > described) > 3. if only inputs-of present, then do the new behaviour. > 4. if neither ad-hoc nor inputs-of present then > a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > new behaviour. > > This would minimze friction, as there will be a few scripts falling under 4. > This would also allow mirgating such scripts one by one. be defining > GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that are > fixed to use the new syntax. > > > What do you think? I am perfectly aligned! :-) It is exactly what I have tried to describe. Sorry again for being slow. Thank you. Do you plan to implement it? Do I give a try? All the best, simon
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello, Let me try again :) zimoun ezt írta (időpont: 2019. dec. 13., P, 13:02): > > Hi Gábor, > > > On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits wrote: > > > zimoun ezt írta (időpont: 2019. dec. 12., Csü > > 17:47): > > >> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option > >> with a different effect? Or why do we want to conserve this option > >> name? > >> It appears to me simpler to give another name, for example > >> "--inputs-of". And it is more meaningful. > > > > Sorry for the confusion. Ad-hoc should be retained with the same effect, so > > that we do not break existing scripts. > > Renamin the option would be ok. It even makes sense to me. > > What I propose is: > > - keep the option "--ad-hoc" with the current behavior; so same effect > - add a new option "--inputs-of" with the new behavior; name more meaningful > - and two env variables; to not break existing scripts > > > >> First, when "--ad-hoc" is used then it reports a warning: deprecated > >> option and falls in the current behavior. > >> When "--inputs-of" is used then it falls in the new behavior. > >> Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc". > > > > That could be done. The problem is caused by uses of guix environment that > > does not use any of these options. Those mean different things after the > > change. > > The transition to such use-case was described below with the > introduction of 2 env variables. :-) > > > >> # Alice > >> $ guix environment foo --ad-hoc bar > >> Warning: deprecated... explanations... > >>instead use: > >> guix environment bar --inputs-of foo > >> > >> # Bob > >> $ guix environment bar --inputs-of foo > >> > >> > >> Second, the previous "guix environment foo" (dependencies of foo) is > >> inconsistent with the new "guix environment bar" (only the package > >> bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED > >> variable to distinguish both, as you said. > > > > Ok. > > It is the easy part. ;-) > > > Now the hard part: avoid to break existing scripts. > > >> # Alice > >> $ guix environment foo > >> Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1 > >>turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1 > >> > >> And Alice has now a new shell with the package foo. If she wants the > >> dependencies, she has two options: > >> > >> $ GUIX_ENVIRONMENT=1 guix environment foo > >> or > >> $ guix environment --inputs-of foo > >> > >> > >> # Bob > >> $ guix environment bar > >> Warning: previous behavior requires GUIX_ENVIRONMENT > >> > >> And if Bob is annoyed by the warnings each time, he globally turns off > >> with the variable GUIX_ENVIRONMENT_NOWARNING=1. > >> > >> > >> Couple of months later -- after the period adoption -- we remove the > >> variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED; > >> still keeping the warning with the "--ad-hoc" option. And then, after > >> we can remove the "--ad-hoc" option if required. > > > > We could recommend simply to use something like: > > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... > > Instead in existing scripts that are fixed to use the new syntax. This > > indeed looks like a better solution, and it is less of a maintenance > > burden. Good idea. > > My point is: the new variable GUIX_ENVIRONMENT_DEPRECATED should only > be used by the scripts that call "guix environment pkg" without the > options "--ad-hoc" or "--inputs-of". And I think that it represents > really few scripts in real life. :-) > > > > Summarizing: > > Introduce the environment variable. > > For fixed scripts recommend unsetting the environment variable. > > I am not to get your plan. :-) > > > Cheers, > simon So in a more algorithmic manner: 1. if ad-hoc and inputs-of is present at the same invocation: fail hard. (With an error like incompatible options present) 2. if only ad-hoc is present, then print a deprecation warning (yes, we could make this suspendable with an environment variable, like you described) 3. if only inputs-of present, then do the new behaviour. 4. if neither ad-hoc nor inputs-of present then a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the new behaviour. This would minimze friction, as there will be a few scripts falling under 4. This would also allow mirgating such scripts one by one. be defining GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that are fixed to use the new syntax. What do you think? Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Re: When to add rust packages?
Hi, I would send them as soon as you think they are usable, the "burden" is shared between people who are interested and work on maintaining them - you, or anyone else. No need to feel like it would be a burden to anyone.
Re: wrap-program –> wrap-script
Hello Ricardo, Ricardo Wurmus writes: > Hi Guix, > > I’ve just pushed a change to use wrap-script in one package. The > purpose of wrap-script is to wrap an executable without having to create > a separate wrapper shell script. It does this by prepending a Guile > script to the top of the file, which sets the environment variables and > then re-executes itself with the target interpreter (e.g. Python). That's smart! > I noticed two things: > > 1) wrap-script does not automatically pull in Guile as a dependency, so > if Guile isn’t among the inputs it will create a bad shebang. This > should be fixed on core- Since as you mention below, the wrap-script isn't much used at all, I guess the reason to make the change to core-updates rather than master is because the host module of wrap-script (guix build utils) is used as a whole when computing the hash of derivations? > 2) we aren’t using wrap-script anywhere. I think a good use case would > be the Python build system’s “wrap” phase where we currently use > wrap-program. Most of the time we’d be dealing with Python scripts, so > using wrap-script would be more appropriate here. > > What do you think? Are you considering "testing" for the type of file (e.g., script? binary?) before wrapping it? Something else? I like the idea in general. IIUC this would remove the need to have those ugly .real-script-name lying around. Maxim
When to add rust packages?
Hi Guix, I packaged a number of Rust programs that I use everyday (ripgrep, alacritty) or I found useful when learning Rust (racer). With the instability of the rust build system and package definition they are a lot to maintain. I would love to send patches for them but I don't want to burden you all with the maintenance of the packages. When do you think would be the best time to send patches? Thanks! John
NLNet grant "Next Generation Internet -- Search & discovery": I'm in!
Dear Guix community! I'm happy to let your know that my application to the NLNet "Next Generation Internet -- Search & Discovery" grant for Guix has been accepted! See https://nlnet.nl/project/GUIX/ (the description is misleading, see below). See also the European Union initiative website: https://www.ngi.eu/. This will allow me to work on Guix for a flexible period, probably between 6 months and 1 year. The bad news: Nope, IPFS is not part of the grant! :p So I won't be working on it myself in the context of NGI. But who knows, if I get extra time... (Or anyone else ;p). Here follows the current plan (subject to change). Ideas are welcome! /The main goal is to enhance search and discovery of Guix packages and services via a catalogue. The subgoal is to complete what “packages” and “services” are in Guix by completing them and broadening their domain./ 1. Parameterized packages (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html) Gentoo’s package manager, Portage, exposes a “USE flags” feature which allows users to customize packages in a way that composes (e.g. “disable the GUI elements of all packages” for a headless server). This essentially subdivides packages into smaller “components.” Since those components form the smallest atoms a user could search for, this is a prerequisite for the rest of the searchability improvements. Milestone(s) * Implement parameterized package support (mostly Guile code). * Write tests. * Document. * Community review. 2. File search (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html) Many package managers support looking up packages by the file paths they include. This feature is missing in Guix while being crucial for search, e.g. when the user knows the executable name which happens to be different from the package name. Milestone(s) * Implement file paths caching in the daemon (mostly C++). * Implement high-level command line interface for file search (mostly Guile). * Write tests. * Document. * Community review. * Deploy on the build farms. 3. User services Previous discussions: - Guix shepherd user services: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00128.html - Julien's home manager: https://lists.gnu.org/archive/html/guix-devel/2019-09/msg00185.html - Nix Home Manager: https://nixos.wiki/wiki/Home_Manager I believe there were many more discussion on user services on the mailing list, feel free to share them! Guix provides excellent integration with GNU Shepherd for system services (all configurations are programmable and composable using Guile). But it lacks integration for user services. User services can be used to replace much of the traditional “dotfiles” which are often ad-hoc hacks (e.g. environment variables, scripts, various program configurations such as GnuPG). The benefit is as for packages: the work of one can be redistributed to many. Finally, services are not searchable with Guix. We could fix this issue. Milestone(s) * Integrate Guix with GNU Shepherd to support user services. A user service should then automatically require the necessary packages, just like a system service does. For instance if the user sets up a GnuPG service, they don’t have to install GnuPG explicitly, Guix+Shepherd will take care of that. * Implement service search. * Write tests. * Document. * Community review. 4. Graphical user interface (GUI) *Question*: I recently read an email about someone (an intern?) working on a graphical installer. Can't find the email back though. Is someone still working on it? There could be a lot of work to factor here. Guix comes with a command line interface and some Emacs interfaces. None of them are particularly newcomer-friendly. Besides, much of the configuration is done by editing Guile files. The goal of this task is to make Guix more accessible to non-tech users by providing an intuitive user interface to most of Guix actions. Milestone(s) * Discuss with the Accessibility Group for the requirements. * Implement the GUI using Gobject-Introspection (Guile). 1. Live fuzzy-search. 2. Search packages. 3. Search file paths. 4. Search system/user services. 5. Configuration editor (generates a Guile configuration). * Write tests. * Document. * Community review. 5. Social integration with the Guix catalogue Previous discussions: - Adding wikidata, wikipedia & screenshot-url fields to package-recipes: https://lists.gnu.org/archive/html/guix-devel/2018-11/msg7.html - Re-approaching package tagging: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00385.html - New library: guile-wikidata: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00107.html -
Re: Parallel downloads
Pierre Neidhardt writes: > Update: I've been using --max-jobs=2 by default for about 2 weeks now, > and it feels like a much smoother experience overall: faster downloads, faster > builds. > > This is obviously a very dumb "optimization" but at least it serves to > underline that Guix could still do much better by parallelizing > downloads and build in a smart way. Agree. > > I couple of ideas were mentioned in this thread: Anyone interested in > working on them? :) When I get some time, I would be more than happy to help with this. -- Brett M. Gilio Homepage -- https://scm.pw/ GNU Guix -- https://guix.gnu.org/
Re: Store channel specification in profile
Hi Pierre,
On Thu, 12 Dec 2019 at 23:35, Pierre Neidhardt wrote:
>
> I've seen the "provenance" field mentioned a couple of times before, but
> I can't see any "provenance" in my $PROFILE/manifest file. Am I missing
> something?
>
> I install profiles with manifests.
You have right. It is a bug.
The manifest contains:
--8<---cut here---start->8---
(specifications->manifest
'("emacs"
"git"
"guile"))
--8<---cut here---end--->8---
Let create 2 profiles: one using the --manifest option and the other
one by plain --install.
--8<---cut here---start->8---
guix package -m /tmp/manif.scm -p /tmp/kikoo-manif
guix package -i emacs git guile -p /tmp/kikoo-nomanif
--8<---cut here---end--->8---
And here we are...
--8<---cut here---start->8---
grep provenance /tmp/kikoo-manif/manifest
--8<---cut here---end--->8---
versus
--8<---cut here---start->8---
grep provenance /tmp/kikoo-nomanif/manifest
(provenance
(provenance
(provenance
--8<---cut here---end--->8---
All the best,
simon
--8<---cut here---start->8---
guix describe
Generation 60 Dec 13 2019 12:52:55(current)
guix eb8aad6
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: eb8aad6a23442cf7b23e0df88b89b4cd030dfbf5
--8<---cut here---end--->8---
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Gábor, On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits wrote: > zimoun ezt írta (időpont: 2019. dec. 12., Csü > 17:47): >> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option >> with a different effect? Or why do we want to conserve this option >> name? >> It appears to me simpler to give another name, for example >> "--inputs-of". And it is more meaningful. > > Sorry for the confusion. Ad-hoc should be retained with the same effect, so > that we do not break existing scripts. > Renamin the option would be ok. It even makes sense to me. What I propose is: - keep the option "--ad-hoc" with the current behavior; so same effect - add a new option "--inputs-of" with the new behavior; name more meaningful - and two env variables; to not break existing scripts >> First, when "--ad-hoc" is used then it reports a warning: deprecated >> option and falls in the current behavior. >> When "--inputs-of" is used then it falls in the new behavior. >> Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc". > > That could be done. The problem is caused by uses of guix environment that > does not use any of these options. Those mean different things after the > change. The transition to such use-case was described below with the introduction of 2 env variables. :-) >> # Alice >> $ guix environment foo --ad-hoc bar >> Warning: deprecated... explanations... >>instead use: >> guix environment bar --inputs-of foo >> >> # Bob >> $ guix environment bar --inputs-of foo >> >> >> Second, the previous "guix environment foo" (dependencies of foo) is >> inconsistent with the new "guix environment bar" (only the package >> bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED >> variable to distinguish both, as you said. > > Ok. It is the easy part. ;-) Now the hard part: avoid to break existing scripts. >> # Alice >> $ guix environment foo >> Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1 >>turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1 >> >> And Alice has now a new shell with the package foo. If she wants the >> dependencies, she has two options: >> >> $ GUIX_ENVIRONMENT=1 guix environment foo >> or >> $ guix environment --inputs-of foo >> >> >> # Bob >> $ guix environment bar >> Warning: previous behavior requires GUIX_ENVIRONMENT >> >> And if Bob is annoyed by the warnings each time, he globally turns off >> with the variable GUIX_ENVIRONMENT_NOWARNING=1. >> >> >> Couple of months later -- after the period adoption -- we remove the >> variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED; >> still keeping the warning with the "--ad-hoc" option. And then, after >> we can remove the "--ad-hoc" option if required. > We could recommend simply to use something like: > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... > Instead in existing scripts that are fixed to use the new syntax. This indeed > looks like a better solution, and it is less of a maintenance burden. Good > idea. My point is: the new variable GUIX_ENVIRONMENT_DEPRECATED should only be used by the scripts that call "guix environment pkg" without the options "--ad-hoc" or "--inputs-of". And I think that it represents really few scripts in real life. :-) > Summarizing: > Introduce the environment variable. > For fixed scripts recommend unsetting the environment variable. I am not to get your plan. :-) Cheers, simon
