Pytest: pip install pytest fails - Mo matching found for py>=1.5.0 for python3.3
I'm using a tox environment and all of its tests pass in Python 2.7,3.4-6 except for in Python 3.3. It just started happening last night and persisted into this morning, both on my Linux environment locally and also remotely
Here is the log for when I try to run
python3.3 -m pip install pytest
Collecting pytest
Using cached pytest-3.3.0-py2.py3-none-any.whl
Requirement already satisfied: setuptools in /usr/local/lib/python3.3/dist-packages (from pytest)
Collecting attrs>=17.2.0 (from pytest)
Using cached attrs-17.3.0-py2.py3-none-any.whl
Collecting pluggy<0.7,>=0.5 (from pytest)
Downloading pluggy-0.5.2.tar.gz
Collecting py>=1.5.0 (from pytest)
Could not find a version that satisfies the requirement py>=1.5.0 (from pytest) (from versions: 0.9.1, 0.9.2, 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.3.0, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7.dev3, 1.4.7, 1.4.8, 1.4.9, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 1.4.14, 1.4.15, 1.4.16, 1.4.17, 1.4.18, 1.4.19, 1.4.20, 1.4.21, 1.4.22, 1.4.23, 1.4.24, 1.4.25, 1.4.26, 1.4.27, 1.4.28, 1.4.29, 1.4.30, 1.4.31, 1.4.32, 1.4.33, 1.4.34)
No matching distribution found for py>=1.5.0 (from pytest)
Here's a report of the failing test remotely:
https://travis-ci.org/ColinKennedy/ways/jobs/308277578
That Travis-CI link refers to a log with more output. This pastebin link is that log: https://pastebin.com/rk8EUq0E
OS:
Ubuntu 16.04.2 LTS
I have a feeling this is simple user error on my part but it's hard to tell since I wiped my environment and am still getting the same error, locally and remotely. Any help would be greatly appreciated
ColinKennedy
All 49 comments
Support for Python 3.3 was dropped, see the changelog.
The-Compiler
on 28 Nov 2017
@ColinKennedy if you are using the latest pip it should not try to install pytest-3.3.0 on Python 3.3. Make sure to update pip on Travis first with pip install --upgrade pip before installing your requirements.
nicoddemus
on 28 Nov 2017
It looks like the metadata did not get published correctly when pytest 3.3.0 was uploaded. Compare py 1.5.2, which has 'Requires Python' metadata on the page, with pytest 3.3.0, which does not.
Unfortunately, this means that installing pytest fails on Python 3.3 rather than automatically falling back to an older version.
takluyver
on 30 Nov 2017
it seems the wheel metadata is incorrect
RonnyPfannschmidt
on 30 Nov 2017
Unfortunately, the only way I can think of to fix this is to make a new release of pytest which can be installed on Python 3.3, and has a version number higher than 3.3.0.
Otherwise, it might get fixed in pip if it gets a proper dependency resolver - that was a GSoC project this year, but I haven't heard much about it.
takluyver
on 30 Nov 2017
I used the automatic procedure detailed in HOWTORELEASE to generate and upload the package, what could have caused the missing header? An old pip or wheel version installed in the virtual environment I used?
nicoddemus
on 30 Nov 2017
@nicoddemus pip cant cause it - wheel looked recent, perhaps setuptools?
RonnyPfannschmidt
on 30 Nov 2017
I will verify the actual versions when I get home to see if they were the cause.
nicoddemus
on 30 Nov 2017
wheel, setuptools or maybe twine (if you're using that).
takluyver
on 30 Nov 2017
Here's the pip list of the virtual environment I used:
Package Version Location
------------------- ------------------------------- --------------------
apipkg 1.4
argon2-cffi 16.3.0
attrs 17.3.0
beautifulsoup4 4.6.0
bleach 2.0.0
certifi 2017.7.27.1
cffi 1.10.0
Chameleon 3.1
chardet 3.0.4
check-manifest 0.35
click 6.7
coverage 4.4.2
defusedxml 0.5.0
devpi 2.2.0
devpi-client 3.0.0
devpi-common 3.1.0
devpi-server 4.3.0
devpi-web 3.2.0
docutils 0.14
execnet 1.4.1
gitdb2 2.0.2
GitPython 2.1.5
html5lib 0.999999999
hupper 1.0
hypothesis 3.37.0
idna 2.5
incremental 17.5.0
invoke 0.20.4
itsdangerous 0.24
Jinja2 2.9.6
MarkupSafe 1.0
passlib 1.7.1
PasteDeploy 1.5.2
pip 9.0.1
pkginfo 1.4.1
plaster 0.5
plaster-pastedeploy 0.4.1
pluggy 0.4.0
py 1.5.0
pycparser 2.18
Pygments 2.2.0
pyramid 1.9.1
pyramid-chameleon 0.3
pytest 3.2.6.dev217+ge97c774.d20171123 /home/vagrant/pytest
readme-renderer 17.2
regendoc 0.6.1
repoze.lru 0.6
requests 2.18.3
requests-toolbelt 0.8.0
setuptools 36.2.7
six 1.10.0
smmap2 2.0.3
toml 0.9.2
towncrier 17.8.0
tox 2.8.1
tqdm 4.15.0
translationstring 1.3
twine 1.9.1
urllib3 1.22
venusian 1.1.0
virtualenv 15.1.0
waitress 1.0.2
webencodings 0.5.1
WebOb 1.7.3
wheel 0.29.0
Whoosh 2.7.4
zope.deprecation 4.3.0
zope.interface 4.4.2
Now with --outdated:
Package Version Latest Type Location
------------------- ------------------------------- --------- ----- --------------------
bleach 2.0.0 2.1.1 wheel
certifi 2017.7.27.1 2017.11.5 wheel
cffi 1.10.0 1.11.2 wheel
Chameleon 3.1 3.2 sdist
check-manifest 0.35 0.36 wheel
devpi-client 3.0.0 3.1.0 wheel
devpi-common 3.1.0 3.2.0 wheel
devpi-server 4.3.0 4.3.1 wheel
devpi-web 3.2.0 3.2.1 wheel
execnet 1.4.1 1.5.0 wheel
gitdb2 2.0.2 2.0.3 wheel
GitPython 2.1.5 2.1.7 wheel
hypothesis 3.37.0 3.38.9 wheel
idna 2.5 2.6 wheel
invoke 0.20.4 0.22.0 wheel
Jinja2 2.9.6 2.10 wheel
plaster 0.5 1.0 wheel
plaster-pastedeploy 0.4.1 0.4.2 wheel
pluggy 0.4.0 0.6.0 sdist
py 1.5.0 1.5.2 wheel
pytest 3.2.6.dev217+ge97c774.d20171123 3.3.0 wheel /home/vagrant/pytest
repoze.lru 0.6 0.7 wheel
requests 2.18.3 2.18.4 wheel
setuptools 36.2.7 38.2.3 wheel
six 1.10.0 1.11.0 wheel
toml 0.9.2 0.9.3.1 sdist
tox 2.8.1 2.9.1 wheel
tqdm 4.15.0 4.19.4 wheel
waitress 1.0.2 1.1.0 wheel
WebOb 1.7.3 1.7.4 wheel
wheel 0.29.0 0.30.0 wheel
zope.interface 4.4.2 4.4.3 wheel
Look at this file, I see that pytest releases are made through devpi. I've never used that; maybe it doesn't propagate the 'Requires-Python' metadata to PyPI.
takluyver
on 1 Dec 2017
@takluyver the metadata is taken from the wheel, and the wheel doesnt contain it
RonnyPfannschmidt
on 1 Dec 2017
Unfortunately, the only way I can think of to fix this is to make a new release of pytest which can be installed on Python 3.3, and has a version number higher than 3.3.0.
Or alternatively, publish a new release 3.3.1 that has the proper metadata and pull 3.3.0 from PyPI any distributions that are missing the metadata (wheel only apparently).
jaraco
on 4 Dec 2017
I think you would have to delete 3.3.0 entirely, both wheel and sdist, to solve the problem that way.
In the simple index, pip is looking for a data-requires-python attribute. You can see that no distributions currently have that (compare py). I think that the metadata from the first distribution to be uploaded is applied to that release as a whole.
takluyver
on 4 Dec 2017
I dare say this issue is a critical one. Some projects have adapted by dropping support for Python 2.6 and 3.3. Others may have worked around it by pinning to older versions of pytest, which isn't a sustainable approach, especially when the metadata provides a better mechanism for filtering releases based on supported Pythons. I don't have access to manage pytest releases myself, or I'd help directly.
Is there any reason not to immediately cut a 3.3.1 from 3.3.0 and remove 3.3.0 from PyPI?
And to prevent the resurgence of this issue, I suggest that releases should be cut mechanically using infrastructure resources like Travis CI to cut releases in a well-defined and visible environment. I've applied this approach in all of the projects I maintain and I'd be happy to help set that up for pytest too.
jaraco
on 6 Dec 2017
@jaraco main blocker for this currently is the lack of commit/push automation in combination with regendoc/towncrier - else we could just use the combination of setuptools_scm and automate the uploads from travis
RonnyPfannschmidt
on 6 Dec 2017
pytest 3.3.1 was released and has the same issue, so that's another version that's going to need to be pulled to address this issue.
jaraco
on 6 Dec 2017
Hi @jaraco!
Is there any reason not to immediately cut a 3.3.1 from 3.3.0 and remove 3.3.0 from PyPI?
We just released 3.3.1 yesterday with the correct metadata. đ If we all agree we should remove 3.3.0 from PyPI, let's do it then, I'm not 100% certain this is a good approach because I read somewhere online that you ideally should never drop a release from PyPI, but I remember the alternative was to just push a new release to solve the issue which is not possible in our case.
And to prevent the resurgence of this issue, I suggest that releases should be cut mechanically using infrastructure resources like Travis CI to cut releases in a well-defined and visible environment. I've applied this approach in all of the projects I maintain and I'd be happy to help set that up for pytest too.
@RonnyPfannschmidt I think @jaraco's point here is that the package generation should be done in a controlled environment, not necessarily the entire process be automated. If that's the suggestion, I think we could just push tags to an approved "release PR" (#2997) and the package generation/publication could be done from Travis.
Besides the technical issues to address, there's some resistance from @hpk42 and @obestwalter (IIRC) about automating releases like this; they prefer some manual checking first.
Particularly I'm a big fan of the "push-tag-to-release" workflow. :)
nicoddemus
on 6 Dec 2017
pytest 3.3.1 was released and has the same issue, so that's another version that's going to need to be pulled to address this issue.
Are you sure? I verified the package myself (both wheel and .tar.gz) and they did contain the "Python Requires" metadata. đŽ
nicoddemus
on 6 Dec 2017
Are you sure?
I'm not certain, but I don't see the Requires-Python in the metadata listing for pytest
Whereas I do see it for py.
jaraco
on 6 Dec 2017
@nicoddemus how did you upload them?
@jaraco when the wheel is uploaded as second file, pypi skips the data, also twine seems to be required
in the actual wheel the data is present this time
RonnyPfannschmidt
on 6 Dec 2017
Just verified again:
PKG-INFO in tar.gz has Requires-Python: >=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*
pytest-3.3.1.dist-info/METADATA in the wheel also has this string
nicoddemus
on 6 Dec 2017
pytest releases are made through devpi
Is it possible that this release flow is implicated, and that py doesn't use this flow?
jaraco
on 6 Dec 2017
@RonnyPfannschmidt using devpi, according to our automated tasks.
Having the Requires-Python meta-data on the package is not sufficient?
Is it possible that this release flow is implicated, and that py doesn't use this flow?
I'm pretty sure py was uploaded using twine.
nicoddemus
on 6 Dec 2017
@nicoddemus then i believe its a devpi bug and we need it fixed and have @hpk42 deploy a new version of devpi
by now i want to see devpi gone from the release process
RonnyPfannschmidt
on 6 Dec 2017
Is the metadata updated in PyPI by the register step, instead of read from each package after they are uploaded?
nicoddemus
on 6 Dec 2017
The definitive thing to check is the 'simple index' page: https://pypi.python.org/simple/pytest/ . View the source of that and search for data-requires-python. That's what pip looks for. So far, no pytest release has it.
The register step is no longer necessary or even possible, but the HTTP request that uploads a package includes some metadata. I guess that this metadata is what PyPI is using, and I guess the devpi doesn't send the requires_python field.
takluyver
on 6 Dec 2017
Here's the method which uploads the file using devpi upload:
nicoddemus
on 6 Dec 2017
I'm beginning to wonder if twine is actually required for this metadata to be present. Looking at the register command, it doesn't seem to have support for PEP 345 metadata (though I'm not sure that's where the metadata needs to be for PyPI to honor it).
jaraco
on 6 Dec 2017
@nicoddemus That code looks like it sends the correct metadata, but I don't know if the devpi server preserves it and sends it on to PyPI when you devpi push it.
takluyver
on 6 Dec 2017
@takluyver that seems possible, thanks for looking into it
nicoddemus
on 6 Dec 2017
Just realized another disadvantage about dropping 3.3.0 and 3.3.1 from PyPI: that would break frozen "requirements.txt" of people that pin to those packages for deployment. âšī¸
nicoddemus
on 7 Dec 2017
Yes, it's disruptive... and the longer 3.3.0/1 is out there, the more the disruption. I suggest that 3.3.2 should be released for as long as 3.3.0 was released with a warning that those versions go away, then they go away.
jaraco
on 7 Dec 2017
Alternatively, maybe we can ask PyPI if we can hack into their DB and update the metadata for those packages.
jaraco
on 7 Dec 2017
A thought: would it be possible for people still supporting Python 2.6 and 3.3 to conditionally pin their tox.ini or requirements based on Python version? I ask because we did it for some time because mock dropped Python 2.6 support in mock 1.1:
https://github.com/pytest-dev/pytest/blob/a220a40350a8a81c0f0e1986aa184e4c33da29d6/tox.ini#L30-L36
nicoddemus
on 7 Dec 2017
I think one issue here is that it's not possible to update metadata on packages on PyPI anymore. Before one was able to fix the Readme or other stuff via the "register" call. That is now gone. I'm pretty sure nobody wants to put that back for PyPI and instead wants to get warehouse out and fix it there. So I think it would be reasonable to ask the to fix it in the Database for 3.3.0 and 3.3.1. In the meantime, I'm looking into the devpi push issue https://github.com/devpi/devpi/issues/480
fschulze
on 8 Dec 2017
Was something fixed on PyPI? The new pytest is now blocked on older PyPy3 https://travis-ci.org/fschulze/devpi/jobs/313430195
fschulze
on 8 Dec 2017
Doh, I misunderstood. With the correct metadata it should use the older release.
fschulze
on 8 Dec 2017
I updated devpi.net with a pre-release. I made a test upload of pytest at https://devpi.net/fschulze/dev/pytest/3.3.1 and it now has the metadata.
fschulze
on 10 Dec 2017
Besides the technical issues to address, there's some resistance from @hpk42 and @obestwalter (IIRC) about automating releases like this; they prefer some manual checking first.
No resistance from me, really. the more automatic a release is, the less one can do wrong :) togetherwith pre-releases that would actually be my ideal scenario.
obestwalter
on 15 Dec 2017
Alternatively, maybe we can ask PyPI if we can hack into their DB and update the metadata for those packages.
So I think it would be reasonable to ask the to fix it in the Database for 3.3.0 and 3.3.1.
That would be ideal solution: it will fix those releases without changing the actual package, and we won't risk further disruption for users using supported Python versions.
Do you guys know who we can contact regarding this request? @dstufft?
nicoddemus
on 22 Dec 2017
Judging from https://pypi.org/help/ the warehouse issue tracker may be a good place. https://github.com/pypa/warehouse/issues
fschulze
on 22 Dec 2017
Thanks @fschulze! Opened up pypa/warehouse#2700.
nicoddemus
on 23 Dec 2017
@nicoddemus so what do we do about the bad uploads - they break the builds and by now pulling will break pinned builds
RonnyPfannschmidt
on 24 Dec 2017
The warehouse guys seem to be happy to help us out, so we should go with
that solution.
Em dom, 24 de dez de 2017 08:32, Ronny Pfannschmidt <
[email protected]> escreveu:
@nicoddemus https://github.com/nicoddemus so what do we do about the
bad uploads - they break the builds and by now pulling will break pinned
buildsâ
You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub
https://github.com/pytest-dev/pytest/issues/2966#issuecomment-353777208,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABCO_InoXUlrr-nwKKUf7Z_9eW0faYyZks5tDihRgaJpZM4QtzSl
.
nicoddemus
on 24 Dec 2017
3.3.2 is out, we should be good as soon as @ewdurbin gets a chance to update the metadata. đ
nicoddemus
on 4 Jan 2018
Thanks to the awesome help from @ewdurbin the metadata is now fixed for 3.3.0 and 3.3.1! đ
nicoddemus
on 5 Jan 2018
Thanks for all the hard work on this one.
jaraco
on 5 Jan 2018
Just verified again:
PKG-INFOintar.gzhasRequires-Python: >=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*
pytest-3.3.1.dist-info/METADATAin the wheel also has this string
metadata is missing
chinu23081994
on 22 Jan 2019
Related issues
jacquerie
¡
3Comments
pombredanne
¡
3Comments
RonnyPfannschmidt
¡
3Comments
jtmoon79
¡
3Comments
TomNicholas
¡
3Comments