Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Python 3.2 coverage has a syntax error #20

Closed
jayvdb opened this issue Sep 25, 2015 · 2 comments
Closed

Python 3.2 coverage has a syntax error #20

jayvdb opened this issue Sep 25, 2015 · 2 comments
Milestone
0.3.4

Comments

@jayvdb
Copy link
Collaborator

jayvdb commented Sep 25, 2015

https://travis-ci.org/menegazzo/travispy/jobs/81966568

$ coverage run --source=travispy setup.py test
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.2.5/bin/coverage", line 9, in <module>
    load_entry_point('coverage==4.0', 'console_scripts', 'coverage')()
  File "/home/travis/virtualenv/python3.2.5/lib/python3.2/site-packages/pkg_resources/__init__.py", line 519, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/home/travis/virtualenv/python3.2.5/lib/python3.2/site-packages/pkg_resources/__init__.py", line 2630, in load_entry_point
    return ep.load()
  File "/home/travis/virtualenv/python3.2.5/lib/python3.2/site-packages/pkg_resources/__init__.py", line 2310, in load
    return self.resolve()
  File "/home/travis/virtualenv/python3.2.5/lib/python3.2/site-packages/pkg_resources/__init__.py", line 2316, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/home/travis/virtualenv/python3.2.5/lib/python3.2/site-packages/coverage/__init__.py", line 13, in <module>
    from coverage.control import Coverage, process_startup
  File "/home/travis/virtualenv/python3.2.5/lib/python3.2/site-packages/coverage/control.py", line 14, in <module>
    from coverage.annotate import AnnotateReporter
  File "/home/travis/virtualenv/python3.2.5/lib/python3.2/site-packages/coverage/annotate.py", line 81
    dest.write(u'  ')
                   ^
SyntaxError: invalid syntax

https://pypi.python.org/pypi/coverage/4.0 omits support for 3.0-3.2.

So either travispy drops support for Python 3.2, or uses coverage 3.7.1 on Python 3.2 ( https://pypi.python.org/pypi/coverage/3.7.1 ).
@jayvdb jayvdb mentioned this issue Sep 25, 2015
Merged
@menegazzo menegazzo modified the milestone: 0.3.4 Sep 30, 2015
iMichka added a commit to CastXML/pygccxml that referenced this issue Oct 20, 2015
@iMichka
Coverage 4.0 is broken with Python 3.2. Use an older version for travis
e0babd4 
Re-enable the combine step

See: menegazzo/travispy#20
@laco laco mentioned this issue Oct 21, 2015
Merged
lambdalisue added a commit to jazzband/django-permission that referenced this issue Oct 29, 2015
@lambdalisue
Drop travis testing on Python 3.2
7a2fcf1 
menegazzo/travispy#20
nlevitt added a commit to nlevitt/surt that referenced this issue Oct 29, 2015
@nlevitt
remove python 3.2 test which fails due to menegazzo/travispy#20
f1aac72
@T045T T045T mentioned this issue Nov 3, 2015
Merged
@daf daf mentioned this issue Nov 13, 2015
Closed
AdamWill added a commit to AdamWill/responses that referenced this issue Jan 22, 2016
@AdamWill
don't pin coverage to < 4.0.0, stop testing py3.2 (getsentry#95)
606a05f 
So the coverage dep was pinned to < 4.0.0 because of an issue
between coverage and Python 3.2 (py3.2 doesn't accept the
u'' syntax). This is fairly well-known, it seems, and the
standard response is simply to drop Python 3.2 testing:

geopython/OWSLib#291
menegazzo/travispy#20

ipython dropped Python 3.2 support for the same reason:

https://stackoverflow.com/questions/28724785

so I think this is a sensible choice here too. It's not
workable to pin coverage to an old and unsupported release
indefinitely, and causes problems for downstreams which
include coverage 4.x.
liam-m added a commit to liam-m/primes.py that referenced this issue Jan 28, 2016
@liam-m
Remove 3.2
a05220b 
Not compatible with the latest version of `coverage` - menegazzo/travispy#20. Standard is just to remove 3.2 testing
@jqnatividad jqnatividad mentioned this issue Feb 25, 2016
Closed
@aparrish aparrish mentioned this issue Mar 13, 2016
Merged
evandempsey added a commit to evandempsey/porter2-stemmer that referenced this issue Apr 1, 2016
@evandempsey
Syntax error in coverage library menegazzo/travispy#20. Removed 3.2 f…
f9a7292 
…rom tox.ini.
qsmits added a commit to qsmits/smeterd that referenced this issue May 30, 2016
@qsmits
Remove testing of Python 3.2
ec76ca0 
menegazzo/travispy#20
@bhgomes
Copy link

bhgomes commented Jul 4, 2016

has this been fixed?

@jayvdb
Copy link
Collaborator Author

jayvdb commented Jul 5, 2016

coverage has no intention of fixing their current code to be py32 compatible.
travispy could support py32, if someone has an app that needs it.

agschwender added a commit to agschwender/pilbox that referenced this issue Jul 16, 2016
@agschwender
Update travis config for coverage incompatibility
51aa14c 
coverage is incompatible with py32. See
menegazzo/travispy#20 for details.
@mtwtkman mtwtkman mentioned this issue Nov 29, 2016
Merged
xgouchet added a commit to xgouchet/AutoMergeTool that referenced this issue Dec 20, 2016
@xgouchet
Travis update
1aab7b5 
 - Remove test on Python 3.2 (coverage issue, see
menegazzo/travispy#20)
 - Add build image on Readme
rrzaripov added a commit to rrzaripov/watchdog that referenced this issue Sep 18, 2018
@rrzaripov
See menegazzo/travispy#20
0f9fc84
@Harumaro Harumaro mentioned this issue Apr 1, 2019
Open
btbrand added a commit to btbrand/responses that referenced this issue Apr 22, 2024
@btbrand
don't pin coverage to < 4.0.0, stop testing py3.2 (#95)
551f9a5 
So the coverage dep was pinned to < 4.0.0 because of an issue
between coverage and Python 3.2 (py3.2 doesn't accept the
u'' syntax). This is fairly well-known, it seems, and the
standard response is simply to drop Python 3.2 testing:

geopython/OWSLib#291
menegazzo/travispy#20

ipython dropped Python 3.2 support for the same reason:

https://stackoverflow.com/questions/28724785

so I think this is a sensible choice here too. It's not
workable to pin coverage to an old and unsupported release
indefinitely, and causes problems for downstreams which
include coverage 4.x.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.3.4
Development

No branches or pull requests
3 participants
@jayvdb @menegazzo @bhgomes