Re: Transformations Shell Syntax
Hi,
Hartmut Goebel skribis:
> Am 03.07.23 um 02:01 schrieb jgart:
>> Starting multiple workers:
>>
>> $ herd start microblog-tasks@{1..4}
>> $ herd status microblog-tasks@{1..4}
>
> Please note that this syntax is expanted by the shell! Thus these
> commands are the same as
>
> $ herd start microblog-tasks@1 microblog-tasks@2 microblog-tasks@3
> microblog-tasks@4
> $ herd status microblog-tasks@1 microblog-tasks@2 microblog-tasks@3
> microblog-tasks@4
Ah yes, sorry for not noticing!
The problem with this syntax is that currently ‘start’ procedures can
take an arbitrary number of arguments:
herd start foo x y z
means that the ‘start’ procedure of foo is passed x, y, and z as
arguments. It’s occasionally useful and we do have a few System/Home
services that use it (‘home-pulseaudio-rtp-sink-service-type’,
‘guix-service-type’, ‘documentation-service-type’ in the installer).
So I think we can’t just remove support for that syntax.
Not sure how to improve on that.
Ludo’.
Re: Transformations Shell Syntax
Am 03.07.23 um 02:01 schrieb jgart:
Starting multiple workers:
$ herd start microblog-tasks@{1..4}
$ herd status microblog-tasks@{1..4}
Please note that this syntax is expanted by the shell! Thus these
commands are the same as
$ herd start microblog-tasks@1 microblog-tasks@2 microblog-tasks@3
microblog-tasks@4
$ herd status microblog-tasks@1 microblog-tasks@2 microblog-tasks@3
microblog-tasks@4
--
Regards
Hartmut Goebel
| Hartmut Goebel |h.goe...@crazy-compilers.com|
|www.crazy-compilers.com | compilers which you thought are impossible |
Re: Transformations Shell Syntax
Hi,
"jgart" skribis:
> In other words being able to specify workers with shepherd:
>
> Starting multiple workers:
>
> $ herd start microblog-tasks@{1..4}
> $ herd status microblog-tasks@{1..4}
>
> Restarting a particular worker:
>
> $ herd restart microblog-tasks@3
>
> WDYT
I’ve never felt the need for this, and I’m typically not a “syntax
person” so to speak ;-), but *if* there is an actual need for this, then
we can thing about it.
(We might want to be more general though, like essentially allowing
users to apply an action such as ‘start’ to a set of services regardless
of their naming scheme.)
Ludo’.
Re: Transformations Shell Syntax
Hello, On Sun, Jul 02, 2023 at 09:54 PM, Ludovic Courtès wrote: > HI, > > John Kehayias skribis: > >> As one who also would like a shorter syntax option, here's a quick >> thought: what about a short version of what we have for when there >> is only one package given or it can be applied to all packages/be a >> positional argument? An example is perhaps best, so what if we could >> write: >> >> guix shell --with-latest >> >> or guix shell - >> >> which is short for >> >> guix shell --with-latest= >> >> or even >> >> guix shell--with-latest >> >> to apply to all packages. > > This should be possible. We should check the option parsers and > transformation procedures in (guix transformations). > Sounds good, seems like a nice little project for someone. I'll pass for the time being as I catch up on my patches and trying to review more. (And I want to add some basic multi-arch support to the FHS container, too.) >> Or something like >> >> guix shell --with-git-url= >> >> >> and so on. > > This I’m unsure; one might argue that it’s also ambiguous, I’d always > wonder what ‘--with-git-url’ applies to. > I generally agree; I'm not a fan of too much positional-ness in arguments as it can get confusing. Though we do have --development for guix shell already, of course.
Re: Transformations Shell Syntax
Hi Ludo,
Is there any interest in having a syntax for shepherd for controlling multiple
workers?
>>>
Excerpt from
https://blog.miguelgrinberg.com/post/running-a-flask-application-as-a-service-with-systemd
Now I can start four workers using brace expansion in bash:
$ sudo systemctl daemon-reload
$ sudo systemctl start microblog-tasks@{1..4}
$ sudo systemctl status microblog-tasks@{1..4}
And if you want to address an individual instance you can do that as well:
$ sudo systemctl restart microblog-tasks@3
>
In other words being able to specify workers with shepherd:
Starting multiple workers:
$ herd start microblog-tasks@{1..4}
$ herd status microblog-tasks@{1..4}
Restarting a particular worker:
$ herd restart microblog-tasks@3
WDYT
Re: Transformations Shell Syntax
HI, John Kehayias skribis: > As one who also would like a shorter syntax option, here's a quick thought: > what about a short version of what we have for when there is only one package > given or it can be applied to all packages/be a positional argument? An > example is perhaps best, so what if we could write: > > guix shell --with-latest > > or guix shell - > > which is short for > > guix shell --with-latest= > > or even > > guix shell--with-latest > > to apply to all packages. This should be possible. We should check the option parsers and transformation procedures in (guix transformations). > Or something like > > guix shell --with-git-url= > > > and so on. This I’m unsure; one might argue that it’s also ambiguous, I’d always wonder what ‘--with-git-url’ applies to. Thanks, Ludo’.
Re: Transformations Shell Syntax
Hello, As one who also would like a shorter syntax option, here's a quick thought: what about a short version of what we have for when there is only one package given or it can be applied to all packages/be a positional argument? An example is perhaps best, so what if we could write: guix shell --with-latest or guix shell - which is short for guix shell --with-latest= or even guix shell--with-latest to apply to all packages. Or something like guix shell --with-git-url= and so on. A positional argument requires a bit more work and signaling/knowledge for the user, but maybe just the short hand --with-latest or -x (or whatever letter) which errors when more than one package is given is a step in this direction. Not sure if these two related suggestions can be combined or not without making things too complex. Anyway, it would be nice to have a short version for, at least for me, the common situation of trying to build a single package with a transformation(s) for just that one. For instance, that's usually how I check if there's trivial version bump or if building from some fork works without modification of the package definition beyond the source. (apologies for the top post and formatting, currently away from a proper computer) John Original Message On May 26, 2023, 10:50 PM, Ludovic Courtès wrote: > Hello! "jgart" skribis: > Uses specified commit hash: > > guix build > emacs-ement@8b56efa9387262514daf63151d41c9e111e79567 > > Uses specified > commit hash (short): > > guix build emacs-ement@8b56efa > > Uses latest > upstream release: > > guix build emacs-ement@latest > > Uses upstream version > 0.8.2 if not packaged: > > guix build emacs-ement@0.8.2 > > Uses the latest > commit in the wip/find-room branch: > > guix build emacs-ement@wip/find-room > I sympathize with the will to get a more compact way to express > transformations. Right now, command-line tools parse package specs by calling > ‘specification->package+output’. There are no restrictions on version fields: > “8b56efa9387262514daf63151d41c9e111e79567” and “latest” are perfectly valid > version fields. Thus, if the syntax above was implemented, we’d introduce > ambiguity. Consequently, rather than overload “@”, I believe another syntax > would need to be found. Thanks, Ludo’.
Re: Transformations Shell Syntax
Hello! "jgart" skribis: > Uses specified commit hash: > > guix build emacs-ement@8b56efa9387262514daf63151d41c9e111e79567 > > Uses specified commit hash (short): > > guix build emacs-ement@8b56efa > > Uses latest upstream release: > > guix build emacs-ement@latest > > Uses upstream version 0.8.2 if not packaged: > > guix build emacs-ement@0.8.2 > > Uses the latest commit in the wip/find-room branch: > > guix build emacs-ement@wip/find-room I sympathize with the will to get a more compact way to express transformations. Right now, command-line tools parse package specs by calling ‘specification->package+output’. There are no restrictions on version fields: “8b56efa9387262514daf63151d41c9e111e79567” and “latest” are perfectly valid version fields. Thus, if the syntax above was implemented, we’d introduce ambiguity. Consequently, rather than overload “@”, I believe another syntax would need to be found. Thanks, Ludo’.
Re: Transformations Shell Syntax
I don't like the unpredictability of jgart's original proposal, but maybe something explicit could still look similar. Suppose you could build emacs-ement these three ways: # no transform- this is a version packaged in Guix guix build emacs-ement@0.5.2 # transform using `with-git-commit` guix build emacs-ement@git-commit:8b56efa9387262514daf63151d41c9e111e79567 # transform using `with-latest` guix build emacs-ement@latest # transform using `with-version` guix build emacs-ement@version:0.8.2 A short syntax for transforms would contribute to readability and ergonomic ease. Worth looking into. Ryan --- Original Message --- On Tuesday, May 23rd, 2023 at 5:20 PM, jgart wrote: > > > > What disturbs me with your suggestion is that it reuses the same syntax > > > that is already used for a different purpose. So in a sense you do > > "operator overloading", and the same command line then means different > > things depending on whether the package version is already provided by > > Guix or not. > > > Yes, I see how that can be an CLI smell and "not Guixonic". > > Would be sweet to have something like it but I realize the negative of > dirtying the current API's explicitness to get lower verbosity invocations at > the shell prompt.
Re: Transformations Shell Syntax
> What disturbs me with your suggestion is that it reuses the same syntax > that is already used for a different purpose. So in a sense you do > "operator overloading", and the same command line then means different > things depending on whether the package version is already provided by > Guix or not. Yes, I see how that can be an CLI smell and "not Guixonic". Would be sweet to have something like it but I realize the negative of dirtying the current API's explicitness to get lower verbosity invocations at the shell prompt.
Re: Transformations Shell Syntax
Am Tue, May 23, 2023 at 02:12:02PM + schrieb jgart: > > I think your semantics ends up meaning "try to make sense of the version > > field, and give me the package at this version". > Aren't these the current semantics of guix package transformations though? > I'm just proposing shell syntax for them. Yes, indeed. So there already is shell syntax, it is just a bit unweildy and verbose. What disturbs me with your suggestion is that it reuses the same syntax that is already used for a different purpose. So in a sense you do "operator overloading", and the same command line then means different things depending on whether the package version is already provided by Guix or not. Like Simon writes, let us be explicit. Andreas
Re: Transformations Shell Syntax
Hi jgart, On Tue, 23 May 2023 at 16:12, jgart wrote: > Aren't these the current semantics of guix package transformations though? > I'm just proposing shell syntax for them. The main difference is explicit vs implicit. The current syntax is explicit. The one you are proposing is implicit. As The Zen of Python (python -c 'import this') says: Explicit is better than implicit. ;-) Cheers, simon
Re: Transformations Shell Syntax
> I am a bit wary of too much intelligence in interpreting commands, at the > expense of clarity Hi Andreas, I agree with this design aesthetic. Personally, I like my software not too dumb and not too smart with a slight bias towards the smart. > I think your semantics ends up meaning "try to make sense of the version > field, and give me the package at this version". Aren't these the current semantics of guix package transformations though? I'm just proposing shell syntax for them. Anyways, just an idea. I'm brainstorming out loud ;() I realize that it might be bloat. I'm fine with also not having them as per the design aesthetics mentioned above.
Re: Transformations Shell Syntax
Hello, Am Tue, May 23, 2023 at 01:24:00PM + schrieb jgart: > I was openly ideating on having shell syntax like we do currently for > emacs-ement@0.9.3, for example, but for a subset of package transformation > options as well. I am a bit wary of too much intelligence in interpreting commands, at the expense of clarity (also for the user - what do they really do?) Right now, "guix build emacs-ement@0.9.3" means "build the package emacs-ement at version 0.9.3, which is available somewhere in my channels". I think your semantics ends up meaning "try to make sense of the version field, and give me the package at this version". This is actually quite different - for instance, it means the package is not vetted by Guix developers. So there may even be security implications. In my opinion we should strive for simplicity in commands, it should always be clear what a specific command line does and not depend on context, and the guix tool should not second guess what we want to do when invoking a given command. Andreas
Re: Transformations Shell Syntax
> WDYT about what? Could you be more specific and detail your idea? Hi Simon, I was openly ideating on having shell syntax like we do currently for emacs-ement@0.9.3, for example, but for a subset of package transformation options as well. Does that clarify my intent? If not, let me know to expound further. all best, jgart
Re: Transformations Shell Syntax
Hi jgart, On Tue, 23 May 2023 at 06:43, "jgart" wrote: > Hi Guixers WDYT, WDYT about what? Could you be more specific and detail your idea? > Uses specified commit hash: > > guix build emacs-ement@8b56efa9387262514daf63151d41c9e111e79567 > > Uses specified commit hash (short): > > guix build emacs-ement@8b56efa > > Uses latest upstream release: > > guix build emacs-ement@latest > > Uses the latest commit in the wip/find-room branch: > > guix build emacs-ement@wip/find-room If you are suggesting between the lines to copy the already packaged ’emacs-ement’ Guix recipe to some temporary location, then tweak the version field and build it. Well, it appears to me already implemented with the transformations “--with-version” or “--with-branch” or “--with-commit” or “--with-latest”. > Uses upstream version 0.8.2 if not packaged: > > guix build emacs-ement@0.8.2 If you are suggesting between the lines to transparently run “guix import” and then build the result, well, it will depend on the quality of the importer. And I think the effort is not worth – it appears to me better to keep the both separated. Cheers, simon
Re: Transformations Shell Syntax
On Tue, May 23, 2023 at 06:43:30AM +, jgart wrote: > Hi Guixers WDYT, > > Uses specified commit hash: > > guix build emacs-ement@8b56efa9387262514daf63151d41c9e111e79567 for a comparison, the current (long) version: guix build emacs-ement --with-commit=emacs-ement=8b56efa9387262514daf63151d41c9e111e79567 Obviously the difference is that --with-commit can apply to dependencies, and this looks to only work on the actual package, but I often find myself only adjusting the actual package I'm trying to build anyway. > Uses specified commit hash (short): > > guix build emacs-ement@8b56efa > > Uses latest upstream release: > > guix build emacs-ement@latest > > Uses upstream version 0.8.2 if not packaged: > > guix build emacs-ement@0.8.2 > > Uses the latest commit in the wip/find-room branch: > > guix build emacs-ement@wip/find-room I'm not sure how @latest would work with @wip/find-room, unless @latest was reserved to point to (maybe) the newest release. I think we've all seen that the updater sometimes gets confused by some of the upstream methods of tagging releases and trying to figure out what the lastest release actually is. -- 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
Transformations Shell Syntax
Hi Guixers WDYT, Uses specified commit hash: guix build emacs-ement@8b56efa9387262514daf63151d41c9e111e79567 Uses specified commit hash (short): guix build emacs-ement@8b56efa Uses latest upstream release: guix build emacs-ement@latest Uses upstream version 0.8.2 if not packaged: guix build emacs-ement@0.8.2 Uses the latest commit in the wip/find-room branch: guix build emacs-ement@wip/find-room etc.
