Re: Profiles/manifests-related command line interface enhancements

On Sun, Dec 22, 2019 at 08:40:25PM +0100, Andreas Enge wrote: > Could we reach out to some experienced UI designers? Is there actually > any such thing as "CLUI designers"? These things grow over time. I think with our current knowledge we could put it to the vote. Also some of the default behavio

Re: Profiles/manifests-related command line interface enhancements

Hello, I am reading up on old threads during the holiday season... On Sun, Nov 17, 2019 at 12:30:11PM +0100, Konrad Hinsen wrote: > If enough people are willing to work on this (beginners included!), we > could run a "CLI working group" that plays with alternatives to the > current CLI, implement

Re: Profiles/manifests-related command line interface enhancements

Hello, zimoun skribis: > On Sat, 16 Nov 2019 at 23:27, Ludovic Courtès wrote: > >> > Me too :-) It's "guix package" that is the worst offender in my >> > opinion. It does two distinct things: querying the package database and >> > managing profiles. And now that we have "guix search" for querie

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, I'll start from the end: > What do we disagree on, actually? :-) This: >> 2. Power users will always write code in powerful languages that exceed >>what less advanced users can deal with. And since power users are not >>necessarily benevolent, this creates a trust issue for th

Re: Profiles/manifests-related command line interface enhancements

Howdy! Konrad Hinsen skribis: >> I’d like to think that writing Guile declarations for the OS config, >> manifest, etc. is not just for “power users”. After all people, or >> rather “computer-savvy” people in a broad sense, write JSON, YAML, >> custom config files etc. routinely, and I don’t th

Re: Profiles/manifests-related command line interface enhancements

Hi Simon, > So, you propose to "enrich" the DSL describing the manifest files, right? Perhaps. I suppose there are several possible approaches, and I don't claim to know what works best before actually trying. One way is to "harden" manifest files, providing richer constructs for defining and tr

Re: Profiles/manifests-related command line interface enhancements

Hi, On Sun, 17 Nov 2019 at 12:30, Konrad Hinsen wrote: > If enough people are willing to work on this (beginners included!), we > could run a "CLI working group" that plays with alternatives to the > current CLI, implemented as a separate Guile package so it won't perturb > business as usual. Th

Re: Profiles/manifests-related command line interface enhancements

Hi Konrad, On Sun, 17 Nov 2019 at 11:45, Konrad Hinsen wrote: > For a long version of these arguments, see >https://hal.archives-ouvertes.fr/hal-01966145/document Thank you for the pointer. I missed it months ago. :-) So, you propose to "enrich" the DSL describing the manifest files, right

Re: Profiles/manifests-related command line interface enhancements

On Sat, 16 Nov 2019 at 23:27, Ludovic Courtès wrote: > > Me too :-) It's "guix package" that is the worst offender in my > > opinion. It does two distinct things: querying the package database and > > managing profiles. And now that we have "guix search" for queries, > > We also have ‘guix show’,

Re: Profiles/manifests-related command line interface enhancements

Ludovic Courtès writes: > To me it’s not entirely clear that a unified command would be easier to > use for newcomers. For example, I’m not fond of “guix profile” as a Indeed. It's also not clear to me if a single command line package for beginners and power users is the best way to go. Maybe w

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > I’d like to think that writing Guile declarations for the OS config, > manifest, etc. is not just for “power users”. After all people, or > rather “computer-savvy” people in a broad sense, write JSON, YAML, > custom config files etc. routinely, and I don’t think the typical config > we

Re: Profiles/manifests-related command line interface enhancements

Howdy! Konrad Hinsen skribis: >> I think having ephemeral + persistent and declarative + imperative is >> cool—I’d call that “flexible” rather than “messy”. :-) > > I agree. What's messy is how the concepts map to commands. How many Guix > users understand that profiles are persistent environme

Re: Profiles/manifests-related command line interface enhancements

Hi Konrad, Konrad Hinsen skribis: > YAML is for kids. Real managers won't settle for less than full XML. ;-) > > Seriously, as a power user, I am perfectly happy with Guile for > everything. I certainly don't want less. And for now, it's safe to > assume that most Guix users are power users. The

Re: Profiles/manifests-related command line interface enhancements

Hi Andy, Guix... On +2019-11-12 09:55:27 +0100, Andy Wingo wrote: > On Sun 10 Nov 2019 10:36, Konrad Hinsen writes: > > > One direction could be to add a sandboxing feature to Guile, which would > > be nice-to-have for other uses as well if Guile is to become a > > general-purpose systems script

Re: Profiles/manifests-related command line interface enhancements

Hi Andy, > I wrote this for that purpose: > > > https://www.gnu.org/software/guile/manual/html_node/Sandboxed-Evaluation.html Right, I had found this when searching for something. It seems to solve a couple of problems that I don't quite understand, but not so much those I do (file/network acc

Re: Profiles/manifests-related command line interface enhancements

On Sun 10 Nov 2019 10:36, Konrad Hinsen writes: > One direction could be to add a sandboxing feature to Guile, which would > be nice-to-have for other uses as well if Guile is to become a > general-purpose systems scripting language. There are some interesting > ideas in shill (http://shill.seas.

Re: Profiles/manifests-related command line interface enhancements

Hi, just want to say, that I like the concept, Konrad and Ludo are discussing. Please continue and make it into code. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > Of course, using a general-purpose language upfront also comes at a > price, as you note. But I think that what it has to offer to users > outweighs the costs, and that’s a lesson learned from Emacs. Just to > say I’m not willing to replace ‘config.scm’ with ‘config.yaml’, if > that’s

Re: Profiles/manifests-related command line interface enhancements

Hi Konrad, Konrad Hinsen skribis: > The bigger issue is config.scm - again unrestricted Guile code, like > manifests. That's not good for publishing because we shouldn't encourage > anyone to run unrestricted code from untrusted sources. It’s a conscious design choice to have configuration as c

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > I agree this is an important use case. It seems to me that the problem > here is being able to aggregate more than just packages. Yes, it's a bit more than that. We'd probably have to look at a couple of use cases to see what the most general content would be. > The Web application e

Re: Profiles/manifests-related command line interface enhancements

Hi Simon, >> I can of course share a manifest file by putting it in a public >> repository. But that isn't necessarily the best way. > > From my opinion, it is not the problem of Guix. Guix should not force > a practise, as good it should be. The way the users share manifests is > the problem of u

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, On Wed, 6 Nov 2019 at 17:42, Ludovic Courtès wrote: > >>> - A Scheme function to create a manifest for the necessary inputs of a > >>> package, like =guix environment PACKAGE= does. (Maybe it's already > >>> possible?) > >> > >> Like ‘specifications->manifest’? > > > > Can specifica

Re: Profiles/manifests-related command line interface enhancements

Konrad Hinsen writes: > This does open some interesting possibilities, such as experts defining > personalized system configurations which are then easy to install for > anyone. Although I am not terribly fond of the idea of typing URLs into > an installer. This should not be an issue once we ha

Re: Profiles/manifests-related command line interface enhancements

Pierre Neidhardt writes: > By the way, the same should be possible from the installer: > > - Specify which channels you want to use. > - Specify which config.scm you want to use. Indeed, the config.scm > might rely on channels. > > This way, the Guix installation process would boil down to the

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > I think having ephemeral + persistent and declarative + imperative is > cool—I’d call that “flexible” rather than “messy”. :-) I agree. What's messy is how the concepts map to commands. How many Guix users understand that profiles are persistent environments, or environments ephemeral

Re: Profiles/manifests-related command line interface enhancements

Hi all, On +2019-11-06 18:07:09 +0100, Ludovic Courtès wrote: > Hi Konrad, > > Konrad Hinsen skribis: > > > Take the typical example from Docker tutorials: bundling a Web server > > with some Web application and a database. It's easy to make a manifest > > file for collecting the required packa

Re: Profiles/manifests-related command line interface enhancements

Hi Konrad, Konrad Hinsen skribis: > Take the typical example from Docker tutorials: bundling a Web server > with some Web application and a database. It's easy to make a manifest > file for collecting the required packages. But it would make more sense > to me to have a module in a Guix channel

Re: Profiles/manifests-related command line interface enhancements

Pierre Neidhardt skribis: > Ludovic Courtès writes: > >> Another way is: >> >> eval `guix package --search-paths=prefix` >> >> or similar. > > Note that this suffers from the shell compatibility issue, e.g. it won't > work with Fish / Eshell. That can be fixed, as proposed in

Re: Profiles/manifests-related command line interface enhancements

Hey! Konrad Hinsen skribis: > Pierre Neidhardt writes: > >> I'm actually surprised you find it surprising! :) >> I can think of Simon, maybe Konrad(?) and myself who mentioned it >> before. > > Yes, me too. I could add to Pierre's list of use cases, but I prefer to > shift the discussion to a h

Re: Profiles/manifests-related command line interface enhancements

Hi Konrad, On Tue, 5 Nov 2019 at 17:05, Konrad Hinsen wrote: > > I am not sure to see which feature is missing. > > My main point is that the future evolution of functionality (and user > interfaces) in this space should take into account usage scenarii, > rather than adding features in an ad-ho

Re: Profiles/manifests-related command line interface enhancements

Hi Simon, > I am not sure to see which feature is missing. My main point is that the future evolution of functionality (and user interfaces) in this space should take into account usage scenarii, rather than adding features in an ad-hoc fashion. I can of course share a manifest file by putting i

Re: Profiles/manifests-related command line interface enhancements

Hi Konrad, On Tue, 5 Nov 2019 at 07:27, Konrad Hinsen wrote: > two dimensions I mentioned, this should include shareable/re-usable > vs. personal. People publish and share Docker images, so why wouldn't > they publish and share Guix super-packages? I am not sure to see which feature is missing.

Re: Profiles/manifests-related command line interface enhancements

Very good points! We are having very constructive discussions these days about `guix environment` and guix profiles ;) Exciting times ahead! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature

Re: Profiles/manifests-related command line interface enhancements

Am 05.11.19 um 10:03 schrieb Konrad Hinsen: >> And adding another dimension: spawning a sub-shell (environment) or not >> (profile). > How is this different from the ephemeral vs. persistent dimension? > Creating an ephemeral package set makes sense only if you spwan a > process in it (not necessar

Re: Profiles/manifests-related command line interface enhancements

Hi Hartmut, > This becomes even messier if we would implement a "guix develop" > command, which is yet just another version of environment/profile. Yes, I worry also about making more of a mess by implementing special-purpose variants. > And adding another dimension: spawning a sub-shell (enviro

Re: Profiles/manifests-related command line interface enhancements

Am 05.11.19 um 07:26 schrieb Konrad Hinsen: > In Guix we have ephemeral (environment) vs. persistent (profile), ad-hoc > (package -i, environment from package lists, ...) and declarative > (manifests). It's a bit of a mess. +1 This becomes even messier if we would implement a "guix develop" comma

Re: Profiles/manifests-related command line interface enhancements

Pierre Neidhardt writes: > I'm actually surprised you find it surprising! :) > I can think of Simon, maybe Konrad(?) and myself who mentioned it > before. Yes, me too. I could add to Pierre's list of use cases, but I prefer to shift the discussion to a higher level. What we have been discussing

Re: Profiles/manifests-related command line interface enhancements

Hi, On Mon, 4 Nov 2019 at 11:39, Pierre Neidhardt wrote: > >> - A Scheme function to create a manifest for the necessary inputs of a > >> package, like =guix environment PACKAGE= does. (Maybe it's already > >> possible?) > > > > Like ‘specifications->manifest’? > > Can specifications->manife

Re: Profiles/manifests-related command line interface enhancements

Ludovic Courtès writes: > Another way is: > > eval `guix package --search-paths=prefix` > > or similar. Note that this suffers from the shell compatibility issue, e.g. it won't work with Fish / Eshell. > Another one is: > > guix environment … This is a bit different since it spawns a subsh

Re: Profiles/manifests-related command line interface enhancements

Hi Pierre! Thanks for looking into this! (And sorry for being late to the party. :-)) Pierre Neidhardt skribis: > - Activate a profile with =guix activate /path/to/profile=. > Right now, the most appropriate way to activate a profile is > > GUIX_PROFILE="$profile" ; . "$profile"/etc/profile

Re: Profiles/manifests-related command line interface enhancements

Hi Pierre, Pierre Neidhardt writes: > Mark H Weaver writes: > >> It wouldn't be sufficient to remove them. You'd have to restore the >> previous settings. For example, if we remove the settings for PATH, >> MANPATH, etc, without restoring the previous settings, I doubt that you >> would be pl

Re: Profiles/manifests-related command line interface enhancements

Hi Pierre, Pierre Neidhardt writes: > Danny Milosavljevic writes: > >> On Thu, 24 Oct 2019 11:32:55 +0200 >> Pierre Neidhardt wrote: >> >>>- The inverse command, =guix deactivate /path/to/profile=. >>> This can be useful to deactivate a profile that was activated during login. >> >> That is no

Re: Profiles/manifests-related command line interface enhancements

Hi Pierre, On Thu, 24 Oct 2019 11:32:55 +0200 Pierre Neidhardt wrote: > As you suggested `guix-activate` could be a shell function that's > defined in /etc/profile or anywhere appropriate. Yes, but what's the advantage of that as opposed to just doing it like anyone else does it: Just start a n

Re: Profiles/manifests-related command line interface enhancements

Forgot to mention one of the stated goals of these enhancements (in particular profile activation): fix bug #37790 "MANPATH missing from non-default profile". https://issues.guix.gnu.org/issue/37790 -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature

Re: Profiles/manifests-related command line interface enhancements

Hi Mark, Good points! Mark H Weaver writes: > However, we could provide a Bash shell function (with a different name) > that provides conveniences like this. Users of other shells would not > be able to use the Bash shell function, though. Ideally, we'd provide > shell functions with a simila

Re: Profiles/manifests-related command line interface enhancements

Hi Pierre, Pierre Neidhardt writes: > While playing with multiple profiles and manifests and discussing with > a couple of people in the community, I collected a number of usability > issues with Guix when it comes to managing multiple profiles and dealing > with manifests. > > Ideas for new fea