Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
exclude legacy dependencies when using python3 #85
Fix Python 3 compatibility
I have not opened an issue for this and went straight ahead to fix it.
However, this was reported in the Arch Linux bugtracker as:
Currently the setup.py has some dependencies that are incompatible with
Setuptools provides a nice way to deal with this by using the proper
@@ Coverage Diff @@ ## master #85 +/- ## ========================================== + Coverage 65.99% 66.32% +0.32% ========================================== Files 17 17 Lines 2941 3014 +73 ========================================== + Hits 1941 1999 +58 - Misses 1000 1015 +15
Also, there's literally nothing in those packages preventing them from being installed under Python 3:
It's rather a problem with Arch not packaging it.
Did anyone say there was? It is, however, completely useless bloat and possible saves users some time when not having to download and install something unnecessary.
Why should we package completely useless bloat because you don't know how to dependency?
We need to patch this on our side anyway, so we wanted to contribute that back upstream. I think it is rather odd that you're treating our efforts with such derision.
Yes, @foxxx0 did:
And I've corrected him, because such things must be documented for historical purposes.
Sorry, I didn't mean to do this. I just want to point out that (1) this patch will break things and I will accept a better version of it, also (2) those packages handle feature-detection and whether to patch imports themselves.
This is mean and totally not true. The fact that we left it this way means that it works in the packaging ecosystem we support officially: pypi+pip+setuptools.
Apr 14, 2018
7 of 8 checks passed
Indeed, the upstream ticket only states "cheroot requires.txt includes backports.functools_lru_cache which is a python2 package included in python3." That statement is subtly incorrect as the package is a universal Python 2 and Python 3 package. And as far as I can tell, no error or failure was reported by anyone.
@webknjaz If you're okay with it, I'd like to revert this change.
Regarding Arch's issue, it's a bit different from our standard ecosystem we have to deal with, since when some other package manager kicks in it controls dependencies differently, which implies also wrapping all deps of the target package into their package format as well.
Also, it looks like there's two system installations of Python (2 and 3) living alongside and for each python distribution there's a separate pacman package for each of these installations, like it should be