[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#28693] [PATCH] gnu: Add missing input to python-py3status.

From: Tomáš Čech
Subject: [bug#28693] [PATCH] gnu: Add missing input to python-py3status.
Date: Thu, 5 Oct 2017 23:08:57 +0200
User-agent: NeoMutt/20170912 (1.9.0)

Hi Christopher,

first, let me thank you for your long explanatory review, I really
appreciate it.

On Wed, Oct 04, 2017 at 06:59:44AM +0000, Christopher Baines wrote:
On Wed,  4 Oct 2017 00:57:57 +0200
Tomáš Čech <address@hidden> wrote:

* gnu/packages/python.scm (python-py3status): Add missing input.

file is used to determine configuration file encoding and py3status
fails to run when this tool is missing.

Hey Tomáš,

I don't know much about python-py3status, but I had a look at building
it with and without this patch, and it worked for me both times.

That is correct.

When building with this patch, so with file as an additional input, the
resulting store item does not reference the file store item (which you
can check using guix size, which lists the referenced store items [1]).

Given file is used at runtime, it would be good if the resulting store
item for python-py3status referenced file. As far as I can see, file is
used here [2], so you could use the substitute* procedure to replace
the command name with an absolute path to the binary in the store. This
absolute path would then mean that file is recorded as a "runtime"
dependency of python-py3status.

I have taken this approach as it seems to me as the most clean one. It
works and `guix size' command now shows the file store in the list.

Other approaches include wrapping the py3status binary to ensure the
PATH environment variable includes the dependencies (like file), or
adding file as to propagated-inputs (rather than inputs), which ensures
its installed when py3status is installed.

All of these 3 approaches I've mentioned have some downsides. Patching
the files is tricky, and what is used where can change in later

It adds burden to maintainer to verify sufficiency and need for every
code change but besides that it looks as proper solution.

As for wrapping, that is inelegant, and wouldn't help if this
is used as a python library.


Propagated inputs can conflict with other
packages and propagated inputs, which can cause issues for people
installing and upgrading packages.

This point is interesting to me - can you please give me example?

From the number of occurrences of the subprocess module in this
package, this seems to be a problem not limited to the file tool, but a
large number of programs.

That is correct but other occurences are related to plugins providing
functionality. User has to prepare configuration to use that code.

Problem I'm trying to fix is causing hard-to-catch confusing error
right after start for everyone who is missing file in PATH.

I somehow miss expressing optional run-time dependencies in Guix which
would suit for this. I guess I'd go here with lazy approach and
provide basic functionality my problem and let advanced user to deal
with plugin problems by himself.

Otherwise the closure would grow beyond reason.

What do you think? Can this be the way here?

Best regards,


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]