[PATCH] 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:

Your commit is missing a ChangeLog in its message.

Document why (i.e. "no check target").

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

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

Should be gpl3+.

Regards,

Leo

Hi Leo,

Thanks for the feedback.

This will be added with the next patch.

I have also added similar comments for the other removed stages.

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.

I was looking for an accurate description on the site, I have

replaced

with that and the linter passes.

This will also be added to the next patch.

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

--

---

elken

Hi Ellen,

Am Sonntag, den 31.01.2021, 20:16 +0000 schrieb Ellis Keny?:

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.

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:

Am Montag, den 01.02.2021, 03:44 +0000 schrieb Ellis Keny?:

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, 10:06 +0000 schrieb Ellis Keny?:

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:

--

Regards,

elken

Hi Ellis,

Am Samstag, den 06.02.2021, 10:05 +0000 schrieb Ellis Keny?:

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.

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.

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.

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

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:

Am Samstag, den 06.02.2021, 10:58 +0000 schrieb Ellis Keny?:

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:

Ellis,

Ellis Keny? via Guix-patches via ???

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.

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

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:

Leo, Ellis,

Leo Prikler ???

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

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:

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 ???

Schade. Thanks!

Kind regards,

T G-R

Tobias,

Am Samstag, den 06.02.2021, 12:46 +0100 schrieb Tobias Geerinckx-Rice:

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.

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?