pip interprets Matplotlib dev version as stable · Issue #7962 · matplotlib/matplotlib · GitHub

I just noticed that, when I offer pip a directory containing a development version of matplotlib, it will install it, even though I do not use the --pre flag. For example this directory:

https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com/

contains uploaded development versions of matplotlib, e.g.

https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com/matplotlib-2.0.0+3158.g7b79174-cp27-cp27mu-manylinux1_x86_64.whl#sha256=643db393739b13ac93f6519a1dff8af41585dd5462a363f6aa1a923a68b783c1

If I do:

pip install --find-links=https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com matplotlib

I get:

Collecting matplotlib
  Downloading https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com/matplotlib-2.0.0+3158.g7b79174-cp27-cp27mu-manylinux1_x86_64.whl (14.3MB)

I think this is because pip is interpreting the +3158.g7b79174 as irrelevant version decoration, and therefore thinks the real version is 2.0.0, and that this is a stable version.

Something seems to be going wrong with versioner / wheel building. The version should look like

In [3]: matplotlib.__version__
Out[3]: '2.0.0.post3158+g7b79174fb'

In [4]:

What wheel filename do you get for pip wheel . ? I don't get the post suffix, building from a standard matplotlib repo clone.

I get the same effect without pip: python setup.py sdist gives dist/matplotlib-2.0.0+3160.geaf05e9.tar.gz.

"post", even if present, does not make the version a prerelease. We need to add "dev" to the version string. (See https://github.com/pypa/pip/blob/403e398330c8e841e4633aceda859430f5f7b913/pip/_vendor/packaging/version.py#L290).
This can be done using versioneer's pep440-pre style (https://github.com/warner/python-versioneer/blob/a24a1562b0faa2a2d10ee044ae8eda9298fd2ad8/details.md#how-do-i-select-a-version-style)... which needs to be set in setup.cfg, but then we need to decide how to handle setup.cfg.template.

Additionally, my guess is that if we do such a switch, then installing from source may(?) also require passing --pre.

Moving to the pre-release version (and telegraphing what the next release will be) seems like a reasonable thing to do.

We currently use a hacked version of versioneer to avoid using setup.cfg, presumable we could update versioneer and then re-apply that hack.

"pep440-pre" doesn't include info about next version so that's fine.

FWIW I have now switched my personal projects to use https://github.com/pypa/setuptools_scm instead of versioneer:

development on versioneer (sadly) seems to have stalled
setuptools_scm is installed as its own library, instead of having to check in a large generated file in the repository; this allows normal update paths.
setuptools_scm generates version ids that do not suffer from the problem described here (I like post-release+node-and-date version ids).
for mpl specifically: configuration happens in setup.py/__init__.py, so no need to hack around setup.cfg.

Last time I checked, setuptools_scm interacted poorly with setupext.py trying to use multiprocessing -- which I get rid of in #9795.

does setuptools_scm work if you download the zip / tarball directly from github (or use git archive?). I assume it handles sdist correctly.

sdists are of course handled correctly.
git archives can be handled via https://pypi.python.org/pypi/setuptools_scm_git_archive which tbh I haven't tried but seems straightforward (basically replicating versioneer's approach of using git export-subst).
github tarballs are not generated using git archive and are thus not supported (there is no hook via which setuptools_scm could write the version). However, it is possible to conditionally set the SETUPTOOLS_SCM_PRETEND_VERSION env var to override the issue (which is not really worse that the situation with versioneer, which installs the package as version 0+unknown).

The release tarballs do use git export (which you can verify via sha256 see https://matplotlib.org/devdocs/devel/release_guide.html#id2 and which leads to choas with conda if you are pointing at a tag and there is a branch sitting on that tag).

Any reason not to use sdist instead? It sort of connects back to #9735; a priori I'd have thought that sdist is exactly there for that purpose.

What we push to pypi is from sdist, but the source links on https://github.com/matplotlib/matplotlib/releases are auto-generated.

You can attach binaries, but I am not sure if they can hide the auto generated ones and even if they could, I am not sure we would want to.

Setting SETUPTOOLS_SCM_PRETEND_VERSION from setup.py should be enough to cover this case.

Should be fixed by switching to setuptools-scm in #18971.

pip interprets Matplotlib dev version as stable · Issue #7962 · matplotlib/matplotlib · GitHub

Repository navigation

pip interprets Matplotlib dev version as stable #7962

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

pip interprets Matplotlib dev version as stable · Issue #7962 · matplotlib/matplotlib · GitHub

Repository navigation

pip interprets Matplotlib dev version as stable #7962

Description

Activity

tacaswell commented on Jan 27, 2017

matthew-brett commented on Jan 27, 2017

matthew-brett commented on Jan 27, 2017

anntzer commented on May 13, 2017

tacaswell commented on May 13, 2017

anntzer commented on May 13, 2017

4 remaining items

anntzer commented on Dec 22, 2017

tacaswell commented on Dec 22, 2017

anntzer commented on Dec 22, 2017

tacaswell commented on Dec 22, 2017

anntzer commented on Dec 22, 2017

tacaswell commented on Dec 22, 2017

anntzer commented on Dec 22, 2017

QuLogic commented on Apr 2, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions