[PATCH] Add yadm

OpenSubmitted by Ellis Kenyo.
Details
3 participants
  • Leo Prikler
  • Ellis Kenyo
  • Tobias Geerinckx-Rice
Owner
unassigned
Severity
normal
E
E
Ellis Kenyo wrote on 31 Jan 2021 17:47
(address . guix-patches@gnu.org)(name . Ellis Kenyo)(address . me@elken.dev)
20210131164721.8792-1-me@elken.dev
---
gnu/packages/package-management.scm | 32 +++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)

Toggle diff (42 lines)
diff --git a/gnu/packages/package-management.scm b/gnu/packages/package-management.scm
index 98af2187fa..845098aa10 100644
--- a/gnu/packages/package-management.scm
+++ b/gnu/packages/package-management.scm
@@ -1479,3 +1479,35 @@ It is mainly meant for programmers who develop portable programs or libraries in
 but could potentially work for end-users of those programs.  It also has a translator
 from R7RS, which allows most R7RS code to run on R6RS implementations.")
     (license license:gpl3+)))
+
+(define-public yadm
+  (package
+    (name "yadm")
+    (version "3.0.2")
+    (source (origin
+              (method git-fetch)
+              (uri (git-reference
+                    (url "https://github.com/TheLocehiliosan/yadm")
+                    (commit version)))
+              (file-name (git-file-name name version))
+              (sha256 (base32 "18lqy8hm1y1hkzmjpiwn1i29yk2hg7mrvyi0x5imvfxz3j4jj2qa"))))
+    (build-system gnu-build-system)
+    (arguments
+     '(#:tests? #f
+       #:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")))
+       #:phases
+       (modify-phases %standard-phases
+         (delete 'bootstrap)
+         (delete 'configure)
+         (delete 'build))))
+    (synopsis "Yet Another Dotfile Manager")
+    (home-page "https://yadm.io")
+    (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.")
+    (license license:gpl3)))
-- 
2.30.0
L
L
Leo Prikler wrote on 31 Jan 2021 18:38
84ab5054792abeb5e9b85d21229cd7182204d817.camel@student.tugraz.at
Hello Ellis,

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

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

Toggle quote (7 lines)
> + #: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).

Toggle quote (15 lines)
> + (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).

Toggle quote (1 lines)
> + (license license:gpl3)))
Should be gpl3+.

Regards,
Leo
E
E
Ellis Kenyő wrote on 31 Jan 2021 21:16
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)(address . 46215@debbugs.gnu.org)
87czxkc0yv.fsf@elken.dev
Hi Leo,

Thanks for the feedback.

Toggle quote (1 lines)
> Your commit is missing a ChangeLog in its message.
This will be added with the next patch.

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

Toggle quote (8 lines)
> 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.

Toggle quote (5 lines)
> 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.

Toggle quote (1 lines)
> Should be gpl3+.
This will also be added to the next patch.

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

Toggle quote (64 lines)
> 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


--
---
elken
L
L
Leo Prikler wrote on 31 Jan 2021 21:36
(name . Ellis Kenyő)(address . me@elken.dev)(address . 46215@debbugs.gnu.org)
0ff6a0c2cc9a2f65cd51c1eeb9e6a33aa4789766.camel@student.tugraz.at
Hi Ellen,

Am Sonntag, den 31.01.2021, 20:16 +0000 schrieb Ellis Kenyő:
Toggle quote (9 lines)
> 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.

Toggle quote (11 lines)
> > 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
E
E
Ellis Kenyő wrote on 1 Feb 2021 04:44
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)(address . 46215@debbugs.gnu.org)
669deac8-ffa5-42ba-8741-3cae0b18220e@elken.dev
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:
Toggle quote (46 lines)
>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
Attachment: file
L
L
Leo Prikler wrote on 1 Feb 2021 09:13
(name . Ellis Kenyő)(address . me@elken.dev)(address . 46215@debbugs.gnu.org)
38ed969df583e9254802fa7a4a80299ec5caddc4.camel@student.tugraz.at
Am Montag, den 01.02.2021, 03:44 +0000 schrieb Ellis Kenyő:
Toggle quote (7 lines)
> 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
E
E
Ellis Kenyő wrote on 1 Feb 2021 11:06
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)(address . 46215@debbugs.gnu.org)
a69c6126-5304-48ca-a992-a6a0254e2d84@elken.dev
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:
Toggle quote (14 lines)
>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
Attachment: file
L
L
Leo Prikler wrote on 1 Feb 2021 12:44
(name . Ellis Kenyő)(address . me@elken.dev)(address . 46215@debbugs.gnu.org)
9efaa5895bc488ddd4fd8c456aa5c2fdf09cb4af.camel@student.tugraz.at
Am Montag, den 01.02.2021, 10:06 +0000 schrieb Ellis Kenyő:
Toggle quote (2 lines)
> 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
E
E
Ellis Kenyő wrote on 6 Feb 2021 11:05
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)(address . 46215@debbugs.gnu.org)
87pn1dpkwr.fsf@elken.dev
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:

Toggle quote (21 lines)
> 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


--
Regards,
elken
L
L
Leo Prikler wrote on 6 Feb 2021 11:48
(name . Ellis Kenyő)(address . me@elken.dev)(address . 46215@debbugs.gnu.org)
d3e6681b2ad06ddbd0458aae96773b1d8128a26e.camel@student.tugraz.at
Hi Ellis,

Am Samstag, den 06.02.2021, 10:05 +0000 schrieb Ellis Kenyő:
Toggle quote (4 lines)
> 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.

Toggle quote (2 lines)
> 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.

Toggle quote (3 lines)
> 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.

Toggle quote (1 lines)
> 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
E
E
Ellis Kenyő wrote on 6 Feb 2021 11:58
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)(address . 46215@debbugs.gnu.org)
9b32a7b7-9664-4108-a66c-f3de42d10c68@elken.dev
Toggle quote (1 lines)
> 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:
Toggle quote (39 lines)
>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
Attachment: file
L
L
Leo Prikler wrote on 6 Feb 2021 12:22
(name . Ellis Kenyő)(address . me@elken.dev)(address . 46215@debbugs.gnu.org)
78f1ced9e2125994a806383fb1d985d256874a81.camel@student.tugraz.at
Am Samstag, den 06.02.2021, 10:58 +0000 schrieb Ellis Kenyő:
Toggle quote (11 lines)
> > 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
E
E
Ellis Kenyő wrote on 6 Feb 2021 12:26
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)(address . 46215@debbugs.gnu.org)
330eb3b4-1e90-4c0e-bb83-a8bd2cd81365@elken.dev
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:
Toggle quote (23 lines)
>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
Attachment: file
T
T
Tobias Geerinckx-Rice wrote on 6 Feb 2021 12:30
Re: [bug#46215] [PATCH] Add yadm
(name . Ellis Kenyő)(address . me@elken.dev)
871rdtxwkx.fsf@nckx
Ellis,

Ellis Kenyő via Guix-patches via 写道:
Toggle quote (3 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYB59zg0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15UgoBAJUizEAAR+MHMzz+jVmscRlMwjAYI2/YCMvZoqQ2
PJJWAP9vosK1ucO7rmhlDJYGnj9yQJme1ANYkOBJjyiROPv1Bg==
=BQbI
-----END PGP SIGNATURE-----

E
E
Ellis Kenyő wrote on 6 Feb 2021 12:43
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
69ac9a7c-8e9f-44b4-8cbd-f860262350a9@elken.dev
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.

Toggle quote (2 lines)
> Does that not work?

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

Toggle quote (1 lines)
> 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:
Toggle quote (23 lines)
>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
Attachment: file
T
T
Tobias Geerinckx-Rice wrote on 6 Feb 2021 12:46
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
87y2g1wha4.fsf@nckx
Leo, Ellis,

Leo Prikler 写道:
Toggle quote (5 lines)
> 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.

Toggle quote (5 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYB6Bgw0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15xkoBAMFThoVuK+dIf/i917Fnk9RBNFcUxKXqqRH3BhIH
R3pRAQD4XlUZH8EIba0nh3sd05OneuL0V/H9xzHA1fyzPctxBg==
=U7xR
-----END PGP SIGNATURE-----

L
L
Leo Prikler wrote on 6 Feb 2021 12:58
(address . 46215@debbugs.gnu.org)
a72f963c30d6d36b3b03bc8a4015ad6f9cb4aac4.camel@student.tugraz.at
Am Samstag, den 06.02.2021, 12:30 +0100 schrieb Tobias Geerinckx-Rice:
Toggle quote (3 lines)
> 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
T
T
Tobias Geerinckx-Rice wrote on 6 Feb 2021 13:03
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
87v9b5wghe.fsf@nckx
Leo Prikler 写道:
Toggle quote (6 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYB6FjQ0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW1501QA+wYDAEgOIhtGf85zkkZoXNaQli0lMNA55l7QpoX7
sktNAQCVhz//DDlbCOdWWsN+Y91SAM9OFD3fWP+LFgVUjQcwBQ==
=Ft4O
-----END PGP SIGNATURE-----

L
L
Leo Prikler wrote on 6 Feb 2021 13:41
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
e58fed8faae06e5d5f2a7e848faf9a4d92d1e09c.camel@student.tugraz.at
Tobias,

Am Samstag, den 06.02.2021, 12:46 +0100 schrieb Tobias Geerinckx-Rice:
Toggle quote (9 lines)
> 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.

Toggle quote (25 lines)
> > 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
?