Bug 196154 - audio/py-discogs-client: Update to 2.0.2
Summary: audio/py-discogs-client: Update to 2.0.2
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Mark Felder
Keywords: easy, needs-qa, patch
Depends on:
Blocks: 196160
  Show dependency treegraph
Reported: 2014-12-20 13:19 UTC by Stig Inge Lea Bjørnsen
Modified: 2014-12-21 16:17 UTC (History)
2 users (show)

See Also:
koobs: maintainer-feedback+

py27-discogs-client upgrade from 1.1.1 to 2.0.2 (1.06 KB, patch)
2014-12-20 13:19 UTC, Stig Inge Lea Bjørnsen
koobs: maintainer-approval? (feld)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stig Inge Lea Bjørnsen 2014-12-20 13:19:53 UTC
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.
Comment 1 Bugzilla Automation freebsd_committer 2014-12-20 13:19:53 UTC
Auto-assigned to maintainer feld@FreeBSD.org
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2014-12-20 13:42:47 UTC
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
Comment 3 commit-hook freebsd_committer 2014-12-20 15:56:07 UTC
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

  Update to 2.0.2

  PR:		196154

Comment 4 Mark Felder freebsd_committer 2014-12-20 15:56:41 UTC
Port updated including koobs RUN_DEPENDS suggestion
Comment 5 Stig Inge Lea Bjørnsen 2014-12-20 16:17:49 UTC
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.
Comment 6 Stig Inge Lea Bjørnsen 2014-12-20 16:21:23 UTC
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.
Comment 7 Mark Felder freebsd_committer 2014-12-21 01:01:21 UTC
koobs is more of a python expert than I, so I'll defer to his judgment.
Comment 8 Mark Felder freebsd_committer 2014-12-21 01:02:27 UTC
koobs, see previous comment by Stig about the change to www/py-requests1
Comment 9 Kubilay Kocak freebsd_committer freebsd_triage 2014-12-21 02:16:52 UTC
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 :)
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2014-12-21 02:22:31 UTC
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.
Comment 11 Stig Inge Lea Bjørnsen 2014-12-21 13:41:35 UTC
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.
Comment 12 Mark Felder freebsd_committer 2014-12-21 16:17:18 UTC
Repercussions are clear. We should try to move forward with newer versions if possible.

Resolving for now.