Transformations Shell Syntax

Transformations Shell Syntax

[jgart]

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.

Re: Transformations Shell Syntax

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

On Tue, May 23, 2023 at 06:43:30AM +0000, 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   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Transformations Shell Syntax

[Simon Tournier]

Hi jgart,

On Tue, 23 May 2023 at 06:43, "jgart" <jgart@dismail.de> 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

[jgart]

> 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

[Andreas Enge]

Hello,

Am Tue, May 23, 2023 at 01:24:00PM +0000 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

[jgart]

> 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

[Simon Tournier]

Hi jgart,

On Tue, 23 May 2023 at 16:12, jgart <jgart@dismail.de> 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

[Andreas Enge]

Am Tue, May 23, 2023 at 02:12:02PM +0000 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

[jgart]

> 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

[Ryan Prior]

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 <jgart@dismail.de> 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

[Ludovic Courtès]

Hello!

"jgart" <jgart@dismail.de> 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

[John Kehayias]

[-- Attachment #1: Type: text/plain, Size: 2467 bytes --]

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 <package> --with-latest

or guix shell <package> -<a letter which is available>

which is short for

guix shell <package> --with-latest=<package>

or even

guix shell <package1> <package2> <package3> --with-latest

to apply to all packages.

Or something like

guix shell <package1> <package2> --with-git-url=<a git url for package3> <package3>

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’.

[-- Attachment #2: Type: text/html, Size: 2764 bytes --]

Re: Transformations Shell Syntax

[Ludovic Courtès]

HI,

John Kehayias <john.kehayias@protonmail.com> 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 <package> --with-latest
>
> or guix shell <package> -<a letter which is available>
>
> which is short for
>
> guix shell <package> --with-latest=<package>
>
> or even
>
> guix shell <package1> <package2> <package3> --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 <package1> <package2> --with-git-url=<a git url for package3> <package3>
>
> 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

[jgart]

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

[John Kehayias]

Hello,

On Sun, Jul 02, 2023 at 09:54 PM, Ludovic Courtès wrote:

> HI,
>
> John Kehayias <john.kehayias@protonmail.com> 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 <package> --with-latest
>>
>> or guix shell <package> -<a letter which is available>
>>
>> which is short for
>>
>> guix shell <package> --with-latest=<package>
>>
>> or even
>>
>> guix shell <package1> <package2> <package3> --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 <package1> <package2> --with-git-url=<a git url for package3> <package3>
>>
>> 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

[Ludovic Courtès]

Hi,

"jgart" <jgart@dismail.de> 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

[Hartmut Goebel]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

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.goebel@crazy-compilers.com                |
|www.crazy-compilers.com  | compilers which you thought are impossible |

[-- Attachment #2: Type: text/html, Size: 1508 bytes --]

Re: Transformations Shell Syntax

[Ludovic Courtès]

Hi,

Hartmut Goebel <h.goebel@crazy-compilers.com> 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’.