guix-patches
[Top][All Lists]
Advanced

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

[bug#51314] [PATCH v4 05/14] gnu: Add python-zeroconf-0.33.


From: Maxime Devos
Subject: [bug#51314] [PATCH v4 05/14] gnu: Add python-zeroconf-0.33.
Date: Mon, 30 May 2022 23:30:04 +0200
User-agent: Evolution 3.38.3-1

Vinicius Monego schreef op ma 30-05-2022 om 20:55 [+0000]:
> As mentioned in the cover letter for v4, octoprint hard-checks the
> versions of its dependencies and uses pip to download new versions for
> the packages it judges the version is incorrect. In the case of
> zeroconf there is a notice in setup.py:
> 
> https://github.com/OctoPrint/OctoPrint/blob/53b9b6185781c07e8c4744a6e28462e96448f249/setup.py#L67

To me this seems information to put in a comment next to the input list
(and next to python-zeroconf-0.33). Also, I recommend removing the pip
downloading code to be 100% sure it won't be run.

> The author recognizes that octoprint is not so friendly to packagers:
> https://github.com/OctoPrint/OctoPrint/issues/1922#issuecomment-302407764
> It does depend on specific versions of some packages, for the one  >
or other reasons, and this is something I do not want not change
> > - I've run into too many problems with outdated python libraries
> > provided by the system package manager that produced horribly
> > hard to track down bugs.

There are bugs in the python-zeroconf@0.33 that have been fixed in
python-zeroconf@0.38.1.  The readme in
https://github.com/jstasiak/python-zeroconf mentions a few fixed bugs
that seem rather subtle.

So as-is, we would be distributing an octoprint with a known-buggy
depdendency with known fixes.  Though neither is changing to the new
zeroconf an option (unless changes are made to octoprint) as-is because
the new zeroconf is apparently incompatible.

Greetings,
Maxime.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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