Created attachment 150800 [details] py27-discogs-client upgrade from 1.1.1 to 2.0.2 This upgrade introduces a new dependency to the Python package oauth2, see <https://github.com/discogs/discogs_client/blob/v2.0.2/setup.py>. The only reverse dependency to audio/py-discogs-client that I have been able to find is audio/beets. The reason for performing this upgrade is to be able to upgrade audio/beets to 1.3.9.
Auto-assigned to maintainer feld@FreeBSD.org
Also I note that setup.py refers to 'requests' [1] whereas requirements.txt refers to requests=1.2.3 [2] On that evidence, RUN_DEPENDS can be switched to requests>0 and www/requests rather than requests1>=1.0.0 and www/requests1. Creating an issue for upstream to fix the discrepancy would be great. [1] https://github.com/discogs/discogs_client/blob/master/setup.py#L23 [2] https://github.com/discogs/discogs_client/blob/master/requirements.txt#L5
A commit references this bug: Author: feld Date: Sat Dec 20 15:55:53 UTC 2014 New revision: 375009 URL: https://svnweb.freebsd.org/changeset/ports/375009 Log: Update to 2.0.2 PR: 196154 Changes: head/audio/py-discogs-client/Makefile head/audio/py-discogs-client/distinfo
Port updated including koobs RUN_DEPENDS suggestion
The file `requirements.txt` is a Python convention for a set of some known exact library versions suitable for a bootstrapping a development environment. The versions in 'requirements.txt' are not the minimal versions required at runtime, for that 'setup.py' is the authoritative source. Unfortunately, most Python projects do not specify versions in 'setup.py'. Another issue is that the there are separate ports for requests version 1 and 2 (www/py-requests1 and www/py-requests) that conflict with each other. Most ports will work with either version of requests, but since many ports still depend on www/py-requests1, upgrading this port to depend on www/py-requests will render it incompatible with other ports.
So now, the patch for audio/beets that I'm preparing will have to depend on www/py-requests instead of its existing dependency to www/py-requests1.
koobs is more of a python expert than I, so I'll defer to his judgment.
koobs, see previous comment by Stig about the change to www/py-requests1
The comment about the convention is granted, as is the comment that setup.py is authoritative, which is why I suggested the change. More precisely and independent to the ports framework; if you pip install discogs_client, you *will* get the latest version of requests, since setup.py does not read requirements.txt for its install_requires as some other packages do. Without getting into too much of the detail, on one hand; pinning dependency versions can cause unnecessary version constraints, limiting new functionality, not receiving bug fixes. On the other hand; unpinned dependency versions can break API compatibility, which is technically not a problem for downstreams to solve. This is why many package authors end up using >X.0,<Y.0 to stay within the major version. I created the requests1 port (freeing www/requests for upgrade to 2.0+) for exactly the reasons above, since I did not want to assume, prescribe or otherwise waste time wading through all of the dependency ambiguities. This was left to maintainers of other ports to manually make the requests1 -> requests switch, and this is one of those cases :)
Re comment 6, if beets requires requests *directly*, then yes. If it just depends on discogs_client, then the dependency is taken care of, and beets RUN_DEPEND'ing on requests would be considered an unnecessary and duplicate dependency to be removed. The rules of thumb for FreeBSD Python porting are: - Use what is referenced in {setup,install,tests}_requires. Respectively, they refer to BUILD_DEPENDS, RUN_DEPENDS and TEST_DEPENDS. - Match *_DEPENDS version matching as *closely as possible* to upstream, unless it doesn't make sense for ports. - PORTNAME should be identical to upstream PyPI name (ala pip) in most cases for modules. For all other cases, it's a case by case basis.
Grepping for www/py-requests1 through the makefiles: * devel/py-jira/Makefile * devel/py-rauth/Makefile * finance/py-stripe/Makefile * multimedia/spotify-websocket-api/Makefile * www/py-praw/Makefile * www/py-requests-oauth-hook/Makefile * www/radicale/Makefile (and audio/beets/Makefile) Remember that www/py-requests1 and www/py-requests conflict with each other. So, upgrading audio/beets and audio/py-discogs-client to depend on www/py-requests could cause conflicts for those who have any of the ports listed above installed, directly or through dependencies. But I guess the only way forward is to get the maintainers of those ports to upgrade to depend on www/py-requests as well. But please don't misunderstand me. I'm fine with upgrading to depend on www/py-requests, but I just wanted to highlight that there will be consequences for the users.
Repercussions are clear. We should try to move forward with newer versions if possible. Resolving for now.