py3.4 install failure due to latest pygments release
The latest pygments release appears to depend upon py3.5; since pudb just depends upon pygments>=1.0, then this causes pudb to now depend upon py3.5, and fails to install on py3.4.
In zulip-term we plan to pin pygments to an earlier version as a workaround for now, since we don't explicitly depend on pygments but want pudb to be installable for devs.
What are you suggesting pudb should do?
I generally feel that this is (morally) "not our problem", in that I feel pip/setuptools is just too dumb to realize that installing a package on Py3.4 that doesn't declare support for it is likely not going to work.
As a workaround, we could
- pin to pygments supported on 3.4, or
- drop support for 3.4.
@inducer In this particular case I just saw this as a bug due to the inconsistency between the claimed python version compatibility of pudb and reality (due to the dependency). I'm not currently aware of how to resolve this kind of issue in general, if such a solution exists.
I agree that either of the options you suggest are valid solutions/workarounds. I wasn't sure if you had a plan of when to migrate to py3.5, so was leaving the decision to you on whether to do one and then the other (migrating later) or just the latter (migrating now).
To follow-up on this, we've now dropped python 3.4 support (due to it reaching end of line), so this is not an issue for us. The original issue may be correlated to our use of pipenv in Travis, since we also experienced this same bug with requests, for which the latest package supports only python 3.5+, but which appears to install fine in another system using just pip rather than pipenv.
I would be interested to know what you end up doing.