Bug 257073 - www/mitmproxy: Fails to build after py-asgiref 3.4.1 upgrade
Summary: www/mitmproxy: Fails to build after py-asgiref 3.4.1 upgrade
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords: needs-qa, regression
Depends on: 258500
Blocks:
  Show dependency treegraph
 
Reported: 2021-07-09 07:18 UTC by p5B2E9A8F
Modified: 2021-09-14 23:32 UTC (History)
4 users (show)

See Also:
gaod: maintainer-feedback+
koobs: maintainer-feedback? (wen)


Attachments
poudriere build log file (13.13 KB, text/plain)
2021-07-09 07:18 UTC, p5B2E9A8F
no flags Details
www_mitmproxy.patch (801 bytes, patch)
2021-07-10 16:04 UTC, Hung-Yi Chen
gaod: maintainer-approval-
Details | Diff
www_mitmproxy.patch (1.75 KB, patch)
2021-07-10 21:01 UTC, Hung-Yi Chen
gaod: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description p5B2E9A8F 2021-07-09 07:18:25 UTC
Created attachment 226319 [details]
poudriere build log file

===========================================================================
=======================<phase: run-depends    >============================
===>   Installing existing package /packages/All/py38-asgiref-3.4.1.txz
[12amd64-default-jails-job-04] Installing py38-asgiref-3.4.1...
[12amd64-default-jails-job-04] Extracting py38-asgiref-3.4.1: .......... done
*** Error code 1

Stop.
=>> Cleaning up wrkdir
build time: 00:00:17
!!! build failure encountered !!!
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2021-07-09 07:21:05 UTC
^Triage: Request feedback from committer of asgiref update

mitmproxy port correctly declares a pinned max version [1]

[1] py38-asgiref>=3.2.10<3.4 : www/py-asgiref@py38
Comment 2 Wen Heping freebsd_committer 2021-07-09 13:11:51 UTC
(In reply to Kubilay Kocak from comment #1)
Upstream changed the asgiref depends to:
asgiref>=3.2.10<3.4

shall we update RUN_DEPENDS as it ?


wen
Comment 3 Wen Heping freebsd_committer 2021-07-09 13:21:14 UTC
(In reply to Kubilay Kocak from comment #1)
Sorry, upstream changed the asgiref depends to:
asgiref>=3.2.10<3.5

shall we update RUN_DEPENDS as it ?


wen
Comment 4 Hung-Yi Chen 2021-07-10 16:04:56 UTC
Created attachment 226354 [details]
www_mitmproxy.patch

I've attached a patch for that.
Comment 5 Hung-Yi Chen 2021-07-10 16:42:46 UTC
Ooops, it seems we still need a patch for 6.0.2. I'll make a new patch later.
Comment 6 Hung-Yi Chen 2021-07-10 21:01:36 UTC
Created attachment 226359 [details]
www_mitmproxy.patch
Comment 7 p5B2E9A8F 2021-07-10 21:46:54 UTC
# https://packaging.python.org/en/latest/requirements/#install-requires
# It is not considered best practice to use install_requires to pin dependencies to specific versions.

With this wisdom found there:

https://bugs.freebsd.org/bugzilla/attachment.cgi?id=226359&action=diff#b/www/mitmproxy/files/patch-setup.py_sec1

I do wonder why these are still used here. They should be used only preventing to break a port but not for intentionally breaking if any dependency got a working upgrade.
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2021-07-11 05:04:31 UTC
(In reply to Hung-Yi Chen from comment #6)

Does mitmproxy pass its tests with only the setup.py patch and no other source changes? Can you point us to relevent upstream issue, pr's and/or commits

If the port doesn't yet have TEST_DEPENDS and a test target, this is a good opportunity to add them.
Comment 9 p5B2E9A8F 2021-07-11 08:48:39 UTC
While I'm absolute sure that all Python-Port-Maintainers internalized the whole https://wiki.freebsd.org/Python/PortsPolicy and beyond, I like to point the more casual readers (those looking for distraction and entertainment) to this:

Use common sense for upstream version requirements that set maximum versions or pin very specific versions, eg: ==, <=, 

and more importantly to https://wiki.freebsd.org/Python/PortsPolicy#Upstreaming

Python port maintainers SHOULD (strongly encouraged) aim to:

   * Craft port patches that are likely to be accepted upstream, even if they are committed locally first.
   * Create upstream issues for bug reports and enhancement requests. Eg:

      -  Better documented requirements in install_requires, tests_require, setup_requires

      -  Optional dependencies made a part of extras_require

      -  Support for python setup.py test command (for regression testing)
	...

   * Regularly test and report test suite failures of Python packages on FreeBSD.

Python-(Upstream)-Dependencies have become more and more a wickerwork that should be addressed where it comes from. More communication with Python-upstream is needed because more and more Python-Environmentists are trying to survive in virtual environments, condas and the like, which results in a never-touch-again-mentality if got something to work at least for a while.
Comment 10 p5B2E9A8F 2021-09-14 08:19:26 UTC
The port still does not build:
=======================<phase: run-depends    >============================
===== env: USE_PACKAGE_DEPENDS_ONLY=1 USER=root UID=0 GID=0
===>   mitmproxy-6.0.2 depends on package: py38-asgiref>=3.2.10<3.4 - not found
===>   Installing existing package /packages/All/py38-asgiref-3.4.1.pkg
[12amd64-default-jails-job-02] Installing py38-asgiref-3.4.1...
[12amd64-default-jails-job-02] Extracting py38-asgiref-3.4.1: .......... done
===>   mitmproxy-6.0.2 depends on package: py38-asgiref>=3.2.10<3.4 - not found
*** Error code 1

Stop.
make: stopped in /usr/ports/www/mitmproxy
=>> Cleaning up wrkdir
===>  Cleaning for mitmproxy-6.0.2
build of www/mitmproxy | mitmproxy-6.0.2 ended at Tue Sep 14 10:00:53 CEST 2021
build time: 00:00:07
!!! build failure encountered !!!

A patch exists:  Hung-Yi Chen 2021-07-10 21:01:36 UTC
A commit never happened.

Upstream moved to 7.0.2 (4 August 2021).

Work on this bug seam to be stuck. What action has to be taken here?
Comment 11 p5B2E9A8F 2021-09-14 18:06:45 UTC
Maintainer created https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258500