cloudprint will not start with the following traceback: Starting cloudprint. Traceback (most recent call last): File "/usr/local/bin/cloudprint", line 6, in <module> from pkg_resources import load_entry_point File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3019, in <module> @_call_aside File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3003, in _call_aside f(*args, **kwargs) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3032, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 655, in _build_master ws.require(__requires__) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 963, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 849, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'argparse' distribution was not found and is required by cloudprint /usr/local/etc/rc.d/cloudprint: WARNING: failed to start cloudprint
argparse was removed as a dependency by rene in r427780 [1], assign accordingly (maintainer remains cc'd). devel/py-argparse was originally deleted in r427781 [2], then revived in r440641 [3] If the stdlib argparse module can be used without package code changes (like import paths or function calls), then the argparse dependency should either be a) patched out of setup.py:install_requires as those *_requires do not test for presence of a package in/module in the standard library (as far as im aware). b) The devel/py-argparse dependency removal commit should be reverted (or added back to RUN_DEPENDS if that cannot be done). [1] http://svnweb.freebsd.org/changeset/ports/427780 [2] http://svnweb.freebsd.org/changeset/ports/427781 [3] http://svnweb.freebsd.org/changeset/ports/440641
To clarify comment 1 if no code changes are required then: (a) *ELSE* (b)
I don't know much about python and using libraries in it, but here's what I was able to hack up based on what I know. I realize that the py-argparse port was removed since the functionality was included in the standard library. I tried removing the import statements that were causing the errors, but then the calls to parser = argparse.ArgumentParser() were failing. I found a package py-configargparse which claims to be a drop in replacement for argparse. I modified the sources to reflect configargparse in all locations (3) where argparse was referenced. I rebuilt the port and it's working for me. I'm sure there's someone with more python than I know that can fix it better. I can provide a simple patch to show what I did.
(In reply to nimrodl from comment #3) I don't believe code changes should be required. 1) if removal of setup.py:install_requires=argparse works without changes, OR 2) if (1) indicates code changes are required, add py-argparse back to RUN_DEPENDS In *either case*, the issue should be reported upstream, and at a minimum, argparse made a conditional dependency only on versions where argparse is not in the standard library.
Upstream has switched to ConfigArgParse on latest github [1] so I think the best way forward will be to update the port to latest code from master branch and add a RUN_DEPENDS on devel/py-configargparse. I have already checked the changes since 0.14 and they seem to be mostly harmless so I will prepare an update for the port. Stay tuned! [1] https://github.com/armooo/cloudprint/commit/326ce761621e2f0559e0cfab4878c5c46beae52d
A commit references this bug: Author: decke Date: Mon Jun 12 08:37:05 UTC 2017 New revision: 443416 URL: https://svnweb.freebsd.org/changeset/ports/443416 Log: Fix dependency issue with missing argparse since it's removal in r427780. Upstream has switched to ConfigArgParse in the meantime so let's update the port to latest master and switch to ConfigArgParse. PR: 219890 Reported by: nimrodl@gmail.com Thanks to: koobs@FreeBSD.org Changes: head/print/cloudprint/Makefile head/print/cloudprint/distinfo
Note that the quarterly version is still affected. One of the reason its (highly) preferable to separate fixes from version updates is that so those fixes can be merged to the quarterly branch where those users can benefit.
(In reply to Kubilay Kocak from comment #7) To level set, I've been using the quarterly ports tree. I didn't think about looking at upstream, but it sounds like this is the way to go. It's been broken all quarter, so a couple more weeks until the next quarterly release shouldn't be an issue. Thanks for following up on this.
I don't think this is the right place to discuss this religious stuff. If it affects you and you are on a quaterly branch feel free to either wait for the next quarter or switch to the latest packages until the next quarter starts. The way we are currently handling quarterly branches is less than ideal in my opinion because nobody tests anything in that combination. I don't plan to merge this change to quarterly but if anybody wants to do it feel free to do so (you have my explicit approval).
(In reply to Bernhard Froehlich from comment #9) Totally understood. I was just pointing out that I had been using the quarterly branch and hadn't thought to look at the upstream code and that since I was the first one to notice the problem that I could find, I didn't think it would be an issue to wait for the next quarterly package release. Again, thanks for looking into the issue.
@decke if there's any place, bugzilla is the best place (if not the only place) to discuss and document whether a specific issue affects (head or quarterly) and what should be done about it, independent of our individual feelings about the implementation. This is especially the case since the user in question (reporter) uses the quarterly version. 'its only a few weeks' until the next quarterly branch is not a sufficient warrant to not merge, and is a slippery slope to 'its only 3 months till the next quarterly branch' Over to ports-secteam to merge, or not (with comment).
We have Q1 2018. So I close as fixed.