[bug#46215] Add yadm

---
 gnu/packages/package-management.scm | 32 +++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

Hello Ellis,

Am Sonntag, den 31.01.2021, 16:47 +0000 schrieb Ellis Kenyo:
> ---
>  gnu/packages/package-management.scm | 32
> +++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
Your commit is missing a ChangeLog in its message.

> [...]
> +    (build-system gnu-build-system)
> +    (arguments
> +     '(#:tests? #f
Document why (i.e. "no check target").

> +       #:make-flags (list (string-append "PREFIX=" (assoc-ref
> %outputs "out")))
> +       #:phases
> +       (modify-phases %standard-phases
> +         (delete 'bootstrap)
> +         (delete 'configure)
> +         (delete 'build))))
yadm has a few things you need to patch.  For one, its shebang is
/bin/sh despite requiring bash.  Also it contains a large number of
_PROGRAM variables, which would be need to be replaced by their actual
store path (use the which procedure for that).

> +    (description "When you live in a command line, configurations
> are a deeply
> +personal thing. They are often crafted over years of experience,
> battles lost,
> +lessons learned, advice followed, and ingenuity rewarded. When you
> are away
> +from your own configurations, you are an orphaned refugee in
> unfamiliar and
> +hostile surroundings. You feel clumsy and out of sorts. You are
> filled with a
> +sense of longing to be back in a place you know. A place you built.
> A place
> +where all the short-cuts have been worn bare by your own travels. A
> place you
> +proudly call… $HOME.")
Nice advertisement, but not really a description.  yadm.1 has a better
one, but keep to the formatting in Guix (particularly double spaces
after sentence end).

> +    (license license:gpl3)))
Should be gpl3+.

Regards,
Leo

Hi Leo,

Thanks for the feedback.

> Your commit is missing a ChangeLog in its message.
This will be added with the next patch.

> Document why (i.e. "no check target").
I have also added similar comments for the other removed stages.

> yadm has a few things you need to patch.  For one, its shebang 
> is
> /bin/sh despite requiring bash.  Also it contains a large number 
> of
> _PROGRAM variables, which would be need to be replaced by their 
> actual
> store path (use the which procedure for that).

Patch them to be the $(which <exe>) expression or evaluate that?
If the latter, I'm not sure how that would handle installing deps
retroactively.

> Nice advertisement, but not really a description.  yadm.1 has a 
> better
> one, but keep to the formatting in Guix (particularly double 
> spaces
> after sentence end).
I was looking for an accurate description on the site, I have 
replaced
with that and the linter passes.

> Should be gpl3+.
This will also be added to the next patch.

Leo Prikler <leo.prikler@student.tugraz.at> writes:

> Hello Ellis,
>
> Am Sonntag, den 31.01.2021, 16:47 +0000 schrieb Ellis Kenyo:
>> ---
>>  gnu/packages/package-management.scm | 32
>> +++++++++++++++++++++++++++++
>>  1 file changed, 32 insertions(+)
> Your commit is missing a ChangeLog in its message.
>
>> [...]
>> +    (build-system gnu-build-system)
>> +    (arguments
>> +     '(#:tests? #f
> Document why (i.e. "no check target").
>
>> +       #:make-flags (list (string-append "PREFIX=" (assoc-ref
>> %outputs "out")))
>> +       #:phases
>> +       (modify-phases %standard-phases
>> +         (delete 'bootstrap)
>> +         (delete 'configure)
>> +         (delete 'build))))
> yadm has a few things you need to patch.  For one, its shebang 
> is
> /bin/sh despite requiring bash.  Also it contains a large number 
> of
> _PROGRAM variables, which would be need to be replaced by their 
> actual
> store path (use the which procedure for that).
>
>> +    (description "When you live in a command line, 
>> configurations
>> are a deeply
>> +personal thing. They are often crafted over years of 
>> experience,
>> battles lost,
>> +lessons learned, advice followed, and ingenuity rewarded. When 
>> you
>> are away
>> +from your own configurations, you are an orphaned refugee in
>> unfamiliar and
>> +hostile surroundings. You feel clumsy and out of sorts. You 
>> are
>> filled with a
>> +sense of longing to be back in a place you know. A place you 
>> built.
>> A place
>> +where all the short-cuts have been worn bare by your own 
>> travels. A
>> place you
>> +proudly call… $HOME.")
> Nice advertisement, but not really a description.  yadm.1 has a 
> better
> one, but keep to the formatting in Guix (particularly double 
> spaces
> after sentence end).
>
>> +    (license license:gpl3)))
> Should be gpl3+.
>
> Regards,
> Leo

Hi Ellen,

Am Sonntag, den 31.01.2021, 20:16 +0000 schrieb Ellis Kenyő:
> Hi Leo,
> 
> Thanks for the feedback.
> 
> > Your commit is missing a ChangeLog in its message.
> This will be added with the next patch.
> 
> > Document why (i.e. "no check target").
> I have also added similar comments for the other removed stages.
That's not as important, gnu-build-system is often used as base for
packages and build system, that don't actually have configure.  For
disabled tests, however, it is not clear without comment whether they
fail or whether they simply don't exist.

> > yadm has a few things you need to patch.  For one, its shebang 
> > is
> > /bin/sh despite requiring bash.  Also it contains a large number 
> > of
> > _PROGRAM variables, which would be need to be replaced by their 
> > actual
> > store path (use the which procedure for that).
> 
> Patch them to be the $(which <exe>) expression or evaluate that?
> If the latter, I'm not sure how that would handle installing deps
> retroactively.
You'd add the packages, that define those programs as inputs, then
you do something along the lines of

  (substitute* "yadm" 
    (("(.*)_PROGRAM=\"(.*)\"" all var prog)
     (format #f "~a_PROGRAM=~s" var (which prog))))

inside some phase after unpack.
Please apologize if the snippet above doesn't actually work for your
case, I haven't tried it.

By the way, git format-patch seems to swallow the Umlaut (or however
it's called in your language) in your surname.  If you want it to be
that way, then fair enough, just know that there's no policy
prohibiting UTF-8 in committer names.

Regards,
Leo

Hi Leo,

I understand what to do, I just wasn't sure how dependencies installed later would be handled. Some are optional and if they don't exist yadm just carries on, but some are required.

Would the optional ones still be handled? 

On 31 Jan 2021, 20:36, at 20:36, Leo Prikler <leo.prikler@student.tugraz.at> wrote:
>Hi Ellen,
>
>Am Sonntag, den 31.01.2021, 20:16 +0000 schrieb Ellis Kenyő:
>> Hi Leo,
>> 
>> Thanks for the feedback.
>> 
>> > Your commit is missing a ChangeLog in its message.
>> This will be added with the next patch.
>> 
>> > Document why (i.e. "no check target").
>> I have also added similar comments for the other removed stages.
>That's not as important, gnu-build-system is often used as base for
>packages and build system, that don't actually have configure.  For
>disabled tests, however, it is not clear without comment whether they
>fail or whether they simply don't exist.
>
>> > yadm has a few things you need to patch.  For one, its shebang 
>> > is
>> > /bin/sh despite requiring bash.  Also it contains a large number 
>> > of
>> > _PROGRAM variables, which would be need to be replaced by their 
>> > actual
>> > store path (use the which procedure for that).
>> 
>> Patch them to be the $(which <exe>) expression or evaluate that?
>> If the latter, I'm not sure how that would handle installing deps
>> retroactively.
>You'd add the packages, that define those programs as inputs, then
>you do something along the lines of
>
>  (substitute* "yadm" 
>    (("(.*)_PROGRAM=\"(.*)\"" all var prog)
>     (format #f "~a_PROGRAM=~s" var (which prog))))
>
>inside some phase after unpack.
>Please apologize if the snippet above doesn't actually work for your
>case, I haven't tried it.
>
>By the way, git format-patch seems to swallow the Umlaut (or however
>it's called in your language) in your surname.  If you want it to be
>that way, then fair enough, just know that there's no policy
>prohibiting UTF-8 in committer names.
>
>Regards,
>Leo

Am Montag, den 01.02.2021, 03:44 +0000 schrieb Ellis Kenyő:
> Hi Leo,
> 
> I understand what to do, I just wasn't sure how dependencies
> installed later would be handled. Some are optional and if they don't
> exist yadm just carries on, but some are required.
> 
> Would the optional ones still be handled?
Guix' policy is to include as many optional dependencies as possible,
up to a reasonable limit in closure size.  In this case, that's
hopefully all of them.

Regards,
Leo

I understand that, the question was how are they handled if they're installed after yadm? Would yadm be rebuilt with the new inputs? 

On 1 Feb 2021, 08:14, at 08:14, Leo Prikler <leo.prikler@student.tugraz.at> wrote:
>Am Montag, den 01.02.2021, 03:44 +0000 schrieb Ellis Kenyő:
>> Hi Leo,
>> 
>> I understand what to do, I just wasn't sure how dependencies
>> installed later would be handled. Some are optional and if they don't
>> exist yadm just carries on, but some are required.
>> 
>> Would the optional ones still be handled?
>Guix' policy is to include as many optional dependencies as possible,
>up to a reasonable limit in closure size.  In this case, that's
>hopefully all of them.
>
>Regards,
>Leo

Am Montag, den 01.02.2021, 10:06 +0000 schrieb Ellis Kenyő:
> I understand that, the question was how are they handled if they're
> installed after yadm? Would yadm be rebuilt with the new inputs?
I think you are fundamentally misunderstanding the nature of functional
package management here.  yadm should – like any other package – depend
on its inputs and just its inputs.  Whether or not you have another
package installed should not be relevant for the functioning of yadm
and likewise not cause a rebuild.  What should cause a rebuild is any
of its inputs changing between two generations of `guix pull'.

Regards,
Leo

I don't think you're understanding my question.

A number of the dependencies are optional, for example some of the 
jinja template commands.

When this builds, if those packages aren't installed before you 
install yadm, the path gets set to `#f`.

If you then later install them (one of them for example is a 
python module so likely wouldn't be installed through guix), the 
path in yadm is still `#f` so it would never find them.

Do I have to also package everything it has a soft dependency on?

Leo Prikler <leo.prikler@student.tugraz.at> writes:

> Am Montag, den 01.02.2021, 10:06 +0000 schrieb Ellis Kenyő:
>> I understand that, the question was how are they handled if 
>> they're
>> installed after yadm? Would yadm be rebuilt with the new 
>> inputs?
> I think you are fundamentally misunderstanding the nature of 
> functional
> package management here.  yadm should – like any other package – 
> depend
> on its inputs and just its inputs.  Whether or not you have 
> another
> package installed should not be relevant for the functioning of 
> yadm
> and likewise not cause a rebuild.  What should cause a rebuild 
> is any
> of its inputs changing between two generations of `guix pull'.
>
> Regards,
> Leo

Hi Ellis,

Am Samstag, den 06.02.2021, 10:05 +0000 schrieb Ellis Kenyő:
> I don't think you're understanding my question.
> 
> A number of the dependencies are optional, for example some of the 
> jinja template commands.
And Guix' policy is – as I've already pointed out – to provide such
optional dependencies as inputs up to a reasonable limit in closure
size.

> When this builds, if those packages aren't installed before you 
> install yadm, the path gets set to `#f`.
That's not how building works.  If jinja is *present in the build
environment*, it is available for substitution.  This has nothing to do
with packages the user may or may not have installed at that point.
If not, then yeah, you end up with #f.  It makes no sense to set up
substitutions for commands, that aren't present in the build
environment.

> If you then later install them (one of them for example is a 
> python module so likely wouldn't be installed through guix), the 
> path in yadm is still `#f` so it would never find them.
You can and should install python packages through Guix.  We here at
Guix Solutions™ do not approve of the need for programming language
specific package managers, especially not multiple ones within the same
project.

> Do I have to also package everything it has a soft dependency on?
As long as it can reasonably be expected, that users will want it, yes.
If the soft dependency is indeed completely optional, the software
works perfectly fine without it and few people will be negatively
impacted by a minor feature missing, then it's fine to leave it as-is,
provided that the missing dependency is itself free software.  If there
is an optional dependency on non-free software, mentions of that
software should be removed.

Regards,
Leo

> As long as it can reasonably be expected, that users will want it, yes.
If the soft dependency is indeed completely optional, the software
works perfectly fine without it and few people will be negatively
impacted by a minor feature missing, then it's fine to leave it as-is

This is the only point I'm making. Things like templates and encryption aren't used by everyone so could definitely be optional, so I was asking if there was a simple way to handle optional inputs. As it doesn't seem like there is I'll just add everything required. 

On 6 Feb 2021, 10:48, at 10:48, Leo Prikler <leo.prikler@student.tugraz.at> wrote:
>Hi Ellis,
>
>Am Samstag, den 06.02.2021, 10:05 +0000 schrieb Ellis Kenyő:
>> I don't think you're understanding my question.
>> 
>> A number of the dependencies are optional, for example some of the 
>> jinja template commands.
>And Guix' policy is – as I've already pointed out – to provide such
>optional dependencies as inputs up to a reasonable limit in closure
>size.
>
>> When this builds, if those packages aren't installed before you 
>> install yadm, the path gets set to `#f`.
>That's not how building works.  If jinja is *present in the build
>environment*, it is available for substitution.  This has nothing to do
>with packages the user may or may not have installed at that point.
>If not, then yeah, you end up with #f.  It makes no sense to set up
>substitutions for commands, that aren't present in the build
>environment.
>
>> If you then later install them (one of them for example is a 
>> python module so likely wouldn't be installed through guix), the 
>> path in yadm is still `#f` so it would never find them.
>You can and should install python packages through Guix.  We here at
>Guix Solutions™ do not approve of the need for programming language
>specific package managers, especially not multiple ones within the same
>project.
>
>> Do I have to also package everything it has a soft dependency on?
>As long as it can reasonably be expected, that users will want it, yes.
>If the soft dependency is indeed completely optional, the software
>works perfectly fine without it and few people will be negatively
>impacted by a minor feature missing, then it's fine to leave it as-is,
>provided that the missing dependency is itself free software.  If there
>is an optional dependency on non-free software, mentions of that
>software should be removed.
>
>Regards,
>Leo

Am Samstag, den 06.02.2021, 10:58 +0000 schrieb Ellis Kenyő:
> > As long as it can reasonably be expected, that users will want it, 
> > yes.
> > If the soft dependency is indeed completely optional, the software
> > works perfectly fine without it and few people will be negatively
> > impacted by a minor feature missing, then it's fine to leave it
> > as-is
> 
> This is the only point I'm making. Things like templates and
> encryption aren't used by everyone so could definitely be optional,
> so I was asking if there was a simple way to handle optional inputs.
> As it doesn't seem like there is I'll just add everything required.
I'd like to say "use your best judgement", but you seem to be a little
too fixated on having a minimal package description (and putting
minimal effort into it).  For instance, when the package advertises
encryption, while it is technically optional, shipping it without gpg
would be a grave oversight!  (On the other hand, you need not
necessarily have openssl, since encryption requires any of gpg or
openssl, not both.)  Same for templates, at least awk is required and
either j2cli or envtpl would be nice to have.

Regards,
Leo

I'm not at all fixated on a minimal package and I resent the idea of putting minimal effort in.

I was purely asking a simple question, there's no need to resort to rudeness. 

On 6 Feb 2021, 11:22, at 11:22, Leo Prikler <leo.prikler@student.tugraz.at> wrote:
>Am Samstag, den 06.02.2021, 10:58 +0000 schrieb Ellis Kenyő:
>> > As long as it can reasonably be expected, that users will want it, 
>> > yes.
>> > If the soft dependency is indeed completely optional, the software
>> > works perfectly fine without it and few people will be negatively
>> > impacted by a minor feature missing, then it's fine to leave it
>> > as-is
>> 
>> This is the only point I'm making. Things like templates and
>> encryption aren't used by everyone so could definitely be optional,
>> so I was asking if there was a simple way to handle optional inputs.
>> As it doesn't seem like there is I'll just add everything required.
>I'd like to say "use your best judgement", but you seem to be a little
>too fixated on having a minimal package description (and putting
>minimal effort into it).  For instance, when the package advertises
>encryption, while it is technically optional, shipping it without gpg
>would be a grave oversight!  (On the other hand, you need not
>necessarily have openssl, since encryption requires any of gpg or
>openssl, not both.)  Same for templates, at least awk is required and
>either j2cli or envtpl would be nice to have.
>
>Regards,
>Leo

Ellis,

Ellis Kenyő via Guix-patches via 写道：
> I was asking if there was a simple way to handle optional 
> inputs.

While this is an oxymoron for the reasons pointed out by Leo, 
there is _nothing_ wrong with simply leaving some variables at 
their default e.g.

  GPG_PROGRAM="gpg"

and letting yadm look them up at run time in its $PATH.

Does that not work?

For things like templates {native-,}search-paths can be a 
solution, depending on how yadm (or its templating library) 
searches for these.

Kind regards,

T G-R

Hi Tobias,

Yes I am aware that it's more complicated than the initial question, I'm fine with adding all the dependencies as inputs.

I was simply asking the correct way to handle optional inputs.

> Does that not work?

Yes it would absolutely work, I have tested as such in depth on multiple guix systems.

> For things like templates {native-,}search-paths can be a 
solution, depending on how yadm (or its templating library) 
searches for these.

Yes I still have further testing with regards to templates as I don't personally use them.

Thanks you for your input Tobias 

On 6 Feb 2021, 11:37, at 11:37, Tobias Geerinckx-Rice <me@tobias.gr> wrote:
>Ellis,
>
>Ellis Kenyő via Guix-patches via 写道：
>> I was asking if there was a simple way to handle optional 
>> inputs.
>
>While this is an oxymoron for the reasons pointed out by Leo, 
>there is _nothing_ wrong with simply leaving some variables at 
>their default e.g.
>
>  GPG_PROGRAM="gpg"
>
>and letting yadm look them up at run time in its $PATH.
>
>Does that not work?
>
>For things like templates {native-,}search-paths can be a 
>solution, depending on how yadm (or its templating library) 
>searches for these.
>
>Kind regards,
>
>T G-R

Leo, Ellis,

Leo Prikler 写道：
> I'd like to say "use your best judgement", but you seem to be a 
> little
> too fixated on having a minimal package description (and putting
> minimal effort into it).

That's uncalled for.  It's certainly not the impression I get.

> For instance, when the package advertises encryption, while it 
> is
> technically optional, shipping it without gpg would be a grave 
> oversight!

Well, that depends.  My own rule of thumb for ‘foo supports 
encryption!’ is:

  $ gpg
  bash: gpg: command not found
  $ foo --encrypt
  error: whoopsie: BUG in do_foo()+0x4f44!
  <16 lines of barftrace>
  error: warning: error: No such file or directory. (-ERROR)
  $

=> Make gpg an input, and quick.

  $ gpg
  bash: gpg: command not found
  $ foo --encrypt
  error: gpg not found, please install it.
  $

=> This is totally fine, users who want it know what to do next.

Kind regards,

T G-R

Am Samstag, den 06.02.2021, 12:30 +0100 schrieb Tobias Geerinckx-Rice:
> For things like templates {native-,}search-paths can be a 
> solution, depending on how yadm (or its templating library) 
> searches for these.
In this context, templates are files, in which specific substitutions
are made by a template engine, e.g. a hardcoded awk script.  It has
little to do with environment variables.

Regards,
Leo

Leo Prikler 写道：
> In this context, templates are files, in which specific 
> substitutions
> are made by a template engine, e.g. a hardcoded awk script.  It 
> has
> little to do with environment variables.

Schade.  Thanks!

Kind regards,

T G-R

Tobias,

Am Samstag, den 06.02.2021, 12:46 +0100 schrieb Tobias Geerinckx-Rice:
> Leo, Ellis,
> 
> Leo Prikler 写道：
> > I'd like to say "use your best judgement", but you seem to be a 
> > little
> > too fixated on having a minimal package description (and putting
> > minimal effort into it).
> 
> That's uncalled for.  It's certainly not the impression I get.
Apologies.  To me it read like Ellis wanted to avoid making certain
substitutions for no apparent reason.  I understand, that there may at
times be valid concerns w.r.t. having something as input, but rather
than talk about specific concerns, we just went in circles over what
"optional" means.

> > For instance, when the package advertises encryption, while it 
> > is
> > technically optional, shipping it without gpg would be a grave 
> > oversight!
> 
> Well, that depends.  My own rule of thumb for ‘foo supports 
> encryption!’ is:
> 
>   $ gpg
>   bash: gpg: command not found
>   $ foo --encrypt
>   error: whoopsie: BUG in do_foo()+0x4f44!
>   <16 lines of barftrace>
>   error: warning: error: No such file or directory. (-ERROR)
>   $
> 
> => Make gpg an input, and quick.
> 
>   $ gpg
>   bash: gpg: command not found
>   $ foo --encrypt
>   error: gpg not found, please install it.
>   $
> 
> => This is totally fine, users who want it know what to do next.
Fair enough, but I'd still like to raise a point w.r.t. frequency.  If
most use cases were to somehow involve encryption, I still think it's
better to have it in by default rather than not.  Unlike Debian, we
don't really have (and probably don't want) a "recommended packages"
field in packages.

Regards,
Leo

merge 46215 52996

What's the status of this patch?