(name . Leo Prikler)(address . firstname.lastname@example.org)(address . email@example.com)
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 <firstname.lastname@example.org> wrote:
Toggle quote (39 lines)
>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
>> 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
>> 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
>> 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