Bug 255307

Summary: net/py-pynsq: update to 0.9.0 (fixes indirect conflict with math/py-matplotlib)
Product: Ports & Packages Reporter: John Hein <jcfyecrayz>
Component: Individual Port(s)Assignee: Thierry Thomas <thierry>
Status: Closed Overcome By Events    
Severity: Affects Only Me CC: jcfyecrayz, thierry
Priority: --- Keywords: needs-qa
Version: LatestFlags: bugzilla: maintainer-feedback? (koobs)
jcfyecrayz: maintainer-feedback+
jcfyecrayz: merge-quarterly?
Hardware: Any   
OS: Any   
URL: https://github.com/nsqio/pynsq/releases/tag/v0.9.0
Attachments:
Description Flags
[patch] update to 0.9.0
none
[patch] update to 0.9.0 [v2] jcfyecrayz: maintainer-approval? (koobs)

Description John Hein 2021-04-21 16:02:02 UTC 
Created attachment 224333 [details]
[patch] update to 0.9.0

Update py-pynsq to 0.9.0

0.9.0 now supports tornado > 5

 This is important for playing well in the ports tree.  It avoids
 the problem of, for example, py-matplotlib depending on www/py-tornado
 (currently 6.1) and py-pynsq depending on www/py-tornado5 (5.1.1).
 These two tornado versions currently install conflicting files,
 so this effectively prevents users from installing py-pynsq when
 py-matplotlib is installed.  There may be other similar examples
 of dependency issues.

 tornado6 & tornado5 might be able to co-exist, but I suspect that
 would be a lot harder to implement (probably requiring leaf port
 changes).


0.9.0 also addresses some other issues:
https://github.com/nsqio/pynsq/releases/tag/v0.9.0

In addition to the tornado support update, the most notable changes
are IPv6 support and improved RDY handling.



Note regarding PORTVERSION / DISTVERSION:

When this port was updated to 0.9.0b1, it should have used DISTVERSION
instead of PORTVERSION.

This would have generated a PORTVERSION of 0.9.0.b1.  It seems
upstream intended b1 to mean beta #1 (rather than a "later" minor
update to 0.9.0).  0.9.0.b1 is better for package versioning
comparison.

Now that we want to update to 0.9.0, version comparison thinks
0.9.0b1 is later than 0.9.0

Address this by using DISTVERSION=0.9.0 so the fetch gets the
right version - and because 0.9.0<0.9.0b1, set PORTVERSION=0.9.0rel
which evaluates to later than 0.9.0b1.  This is better than using
a permanent PORTEPOCH bump.

% pkg version --test-version 0.9.0 0.9.0b1_1
<
% pkg version --test-version 0.9.0 0.9.0.b1_1
>
% pkg version --test-version 0.9.0rel 0.9.0b1_1
>

The porter's handbook currently documents this situation fairly well.
See section 5.2.2, particularly example 5.4 and 5.5.

I appreciate the subtle distinction between DISTVERSION & PORTVERSION (pre-release designators such as alpha, beta, etc. vs. post-release patch levels) a wee bit more after dealing with this particular case.  I'll think twice before just updating PORTVERSION for a port update in the future since every upstream will apply versioning per its own (sometimes not well thought out) scheme.
Comment 1 John Hein 2021-05-04 19:54:13 UTC 
Created attachment 224666 [details]
[patch] update to 0.9.0 [v2]

Reworked patch to avoid DISTVERSION & PORTVERSION defined at the same time.  It worked fine that way, but the handbook (& portlint) frown on that.

So tweak the patch to specify GH_TAGNAME=v0.9.0 and PORTVERSION=0.9.0r.  The latter is for the same reason mentioned for the first patch: to be "greater than" 0.9.0b1 without restoring to PORTEPOCH.  I used 'r' instead of 'rel' just because portlint didn't like the latter.  But the meaning for the 'r' is that it is the real 0.9.0 release (instead of the "b1" beta).

Again if the update to the 0.9.0b1 beta had used DISTVERSION as it should have, this would not be needed and the update to 0.9.0 (using PORTVERSION or DISTVERSION, although I think the latter is better generally) would have correctly been "0.9.0 > 0.9.0.b1".

For 0.9.1 (or some later release), I would use DISTVERSION.  That future update can go back to DISTVERSION + DISTVERSIONPREFIX=v and drop GH_TAGNAME, or continue to use GH_TAGNAME + DISTVERSION without DISTVERSIONPREFIX.  Both seem reasonable.

QA:
  portlink (ok)
  poudriere (ok - py38, stable-11/amd64)
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2021-05-05 02:29:08 UTC 
Thanks John. Should this be merged to quarterly? If so please set merge-quarterly flag to ? with comment:

MFH: <branch> (<reason)>

else, set merge-quarterly to - with comment:

MFH: No (<reason))
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2021-05-05 03:04:53 UTC 
@John Can I ask what the conflicting tornado files are?
Comment 4 John Hein 2021-05-11 01:12:12 UTC 
(In reply to Kubilay Kocak from comment #3)
'pkg register' complained about this:
pkg-static: py37-tornado5-5.1.1 conflicts with py37-tornado-6.1 (installs files into the same place).  Problematic file: /usr/local/lib/python3.7/site-packages/tornado/__init__.py

But I don't think that's the only conflict.  At a quick glance at file listings also: tornado/platform/twisted.py, tornado/process.py, tornado/queues.py, and more.  Dozens it seems.
.
Comment 5 John Hein 2021-05-11 01:21:46 UTC 
(In reply to Kubilay Kocak from comment #2)
Yes, I think this needs the same change on 2021Q2

MFH: 2021Q2 (conflict reduction)
Comment 6 John Hein 2021-05-11 01:27:27 UTC 
(In reply to John Hein from comment #5)

It looks like [1] 'reason' for MFH wants only one of: bugfix or security release, so this instead, I guess:

MFH: 2021Q2 (bugfix)

[1] https://wiki.freebsd.org/Bugzilla/TriageTraining
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2021-05-11 01:38:56 UTC 
(In reply to John Hein from comment #6)

The list is not exhaustive, only providing (common) examples for bugfix and security releases. I'll add notes to this effect, thanks!
Comment 8 Rene Ladan freebsd_committer freebsd_triage 2022-03-07 19:55:16 UTC 
Maintainer reset.
Comment 9 Thierry Thomas freebsd_committer freebsd_triage 2023-08-29 18:31:35 UTC 
Thanks for this PR, but since net/py-pynsq has been upgraded to 0.9.1 we can close it.