Re: Using --manfistest with /manifest files
Hello! elaexuo...@wilsonb.com writes: > FWIW, I never expected `/manifest' to encode "this is what the user > ordered," so much as "this is the recipe for (deterministically) reproducing > this exact profile." For the former we have `packages->manifest', > `specifications->manifest' etc. The latter is what I understand this > discussion > to be about. I am sorry if it sounded like I was criticizing your level of guix knowledge. Not my intent. You knowledge seems very high to me ;-) I do admit to taking advantage of your public suffering in this guix "trap" ... > $ guix environment -m ~/.guix-profile/manifest > (manifest ...): Wrong number of arguments ... and Ludo's acknowledgment of the "source of confusion that these ‘manifest’ files are not like the ‘manifest.scm’ files" that landed you there to recycle a fix I proposed earlier: https://lists.gnu.org/archive/html/guix-devel/2018-10/msg00011.html Motivation: I see others fall into this trap periodically. When they report their difficulty they get this "~/.guix-profile/manifest is not a manifest" lecture. This is a waste of time for all. It must be truly annoying for someone in the trap to hear. And of course I fell into the trap circa 2017 ;-) FWIW, I support your request. In fact, I acctually suggest something similar in the post referenced above. HTH - George
Re: Using --manfistest with /manifest files
Hi zimoun, zimoun writes: > In contradiction with what I wrote above, I agree. :-) > > /manifest should be renamed /specifications or > something like that. > > And a comment could be inserted in this file saying: internal usage, do > not modify, etc.. > > WDYT? Sure, that would work. But, on further thought, I would like to amend my suggestion -- to change which ever is easier. I say that because ... "manifest" occurs ~600 times in the ./guix directory. I am guessing its use is deeply embedded with developers. If so, renaming it internally seems like a bad idea. And if we write our internal manifest into the profile and call it "specifications" it will only add the confusion. OTOH, "manifest" occurs only ~50 times in guix.info and the "user API" seems limited to the --manifest option and the functions: specifications->manifest and packages->manifest. Furthermore it is a new concept for new users. So I don't think users care what we call it. Bottom line: change whichever is more convenient for developers. HTH - George
Re: Using --manfistest with /manifest files
Ludovic Courtès writes: > elaexuo...@wilsonb.com skribis: >> First, am I missing something? Is there a better/preferred way to make use of >> the `manifest' files in profiles? > You’re not missing anything: it’s a longstanding source of confusion > that these ‘manifest’ files are not like the ‘manifest.scm’ files. > These ‘manifest’ files are meant for internal consumption. This hurt my head for a while a few years ago until I realized that 'manifest.scm' is the guix "order" and ‘.guix-profile/manifest’ is the guix "packing list". But actually a guix' 'manifest' packing list goes well beyond what we normally find in a packing list by containing detailed info about how the specific products were made, down to the specific design for the specific version shipped. Thought of this way it is easy to understand why a receiver of a 'manifest' can only estimate the set of 'manifest.scm' that might produce it. A simple-minded example: did the manifest.scm specify the version of the package shipped or is this an artifact of a) when 'manifest.scm' was processed or b) of the requirements of the other packages that were received? In any event, once I saw it this way it no longer troubled me that guix doesn't have a pushbutton way to "reverse" 'manifest' into 'manifest.scm'. ISTM we set ourselves up for confused users and a lot of explaining by labeling two very different things with same name :-0 Yes, only 'manifest.scm' is in the doc, but '.guix-profile/manifest' smacks a user in the face pretty quickly which leads to these messy questions. IMO we could dramatically simplify the situation, and simplify our lives, by simply renaming the .guix-profile/manifest file ;-) George
Re: Manual consistency
zimoun writes: > (from: http://issues.guix.gnu.org/issue/41253#10) > > On Fri, 5 Jun 2020 at 18:36, Ludovic Courtès wrote: > >> > There are many examples in guix.texi with $, and also many without. Plus >> > some with # as the command line prompt. >> I’ve come to the conclusion that snippets that contain only input should >> be written without a prompt, for easier copy/pasting. > I propose to do a pass on that: > - apply this rule: no-$ for only input and $ to distinguish between > inputs and outputs. +1. For examples w/ outputs, how about also removing the $ and commenting the outputs with '# ', or '# > '? HTH - George
Re: Any interest in using HTML for locally-installed Texinfo documentation?
Hi Gavin, Gavin Smith writes: [...] > A manual with this interface added is at > https://www.gnu.org/software/texinfo/manual/texinfo-html/Overview.html. > All the important keyboard commands that work in the Info viewers are > implemented, including index lookup. Nice! I like seeing Info commands work on WWW-posted doc. This would be useful to an Emacs/Info user for packages that aren't installed or when their Info system is broken. To reach the more numerous "non Emacs/Info users", these commands need to be advertised and promoted. Is there a plan for this? WRT the current implementation ... In Emacs and Info, typing 'h' shows Info keyboard commands. It didn't do anything visiting this site with CHROME and Safari. It would be nice if a second 'C-s' advanced to the next match without requiring . 'C-s' on the site is so slow that I thought it was broken at first :( HTH - George
Re: Communication and Design at Guix
Hi Lprndn, I am glad to see your interest in these issues. Ludovic Courtès writes: > Hi, > > L p R n d n skribis: > >> Ludovic Courtès writes: > > [...] > >>> A very concrete task that could be of interest to you is the “name >>> change” (a bit of a strong word) that we’d like to implement by 1.0. >>> I’ll try to summarize. Currently we have “Guix” and “GuixSD”, and that >>> confuses things: people visit the web site, they see a “GuixSD” logo and >>> get confused because they were just looking for a package manager, not a >>> whole distro, or they think “GuixSD” is a storage device ;-), things >>> like that. >>> >>> The idea is to bring everything under the “Guix” name. Most of the >>> time, writing “Guix” is good enough—after all, one can run ‘guix system’ >>> on a foreign distro, too. When we really need to make the distinction, >>> for instance in the manual, we would write “Guix System” to designate >>> what we currently call “GuixSD”. >> >> Hum. It might just be as easy as getting rid of the GuixSD logo and >> wording for the most part. Then we can find a *preferred* way to >> designate GuixSD (a Guix system (probably), Guix distro, Guix os).Here, >> it's more about making GuixSD "disappear" but we could also just rebrand >> GuixSD with some kind of "subtitle": "Guix, the system", derive a logo >> from the Guix's one. It depends a lot from what we want to put under >> the spotlight. > > The idea is more to have a single “brand”: Guix. Yes a single brand is the way to go. But, piecemeal changes to the web site are unlikely to get us there unless we work from a unified "Guix Brand" product description. E.g., earlier I proposed ... "'Guix' is a software environment manager that creates user environments that are completely and independently specified by users. Guix users are never stuck needing software that a Sysadmin can't, won't, or hasn't installed. A Guix user can run multiple, differing environments simultaneously and can replicate any environment on any Guix run-time platform. Guix provides system-wide environment management when appropriate to the run-time platform. Creation, modification, and upgrade are atomic and roll-back is instantaneous, so Guix users and sysadmins are never stuck with a broken user environment or system. Guix implements a functional specification of package, user, and system configurations using the Scheme language. Guix complies with the FSF Four Essential Freedoms and Free System Distribution Guidelines and provides easy and immediate access to the exact source being run. By default, Guix uses pre-built package substitutes from the Guix build farm and mirrors but users may build any package, or a complete system, from package developer sources."[1] > Then “Guix System” would be a component of Guix, so to speak, similar > to GNOME and its applications. "Guix System" is a "bad" name for "GuixSD." Why? Because a new user's first expectation is for "Guix system" to refer to the whole of Guix, which we want to call "Guix" (referred to as "Guix Brand" below). But if we call GuixSD the "Guix System", we create a counter-intuitive thing to explain. E.g., we will be saying, "Our GNU/Linux System Distribution, 'Guix System' is just one of multiple ways to use 'Guix Brand', which includes the Guix package manager, for which we also use the 'Guix Brand' label. Another "bad" thing about calling it "Guix system" is that when a user searches "guix system" they hit the 'guix system' "Guix Brand" package manager' command that, BTW, also generates "Guix VMs". It will simplify our work if we present GuixSD as simply one of several Guix download/deployment options. E.g., earlier I suggested ... "Guix is available on multiple run-time platforms including bare metal (GuixSD), Virtual Machines (QEMU image), and any GNU/Linux distro (Guix Binary).[1]" With this approach, we only need a distinctive label for GuixSD that doesn't puzzle users to produce reliable search hits on the relevant parts of our message and documentation. E.g., GuixOS. HTH - George [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00444.html
Re: End of beta soon? drop i686?
swedebu...@riseup.net writes: > First of all thanks for building a great OS! +1 > In my view we still have a system where encountering a bug is still far > more common than any other OS I ever used. +1 > To sum it up: lets not ruin what we have by rushing ahead and ending > beta too early. +1 FWIW, GuixSD has been my daily headless server driver for ~3 years.
Re: Promoting the GNU Kind Communication Guidelines?
Hello Ricardo Wurmus writes: > Hello Mathieu, > >> Mathieu Lirzin skribis: >> >>> Following the announcement made by RMS regarding the new GNU Kind >>> Communication Guidelines (GKCG) [1], I would like to know if the Guix >>> developpers in particular its maintainers would agree to adopt it in >>> place of the current Code of Conduct (CoC)? >> >> Speaking for myself: no. I think the GKCG fails to address important >> issues, such as defining what’s acceptable and what’s not as well as >> clear processes to address this. > > [Apologies for the delay; I’m currently traveling.] > > Adding to what Ludovic wrote, I also would not want to replace the > current proven Contributor Covenant with the recently emerged GKCG. > Using *both* of them would not be useful, I think, as I find our current > CoC to be sufficient; using *only* the GKCG and dropping the existing > CoC would be a mistake in my opinion, as our CoC describes a process > which the GKCG does not. > > Committing to a process to deal with grievances is a very desirable > feature of our current CoC that I don’t want to give up. As one of the > people who shares responsibility for dealing with incidents of > harassment or misunderstandings, this helps me do a better job. > > Even so, I encourage people to continue to engage in fostering kind > communication in the channels of the Guix project, something that this > community by and large does very well. > >>> Adopting the GKCG instead of a CoC would help attracting people (like >>> me) who agree to use a welcoming and respectful language which >>> encourages everyone to contribute but are reluctant in contributing to >>> any project following a CoC due to its punitive nature and the politics >>> of its authors [2][3]. > > To me the politics of the author(s) of the original or current version > of the Contributor Covenant don’t play much of a role in prefering it as > a practical guiding document for this community. (I don’t know the > author.) > > I think I see how it could be seen as “punitive”, but I don’t share this > assessment. We all want what’s best for the project and the people who > currently work on or consider working on it — to me the emergence of the > GKCG is more evidence that this is true. I hope that seeing these > similarities in intent more than the differences in implementation will > allow you to overcome your feeling of reluctance to contribute to Guix > (and other projects that have decided to adopt a CoC). The responses above seem consistent with why CoC mightq appeal to maintainers. But as a Guix user and occasional contributor, I find GKCG more welcoming and more useful. For me, RMS' rationale is compelling: The idea of the GNU Kind Communication Guidelines is to start guiding people towards kinder communication at a point well before one would even think of saying, "You are breaking the rules." The way we do this, rather than ordering people to be kind or else, is try to help people learn to make their communication more kind. It is really the either-or situation implied by the discussion above? What would be wrong with adding GKCG and keeping CoC? - George
Re: ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..
Ludovic Courtès writes: > Hello, > > Ricardo Wurmus skribis: > [...] >> You can put this in a file “manifest-to-manifest.scm” and run it like >> this from a Guix source checkout: >> >> ./pre-inst-env guile -s manifest-to-manifest.scm /path/to/.guix-profile >> > my-manifest.scm > > I like how the script’s name highlights the naming inconsistency. :-) ... and that we should consider renaming one of these "manifests" ;-) >> You can then proceed to install the generated manifest with: >> >> guix package -m my-manifest.scm -p /path/to/new/.guix-profile >> >> If that’s what you’re looking for I suppose we could find a place for >> something like that under the umbrella of “guix package”. > > The problem, as I see it, is that this might give a false impression > that both “manifests” are entirely equivalent, which is not the case. This "false impression" is caused by the "naming inconsistency" (above) rather that by the proposed function, isn't it? > I sympathize with George’s idea of making it easier to move from the > incremental style to the declarative style, but I wonder if we should go > beyond suggesting to basically copy the package names shown in “guix > package -I” to the manifest file. Does this mean to have "manifest-to-manifest.scm" add any non-default (in the current Guix version) package outputs and versions to the package specifications produced? Or something else? - George
Re: Blog: Guix packaging tutorial
This LGTM except ... the first paragraphs (quoted below) are an advertisement. This is out of place in a tutorial. So, IMO, they should simply be removed. > GNU Guix stands out as the *hackable* package manager, mostly because > it uses [GNU Guile](https://www.gnu.org/software/guile/), a powerful > high-level programming language, one of the > [Scheme](https://en.wikipedia.org/wiki/Scheme_(programming_language)) > dialects from the [Lisp > family](https://en.wikipedia.org/wiki/Lisp_(programming_language)). > > Package definitions are also written in Scheme, which empowers Guix in > some very unique ways, unlike most other package managers that use > shell scripts or simple languages. > > - Use functions, structures, macros and all of Scheme expressiveness > for your package definitions. > > - Inheritance makes it easy to customize a package by inheriting from > it and modifying only what is needed. > > - Batch processing: the whole package collection can be parsed, > filtered and processed. Building a headless server with all graphical > interfaces stripped out? It's possible. Want to rebuild everything > from source using specific compiler optimization flags? Pass the > `#:make-flags "..."` argument to the list of packages. It wouldn't be > a stretch to think [Gentoo USE > flags](https://wiki.gentoo.org/wiki/USE_flag) here, but this goes even > further: the changes don't have to be thought out beforehand by the > packager, they can be *programmed* by the user! If you don't remove them, then at least move the paragraph quoted below to the top of the piece ... > The following tutorial covers all the basics around package creation > with Guix. It does not assume much knowledge of the Guix system nor > of the Lisp language. The reader is only expected to be familiar with > the command line and to have some basic programming knowledge. ... and preface the above mentioned paragraphs with something like ... # Guix is a unique approach to package management HTH - George
Re: ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..
Ricardo Wurmus writes: > Hi George, > >> My thinking is that if there was an easy way to produce “manifests as >> passed to ‘guix package -m’” from profiles, it would be a handy: an easy >> way for someone that has gone down the incremental path to switch to >> manifests and an easy way to update one's manifest after incremental >> changes. > > Do you mean something like this? > > --8<---cut here---start->8--- > (use-modules (guix profiles) > (ice-9 match) > (ice-9 pretty-print)) > > (match (command-line) > ((_ where) >(pretty-print > `(specifications->manifest > ',(map manifest-entry-name (manifest-entries (profile-manifest > where)) > (_ (error "Please provide the path to a Guix profile."))) > --8<---cut here---end--->8--- > > You can put this in a file “manifest-to-manifest.scm” and run it like > this from a Guix source checkout: > > ./pre-inst-env guile -s manifest-to-manifest.scm /path/to/.guix-profile > > my-manifest.scm > > You can then proceed to install the generated manifest with: > > guix package -m my-manifest.scm -p /path/to/new/.guix-profile > > If that’s what you’re looking for I suppose we could find a place for > something like that under the umbrella of “guix package”. Hi Ricardo, Nice! Yes, this is the idea and it worked here for me, thank you. Ideally this would recover additional package specification details when needed. E.g., I did 'guix package -i guile@2.2:debug' but only "guile" was added to my-manifest.scm. TIA! - George
Re: ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..
Hi Ludo’,
Ludovic Courtès writes:
> Hello,
>
> George Clemmer skribis:
>
>> YOANN hit an error when trying to do 'guix package -m
>> ~/.guix-profile/manifest'. Why would one want to do this? Maybe to
>> (re)produce a configuration previously reached by a series of 'guix
>> package -i' operations?
>
> I agree this would be nice, but be aware that this is not quite possible
> because those files don’t have enough information to rebuild packages.
>
> Starting from a few weeks/months ago, ~/.guix-profile/manifest records
> upstream VCS information, like this:
>
> ("libreoffice"
> "6.1.2.1"
> "out"
> "/gnu/store/y4l3r7nh0dg3d8qaifz96ffab4jpjl3s-libreoffice-6.1.2.1"
> (propagated-inputs ())
> (search-paths ())
> (properties
> (provenance
> (repository
> (version 0)
> (url "https://git.savannah.gnu.org/git/guix.git;)
> (branch "master")
> (commit
> "f8e710684e5c3f866413dff825ba17bdffceac5d")
>
> With this info and with inferiors and channels, it becomes possible to
> rebuild the package (if we make simplifying assumptions.)
>
> So I understand the need and agree that it would be nice. But for now,
> I strongly recommend “manifests as passed to ‘guix package -m’” because
> they’re much more expressive, especially with the introduction of the
> inferior API:
>
> https://issues.guix.info/issue/32759
IIUC, you are describing more-or-less "exact" (re)production of an
existing profile. But that's not what I was thinking of when I said
"(re)produce a configuration". Rather, I was thinking (as described
elsewhere in the original post) of the ability to produce “manifests as
passed to ‘guix package -m’” from an existing profile.
Why? In part to smooth over a puzzling inconsistency in guix
configuration: Systems configuration is "declarative" but user-profiles
may be "incremental" ('guix package -i') or "declarative" ('guix package
-m').
My thinking is that if there was an easy way to produce “manifests as
passed to ‘guix package -m’” from profiles, it would be a handy: an easy
way for someone that has gone down the incremental path to switch to
manifests and an easy way to update one's manifest after incremental
changes.
HTH - George
Re: ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..
Ludovic Courtès writes: > Hello, > > YOANN P skribis: > >> I was thinking than "~/.guix-profile/manifest" was a valid manifest file due >> to his name, but it seems not that is the case from the error i've got >> >> https://pastebin.com/Z7h2t5mL >> >> After some search , i've finally understand that the instantiated profile >> couldn't be used as source profile for "guix package -m" etc... due to the >> same words despite use case and is a bit confusing > > I agree it’s a bit confusing. The manual does make it clear that -m > expects source code that evaluates to a manifest object, though. > >> https://gnunet.org/bot/log/guix/2016-05-27#T1040380 >> >> It will be really convenient to only have the instantiate profile to easily >> maintain it in a vcs system. >> >> Despite what ludo said in 2016 on IRC, i didn't see those options yet. >> Did i missed them ? >> If not implemented yet, any news about this feature ? :) > > No news I’m afraid :-) but I’ve opened an issue so we keep track of it: > > https://issues.guix.info/issue/32844 Hi Ludo’, Your bug doesn't capture some other manifest issues ... "~/.guix-profile/manifest" and 'guix package --manifest=FILE' use the same term/filename for markedly different things and the doc is silent on the distinction. While "~/.guix-profile/manifest" may be internal to Guix, users will inevitably trip across it and be confused (as YOANN did here, and I did a year ago). We might avoid confusion and make documentation easier by renaming one of these. Consider ... We are using "~/.guix-profile/manifest" in a way that is consistent with a common use, e.g., shipping manifest, which specifies information not in the associated order and at a level of detail that can only be determined at shipment (e.g. serial number). Our use of manifest in 'guix package --manifest=FILE' is rather less intuitive. In fact this FILE is more like an order than a manifest, IMO. As the doc says, [the manifest] 'FILE must return a “manifest” object, which is roughly a list of packages'. If we were to rename this a "package-list" or "package-spec", this would be more intuitive and self-explanatory (at least to me, an English speaker), and make the doc easier to write/understand. YOANN hit an error when trying to do 'guix package -m ~/.guix-profile/manifest'. Why would one want to do this? Maybe to (re)produce a configuration previously reached by a series of 'guix package -i' operations? In most situations, rather than a "~/.guix-profile/manifest" file, one wants to use a 'guix package --manifest=FILE', since this is more durable over time and easier to maintain (e.g. in SCC). So, IMO, it would be useful to have something like ... guix package --manifest-from-profile -p ~/.guix-profile > FILE ... which returns a "minimally specified" FILE that allows 'guix package --manifest=FILE' to reproduce "~/.guix-profile". - George
Re: Roadmap for Guix 1.0
Gábor Boskovits writes: > George Clemmer ezt írta (időpont: 2018. aug. 30., Cs, > 21:14): > >> >> Ricardo Wurmus writes: >> >> > Ludovic Courtès writes: >> > >> >> Hello, >> >> >> >> I think “Guix System” is OK. >> > >> > I think so too. >> >> I recommend against renaming GuixSD >> "Guix System". Here is Why: >> >> 1) A noob would expect "guix system" to refer to the whole Guix >> enchilada. If we use it to refer to GuixSD, a specific Guix deployment >> mode, we have created a new, counter-intuitive thing we have to explain. >> >> 2) As Ricardo points out below, the "guix system" command clashes with >> this use of Guix system. This is a second counter-intuitive thing we >> would have to explain. >> >> Bottom line: we shouln'd use the general term "Guix System" in any way >> beyond, perhaps in a descriptway way, e.g., The Guix project develops >> the Guix System, a set of tools that manage software environments. >> >> >> Most of the time we’ll just say “Guix”, as >> >> is already the case, and when we need to disambiguate (for instance when >> >> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you >> >> using the Guix distro?”, and everything will be fine. :-) >> > >> > Exactly. >> > >> > I wrote this on IRC: >> > >> > The name “GuixSD” is opaque and creates an arbitrary distinction between >> > the system running on bare metal and the systems you can create with the >> > “guix system” commands. It makes it difficult to communicate about >> > Guix. Do we really offer “a package manager” and a “distro” — or is it >> > really all one thing with various levels? >> > >> > The “guix system” command can be used without GuixSD to create Guix >> > virtual machines or containers. Describing “guix system” is difficult >> > when we think in terms of “package manager” vs “distro”. Guix itself is >> > also a distro – none of the packages it provides link with the host >> > system, and the collection of packages is a distribution of free >> > software. >> > >> > I think that simplifying the name by using “guix” as a category will >> > make communication easier. >> > >> >> The motivation for this name change is that “SD” is obscure to most, as >> >> you note, plus it creates confusion when people visit the web site: the >> >> web site has a “GuixSD” logo, but then it talks about features of the >> >> package manager. Designating the whole tool set as “Guix” will simplify >> >> this, and we can always be more specific when we need to. >> > >> > I agree. >> >> I agree too. You may recall that I recommendi this approach when we >> discussed the web site in January. That thread includes a product >> description [1] that might be a good place to start when describing the >> "whole tool set". >> >> [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html >> >> What do you think about GuixSD >> "Guix Distribution"? This naming seems > to resolve the ambiguities mentioned so far, and has a widespread > use, that exactly matches the intended meaning. WDYT? Hi Gábor, I think this discussion was primarily triggered by the realization that we can improve the top-level presentation of Guix by downplaying the distinction between Guix and GuixSD. In fact, we could delay the introduction of Guix/GuixSD to the download page. A more informative download page might look like: Use Guix to manage ... entire computers: GuixSD download options: x86_64 i686 VMs: download options: GuixSD x86_64-QEMU-image GNU/Linux user environments: Guix download options: x86_64, i686, armhf, aarch64 Here we see the primary purpose of the Guix/GuixSD labels is to identify the different download options and to enable the user to find the correct install instructions and doc sections for whatever they download. GuixSD doesn't necessarily need to be changed. But the issue has been raised, as mentioned above, that because "SD" is not a recognized abbreviation "GuixSD" carries no intuitive meaning. If we want an improved label for the Guix system distribution, the best one is probably "GuixOS" since "OS" is a widely used and recognized abbreviation ... Termgoogle hits OS 3.0 * 10**9 operating system0.7 * 10**9 system distribution 0.5 * 10**9 I guess the issue with this is that it seems odd to say "the GNU Guix GNU/Linux System Distribution, abbreviated GuixOS" ;-) HTH - George
Re: Roadmap for Guix 1.0
Ricardo Wurmus writes: > Ludovic Courtès writes: > >> Hello, >> >> I think “Guix System” is OK. > > I think so too. I recommend against renaming GuixSD >> "Guix System". Here is Why: 1) A noob would expect "guix system" to refer to the whole Guix enchilada. If we use it to refer to GuixSD, a specific Guix deployment mode, we have created a new, counter-intuitive thing we have to explain. 2) As Ricardo points out below, the "guix system" command clashes with this use of Guix system. This is a second counter-intuitive thing we would have to explain. Bottom line: we shouln'd use the general term "Guix System" in any way beyond, perhaps in a descriptway way, e.g., The Guix project develops the Guix System, a set of tools that manage software environments. >> Most of the time we’ll just say “Guix”, as >> is already the case, and when we need to disambiguate (for instance when >> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you >> using the Guix distro?”, and everything will be fine. :-) > > Exactly. > > I wrote this on IRC: > > The name “GuixSD” is opaque and creates an arbitrary distinction between > the system running on bare metal and the systems you can create with the > “guix system” commands. It makes it difficult to communicate about > Guix. Do we really offer “a package manager” and a “distro” — or is it > really all one thing with various levels? > > The “guix system” command can be used without GuixSD to create Guix > virtual machines or containers. Describing “guix system” is difficult > when we think in terms of “package manager” vs “distro”. Guix itself is > also a distro – none of the packages it provides link with the host > system, and the collection of packages is a distribution of free > software. > > I think that simplifying the name by using “guix” as a category will > make communication easier. > >> The motivation for this name change is that “SD” is obscure to most, as >> you note, plus it creates confusion when people visit the web site: the >> web site has a “GuixSD” logo, but then it talks about features of the >> package manager. Designating the whole tool set as “Guix” will simplify >> this, and we can always be more specific when we need to. > > I agree. I agree too. You may recall that I recommendi this approach when we discussed the web site in January. That thread includes a product description [1] that might be a good place to start when describing the "whole tool set". [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html
Re: Roadmap for Guix 1.0
Hi, Ludovic Courtès writes: > Hello, > > Pierre Neidhardt skribis: > >> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we >> will end up with a bunch Guix FS, Guix IP, Guix CD... > > I think “Guix System” is OK. Most of the time we’ll just say “Guix”, as > is already the case, and when we need to disambiguate (for instance when > addressing bugs), we’ll ask “Are you using Guix System?” or “Are you > using the Guix distro?”, and everything will be fine. :-) > > The motivation for this name change is that “SD” is obscure to most, as > you note, plus it creates confusion when people visit the web site: the > web site has a “GuixSD” logo, but then it talks about features of the > package manager. Designating the whole tool set as “Guix” will simplify > this, and we can always be more specific when we need to. This is good because it declutters the Guix-Verse for new users. I suggest that the distinction between GuixOS, package manager, QEMU image, and source can be re-positioned as download options. We could simplify the choice of these by improving the download page. For example ... 1) We could simplify the download labels/descriptions, e.g., "GuixSD 0.15.0 QEMU Image QCOW2 virtual machine (VM) image. Download options: x86_64" ... might become ... "x86_64 VM (GuixSD 0.15.0 QEMU Image QCOW2 virtual machine image)" 2) We could add a feature check list that helps with download selection. With such changes the support question is: what did you download? IMO it would be desirable to pick a single term for each download option and use it obsessively throughout the site and doc. This small thing can be quite helpful to a noob because it eliminates any confusion that might be caused by multiple terms meaning the same thing. So, IMO we should settle on only one of Guix System, GuixSD, GuixOS, or maybe "Guix bare metal". - George
Re: [doc RFC] Tame the Guix profile blizzard?
Hi Nils, Nils Gillmann writes: > 4) before each profile kind is used for the first time, > make use of something like this for the brief introduction > of it again (our manual is not very long, but it is still > long): I Agee. > @cartouche > @quotation Note > In the following ``spacejump'' refers to … > @end quotation > @end cartouche > > this renders at least in HTML and PDF output of texinfo. I haven't > used this very much so far. > > A visual example can be found in 'Exchange', Chapter 'Configuration' > in https://docs.taler.net/ I assume you refer to the box that reads, "Note: The rationale behind having multiple bank accounts ..." and I agreed this would work well. - George
Re: [doc RFC] Tame the Guix profile blizzard?
Ludovic Courtès writes: > Hi George, > > George Clemmer skribis: > >> ISTM we can improve this situation as follows: >> >> 1) agree on a canonical term to use for the 4 types of profiles > > I think you mentioned only two types of “profiles”: one is profiles > created by ‘guix package’ or ‘guix environment’ or ‘guix system’ (they > are all the same kind of “profile”), and the other one is execution > profile, which has nothing to do with that. > > So to me it seems that “profile” is in fact used fairly consistently, > isn’t it? Yes ... but ... the use of these profiles produces subtly different "side-effects". Package operations cause changes in the user's "default" profile that are immediately "used" in the user environment. However 'guix package -p foo' does not cause foo to be "used". 'guix environment --ad-hoc' causes the environment profile to be "added" to the user's environment, but --pure substitutes it for both system and "default" profiles IIUC. IMO these could be better explained and more easily referenced by users if we develop a structured nomenclature to distinquish between these. > However… > >> 3) add a top level discussion of profiles > > … we surely need this. Someone we should clearly define “profile” > somewhere upfront. Perhaps we also need a glossary. Agreed
[doc RFC] Tame the Guix profile blizzard?
ISTM our doc is a veritable "Profile Blizzard." The term occurs 173 times in guix.texi The "user profile" is referred to in multiple ways: (guix) Application Setup: "your Guix profile" (guix) Features: 'own “profile”', "per-user profiles", "their profile" (guix) Invoking guix package: "user’s own profile", "user’s default profile", ‘$HOME/.guix-profile’ (guix) Invoking guix environment: "package profile" The "system profile" is referred to in multiple ways: (guix) Using the Configuration System: "Globally-installed packages" (guix) operating-system Reference: "global profile", ‘/run/current-system/profile’ (guix) Networking Services: "system profile" An unnamed type of "environment profile" is produced by 'guix environment' (guix) Invoking guix environment" ‘GUIX_ENVIRONMENT’ variable An unnamed type of "custom profile" is produced by the 'guix package' -p option. (guix) Top mentions only an entirely different use of the term: * Invoking guix size:: Profiling disk usage. (guix) Concept Index contains only (guix) Invoking guix package references. ISTM we can improve this situation as follows: 1) agree on a canonical term to use for the 4 types of profiles 2) update the doc accordingly 3) add a top level discussion of profiles WDYT? - George
Re: guix package is slow
Alex Kost writes: > "M-x guix" can't be an entry point for this or any other interface, it > is only for "guix" *shell* commands. Actually I'm very surprised > someone uses "M-x guix", I find it unpractical. Agreed. FWIW, when I am trying to find an emacs-guix command I type 'M-x guix-' and search the completions. But sometimes I forget the '-' and when this pops up I am like ... UGH ;-( I wanted to use and like the "M-x Guix" pop-up, I really did. I figured the Guix CLI needed all the help it could get ;-) I tried several times to learn this, but I just couldn't get the hang of it. I also tried it in magit and it didn't work for me there. This makes me wonder: a) Am I am a dope? b) Do people really use this? > I even plan to rename it to "M-x guix-command", and to make "M-x guix" > a real entry point for the various Emacs-Guix commands (including > "guix-command" and all the interfaces). That's a great idea. If "M-x guix" is not widely used you might consider deleting it altogether. - George
