I'm using versioneer to manage versions, ala PEP 440.
I have uploaded a few versions to a private repository:
0.0.1
0.0.2
0.0.2+0.0.2+18.g5a127f2.dirty
My problem is that now when I use
pip install mypackage==0.0.2
I get version 0.0.2+0.0.2+18.g5a127f2.dirty when I expected to get 0.0.2.
Is there a way to have have pip ignore the "local version" and just install the exact version, without me having to upload to different indices (ie. staging and stable)?
Edit:
I have tried using the --no-cache-dir and -I flags, but the issue persists; pip is preferring the 0.0.2+ version to the 0.0.2 version.
Additional Edit:
I'm using pip 18.0 and Python 2.7
According to distutils:
Following a release number, you can have either a pre-release or post-release tag. Pre-release tags make a version be considered older than the version they are appended to. So, revision 2.4 is newer than revision 2.4c1, which in turn is newer than 2.4b1 or 2.4a1. Postrelease tags make a version be considered newer than the version they are appended to. So, revisions like 2.4-1 and 2.4pl3 are newer than 2.4, but are older than 2.4.1 (which has a higher release number).
So, while not the solution I'm looking for (full answer below) it looks like this works:
pip install "mypackage<=0.0.2"
The distutils blurb about post-releases seems to go against what is specified in PEP440
[Examples: ...] == 3.1: specifically version 3.1 (or 3.1.0), excludes all pre-releases, post releases, developmental releases and any 3.1.x maintenance releases.
...but I'm still a little fuzzy on how it's determined whether something is a "post" or "pre" release.
Nevertheless, the answer to my problem appears to be: use Aribitrary Equality:
pip install mypackage===0.0.2
This gives me exactly the version specified, ignoring versions with any pre/post/dev details.
Related
I Have a package published on pypi and versioned as 3.0.0.
setup.py has never mentioned python_requires directive.
In release 2.5.0 there was a change which made package to be incompatible with python 2, which went unnoticed, until now.
Since 2.5.0 there were a plenty of releases of a package published on pypi.
Now, if I want to install the package using python2 - pip will install the latest release 3.0.0 which won't work.
I need pip to install version 2.4.0 - which has no compatibility issues. But how exactly can I accomplish that? (without prior knowledge of pip install package==2.4.0 - something like using pip's backtracking mechanism)
If I specify the directive python_requires=">=3.6" in release 3.1.0 pip will backtrack to release 3.0.0 installing package which won't work.
I can think of:
cx_Oracle way. Raising exception in setup.py if minimal version does not match required for installation and specifying how to install correct one.
Create 2 new releases. One, which is essentialy 2.4.0 versioned as 3.1.0 with python_requires=">=2.7,<3.6" and one which is 3.0.0 versioned as 3.1.1 with python_requires=">=3.6"
Is there a better way?
There is a relatively new feature on PyPI: you could "yank" the release(s) which are incompatible with Python 2 but not correctly specifying that in the metadata.
A yanked release is a release that is always ignored by an installer, unless it is the only release that matches a version specifier (using either == or ===).
See PEP 592 -- Adding "Yank" Support to the Simple API for more information. In fact, what you've described is the main scenario described in the motivation section of the PEP.
I was trying to upgrade to the latest version of a package I had installed with pip, but for some reason it won't get the latest version. I've tried uninstalling the package in question, or even reinstalling pip entirely, but it still refuses to get the latest version from PyPI. When I try to pin the package version (e.g. pip install package==0.10.0) it says that it "Could not find a version that satisfies the requirement package==0.10.0 (from versions: ...)"
pip search package even acknowledges that the installed version isn't the latest, labeling the two versions for me.
I've seen other questions with external files or local versions, but I've tried the respective solutions (--allow-external doesn't exist anymore, and --no-cache-dir doesn't help) and I'm still stuck on the older version.
I was trying to upgrade Quart. Maybe other packages have something else going on.
In this particular case, Quart had dropped support for Python 3.6 (the version I had installed) and only supported 3.7 or later. (This was a fairly recent change to the project, so I just didn't see the news.)
However, when attempting to install a package only supported by a later Python, pip doesn't really explain why it couldn't find a version to satisfy the requirement - instead, it just lists all the versions that should work with the current Python, without indicating that more exist and just can't be installed.
The only real options to fix are:
Update your Python to meet the package's requirements
Ask/help the maintainer to backport the package to the version you have.
Every time pip is installed, the version is always 9.0.1 and there's this rather annoying DEPRECRATION warning about columns. Why not just ship 19 or some newer version?
[EDIT]
NOTE: My question is not HOW to install the latest version.
My question is WHY doing sudo apt install python3-pip simply doesn't come with pip-19 or some version greater than 9.
Because if I remember correctly, updating the system wide pip causes unwanted side effects. Updating pip should only be done in a virtual environment. Now how will a normal end-user know how to avoid that?
Because each distribution is versioned. 10 major versions of pip have been released since you version of Python was. Only to follow pip, it would have required 10 new minor (or even patch) versions of Python.
Packaging and distributing a new version requires a good deal of work which here was just found non necessary, because the end users:
are warned that a more recent version is available
can easily download and install it.
Long story short: the general opinion among core Python developpers seem to have been that following pip version just was not worth it.
I have trouble installing my project which depends on Colorama.
In the setup.py, I specified:
'colorama ~= 0.3'
But I’m surprised to see that the version 0.4 is installed (this version is new).
How to reproduce?
Create and activate a virtualenv and run:
pip install colorama~=0.3
And then look at the logs or run:
pip list
What’s wrong with the ~= operator?
note: I'm using pip v18.1 and setuptools v40.4.3
The operator ~= means "compatible release". When using semantic versioning a compatible version is such that the first number in the sequence is the same (number 0 in this case).
From the link above:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner,
and PATCH version when you make backwards-compatible bug fixes.
I have two versions of my python build:
16.1206.43542
17.0817.221945+f4cc396
The only really difference I can see is the ending metadata. When I run pip install package, the version 16.1206.43542 is installed and not the latest. Is this the proper behavior? I would have thought pip would have honored the metadata, and installed the later package?
Thoughts? Ideas? Any would be welcomed. For transparency, I am adding the sha from a git build into the version.
I looked at this, and found that the correct answer is that anything following the normal Semantic Versioning, it labels that build as a pre-release build and must then be explicitly called to be installed, normally identified with a '-'. https://semver.org/ (Topic 9)
For pip install The version must be a NON pre-release build to be automatically installed.