Created attachment 163186 [details] math/py-networkx: Update to 1.10 Changelog: * Update to 1.10 * Add YAML option (on by default) * Remove gratuitous word from option descriptions * USE_PYTHON=concurrent instead of setting EXAMPLESDIR * Alphabetize USE_PYTHON * Discard pkg-message given all options are enabled by default QA: * testport: OK (10.1-RELEASE-p22, amd64, python27 and python34) * portlint: OK (0 fatal errors, 1 warning)
Created attachment 163187 [details] py27-networkx-1.10 testport log
Created attachment 163188 [details] py34-networkx-1.10 testport log
(In reply to John W. O'Brien from comment #0) Looks good for me. Approved.
looks good for me. Approved. (Sorry, previously I used wrong email address for this bug)
@dikshie: Thank you. I believe the formal way to indicate approval (which I am trying right now) is to set the "Flags: bugzilla: maintainer-feedback: +".
(In reply to John W. O'Brien from comment #5) Actually it's the maintainer-approval flag (attachment context). At the moment there is a permissions issue which precludes a person (normally the maintainer) who's name is currently set as the value of a flag set to ?. This does not affect anyone from setting the maintainer-approval flag to + for attachments they are the creators of. We'll be resolving this permission issue soon. In the meantime, try to set the maintainer-approval flag. If it doesn't work, the following is recommended: Add a comment saying: "Attachment <id-of-attachment> approved"
Comment on attachment 163186 [details] math/py-networkx: Update to 1.10 Maintainer approved in comment 3
A commit references this bug: Author: rm Date: Thu Nov 19 18:36:59 UTC 2015 New revision: 401958 URL: https://svnweb.freebsd.org/changeset/ports/401958 Log: math/py-networkx: update to 1.10 - update to 1.10 - add YAML option (on by default) - remove gratuitous word from option descriptions - USE_PYTHON=concurrent instead of setting EXAMPLESDIR - alphabetize USE_PYTHON - discard pkg-message given all options are enabled by default While here limit python version to 2.x, because it's dependencies graphics/py-graphviz and math/py-matplotlib failed to configure with python3. PR: 204594 Submitted by: John W. O'Brien <john@saltant.com> Approved by: dikshie@sfc.wide.ad.jp (maintainer) Changes: head/math/py-networkx/Makefile head/math/py-networkx/distinfo head/math/py-networkx/files/patch-setup.py head/math/py-networkx/pkg-descr head/math/py-networkx/pkg-message
Committed, thank you!
rm@: Would you consider backing out the python2 limitation, or perhaps accepting a patch from me that automatically removes those options from OPTIONS_DEFAULT when being built under py3k? I had submitted bug #201349 for the express purpose of working around the dependencies that are not yet py3k-ready.
Sure, would you provide me with the patch that eliminating failing dependencies when built with python3? I see no such patch in bug #201349, and it would be better to redo against the current port version anyway. PS. btw science/py-scikit-sparse builds fine with py34 in my test.
rm@ What I meant was that bug #201349 made the dependencies optional so that ports users interested in py3k could readily adapt and that math/py-networkx wouldn't necessarily have to encode knowledge about the py3k-readiness of other ports. However, if you prefer the latter, I'll be glad to put together a patch. Look for it over the weekend. re: science/py-scikit-sparse -- I know :) (see: bug 201346)
Ok, nevermind, I'll cook the patch myself now.
(In reply to Ruslan Makhmatkhanov from comment #9) Many thanks!
The sad news that I can't redefine OPTIONS_DEFAULT values depending on python version. I mean this is not working: .include <bsd.port.pre.mk> .if ${PYTHON_REL} <= 3000 OPTIONS_DEFAULT+= MPL GRAPHVIZ .endif .include <bsd.port.post.mk> So, I'm not sure how to fix that properly. The only solution is to drop MPL and GRAPHVIZ options and make them uncoditional runtime dependencies for python2 build. This may be ok, because these options are default anyway. Is it applicable?
I found the following precedents for what to do in this case. www/py-cherrypy -- leave the option alone but nuke the associated ${opt}_RUN_DEPENDS based on PYTHON_REL .if ${PYTHON_REL} >= 3000 .undef MPL_RUN_DEPENDS .undef GRAPHVIZ_RUN_DEPENDS .endif www/py-autobahn, devel/llvm37 -- set BROKEN .if (${PORT_OPTIONS:MMPL} || ${PORT_OPTIONS:MGRAPHVIZ) && ${PYTHON_REL} >= 3000 BROKEN= matplotlib and graphviz do not yet support python3. Please disable the MPL and GRAPHVIZ options. .endif I favor the latter. dikshie?
(In reply to John W. O'Brien from comment #16) I am fine with your solution.
Good catch, John. I'd prefer to go the first way this evening after testing. First because it will not be possible to build the port with python3 in poudriere w/o user intervention (unchecking options).
@rm: For those who get as far as building with poudriere, fiddling with options seems almost like a given. The reason I prefer the latter option is because the former option will result in a package that claims it was built with option X, yet option X has no effect at all, let alone the intended or implied effect. However, I tried to implement the latter option, and it isn't working as expected and I don't yet know why. The port is setting BROKEN as I intend, but poudriere charges ahead, and tried to build dependencies destined to fail rather than refusing informatively.
Created attachment 164187 [details] Mark math/py-networkx BROKEN with py3k+(MPL|GRAPHVIZ)
John, sorry for delay. Today's morning I set up poudriere to build with first option. Once it finishes I'll check with your patch and commit.
@rm: No worries. I finally got around to learning why poudriere doesn't skip the BROKEN port (https://lists.freebsd.org/pipermail/freebsd-ports/2015-December/101361.html). It turns out that's by design. Don't expect my latest patch to affect poudriere's behavior.
Ok, understood. So what the consensus is? We keep up with your latest patch and do not allow user to get the py3 package without manual intervention, or we use .undef solution to let user get the py3 package, that claim that it has not-enabled package options? PS. It's still building the dependencies, so it looks like it would be ready at tomorrow on my slow home server.
I still favor the path that tells the truth and requires action on the part of the user over the path that lies and requires nothing of the user. The BROKEN mechanism is not a perfect solution, but it appears to be the best one we have at the moment. It seems to me that poudriere has made a somewhat odd choice by silencing the helpful output from BROKEN. However, our first duty is to ports proper, and second (or later) to poudriere users.
(In reply to John W. O'Brien from comment #24) I am fine with this solution. please go ahead commit it. after that we can think about poudriere. thanks!
@Dickshie, please set maintainer-approval to + on the attachment you approve. @John, we'll want only a single approved, non-obsolete attachment here to progress
(In reply to Kubilay Kocak from comment #26) Are you suggesting that I need to do something? There are two patches attached to this bug, one received maintainer approval and has already been committed (in modified form). The other is awaiting maintainer approval.
(In reply to Kubilay Kocak from comment #26) @Koobs thank you for the reminder. I just add + maintainer-approval.
A commit references this bug: Author: rm Date: Tue Jan 5 08:42:05 UTC 2016 New revision: 405276 URL: https://svnweb.freebsd.org/changeset/ports/405276 Log: math/py-networkx: let it build with python3 Drop the python version limit, by asking user to uncheck some options, that will not work with python3 for now. PR: 204594 Submitted by: John W. O'Brien <john@saltant.com> Approved by: dikshie@sfc.wide.ad.jp (maintainer) Changes: head/math/py-networkx/Makefile
Committed, thank you.