I am developing a python library that I wish to distribute afterwards. In order to do this I am configuring setuptools. Currently I am testing all this in a fresh install of Ubuntu 18.0.4.2 after doing an update & upgrade.
The problem is that my setup.py looks like this (I defined the oldest available package):
setup(
...
install_requires=[
'setuptools>=40.0.0',
'matplotlib>=1.0.1',
'numpy>=1.3.0',
'scipy>=0.8.0',
],
...
)
and when I install my package from test.pypi I get this error with matplotlib:
Collecting LIB_TEST_NEW
Using cached https://test-files.pythonhosted.org/packages/e6/6a/d3f7569c437b70e4c048e8597977c3d42e9baa1151c0245f210cb6e529f1/LIB_TEST_NEW-0.1.2-py3-none-any.whl
Collecting matplotlib>=1.0.1 (from LIB_TEST_NEW)
Could not find a version that satisfies the requirement matplotlib>=1.0.1 (from LIB_TEST_NEW) (from versions: )
No matching distribution found for matplotlib>=1.0.1 (from LIB_TEST_NEW)
I have tried both with and without specifying the version of the modules and also defining the modules in a separate requirements.txt.
Any help would be appreciated :)
SOLUTION:
After some digging I found a solution.
"If you want to allow pip to also pull other packages from PyPI you can specify --extra-index-url to point to PyPI. This is useful when the package you’re testing has dependencies:"
Then using:
pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple your-package
Solved my error. Hope it helps someone.
Related
I'm working on my first python package, so I'm new with all this.
I have my own setup package which I install through pip install git+<URL>.git.
When I try to upgrade it with the --upgrade flag, it always get reinstalled, even if I haven't changed the version in my setup.py file.
Does anyone know why this is happening? o maybe have a better approach to this?
I have made my research before asking, but I think this is a very specific problem.
I have tried in a venv and out.
python 3.7, pip 19.2, setuptools 40.8
# setup.py
from test import __version__
from setuptools import find_packages, setup
setup(
name="test",
version=__version__,
packages=find_packages(),
)
I expect to get something similar to:
Requirement already up-to-date: test in ./<cwd>/.venv/lib/python3.7/site-packages (0.0.1)
but instead I get this:
Installing collected packages: test
Found existing installation: test 0.0.1
Uninstalling test-0.0.1:
Successfully uninstalled test-0.0.1
Running setup.py install for test ... done
Successfully installed test-0.0.1
Reading the documentation it seems like the expected behaviour to me.
Note that if a satisfactory version of the package is already installed, the VCS source will not overwrite it without an --upgrade flag.
Read a somewhat related discussion here:
https://github.com/pypa/pip/issues/2837
Looks like pip does upgrades in a much more binary fashion when VCS is involved. It seems to always upgrade when --upgrade is set and never when it's not set.
You could try the work-around that is suggested in this discussion, but be aware of its side effects (for example, you will have a full clone of the git repository on your file system):
pip install --editable --upgrade git://somewhere/something.git
I have the following two dependencies in my requirements.txt:
$ pip3 install elasticsearch==7.0.0 requests==2.21.0
Collecting elasticsearch==7.0.0
Using cached https://files.pythonhosted.org/packages/a8/27/d3a9ecd9f8f972d99da98672d4766b9f62ef64c323c40bb5e2557e538ea3/elasticsearch-7.0.0-py2.py3-none-any.whl
Collecting requests==2.21.0
Using cached https://files.pythonhosted.org/packages/7d/e3/20f3d364d6c8e5d2353c72a67778eb189176f08e873c9900e10c0287b84b/requests-2.21.0-py2.py3-none-any.whl
Collecting urllib3>=1.21.1 (from elasticsearch==7.0.0)
Using cached https://files.pythonhosted.org/packages/39/ec/d93dfc69617a028915df914339ef66936ea976ef24fa62940fd86ba0326e/urllib3-1.25.2-py2.py3-none-any.whl
Collecting certifi>=2017.4.17 (from requests==2.21.0)
Using cached https://files.pythonhosted.org/packages/60/75/f692a584e85b7eaba0e03827b3d51f45f571c2e793dd731e598828d380aa/certifi-2019.3.9-py2.py3-none-any.whl
Collecting chardet<3.1.0,>=3.0.2 (from requests==2.21.0)
Using cached https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e4274b6487b4bb1ddec7ca55ec7510b22e4c51f14098443b8/chardet-3.0.4-py2.py3-none-any.whl
Collecting idna<2.9,>=2.5 (from requests==2.21.0)
Using cached https://files.pythonhosted.org/packages/14/2c/cd551d81dbe15200be1cf41cd03869a46fe7226e7450af7a6545bfc474c9/idna-2.8-py2.py3-none-any.whl
requests 2.21.0 has requirement urllib3<1.25,>=1.21.1, but you'll have urllib3 1.25.2 which is incompatible.
Installing collected packages: urllib3, elasticsearch, certifi, chardet, idna, requests
Successfully installed certifi-2019.3.9 chardet-3.0.4 elasticsearch-7.0.0 idna-2.8 requests-2.21.0 urllib3-1.25.2
I want to understand this warning that appeared in the above output:
requests 2.21.0 has requirement urllib3<1.25,>=1.21.1, but you'll have urllib3 1.25.2 which is incompatible.
Why did pip install urllib3 1.25.2? It does not seem to make sense. The required dependencies are:
elasticsearch==7.0.0 requires urllib3>=1.21.1 (source)
requests==2.21.0 requires urllib3>=1.21.1,<1.25 (source)
Both dependencies could have been easily satisfied by installing urllib3 1.24.3. Why did pip3 then install urllib3 1.25.2? Isn't deciding the correct version according to the available requirements one of its responsibility?
It this a bug in pip3 or is this functioning as designed?
Update on 10th of November 2020
Install beta version of pip, it will solve the dependencies correctly for you.
Or install latest stable and run pip install --use-feature=2020-resolver.
Original answer
As it is now, pip doesn’t have true dependency resolution, but instead simply uses the first specification it finds for a project.
You can add constraints.txt file with urllib3==1.24.3 and then invoke:
$ pip install -r requirements.txt -c contraints.txt
That would do the job. When updating requirements remember to update also contraints.
Alternatively you can use one of Python dependency managers:
Pipenv
Poetry
pip-tools
DepHell
See Requirements Files and Constraints Files sections in pip user guide and Managing Application Dependencies tutorial.
I’m new to python and I got some problem when trying to install QISKit.
First, I was using pip install qiskit on cmd, but it showed an error
numpy.distutils.system_info.NotFoundError: no lapack/blas resources found
I searched on internet and pip install scipy separately. It worked
Collecting scipy
Using cached scipy-1.0.0-cp36-none-win32.whl
Requirement already satisfied: numpy>=1.8.2 in
d:\programming\python\lib\site-packages (from scipy)
Installing collected packages: scipy
Successfully installed scipy-1.0.0
Then I tried pip install qiskit again. It showed an error:
Found existing installation: scipy 1.0.0
Uninstalling scipy-1.0.0:
Successfully uninstalled scipy-1.0.0
Running setup.py install for scipy ... error
……
numpy.distutils.system_info.NotFoundError: no lapack/blas resources found
----------------------------------------
Rolling back uninstall of scipy
So I used the second way:
git clone https://github.com/QISKit/qiskit-sdk-py
cd qiskit-sdk-py
then
pip install -r requirements.txt
again
Installing collected packages: scipy, sympy
Found existing installation: scipy 1.0.0
Uninstalling scipy-1.0.0:
Successfully uninstalled scipy-1.0.0
Running setup.py install for scipy ... error
……
numpy.distutils.system_info.NotFoundError: no lapack/blas resources found
----------------------------------------
Rolling back uninstall of scipy
how can I solve this and add QISKit to python lib?
reference:
https://github.com/QISKit/qiskit-sdk-py/blob/master/doc/install.rst#3.1-Setup-the-environment
Installing scipy, at least the version currently required by QISKit, on Windows requires that you have a couple of different compilers installed, which you probably don't. I recommend you install Anaconda. If you download the full Anaconda package, it includes the appropriate scipy binary, or alternatively you can do conda install scipy=0.19 before you do pip install qiskit.
I think that should fix your current issue but feel free to reach out with any others -- I'll be happy to help. You can also find more documentation at qiskit.org, github.com/QISKit/qiskit-sdk-py, and on the IBM Q experience community forums.
Cheers,
Doug
I have a python 3.4 virtualenv and trying to install sphinx in it rises an error:
$ pip install sphinx
Collecting sphinx
Using cached Sphinx-1.3.1-py2.py3-none-any.whl
Collecting alabaster<0.8,>=0.7 (from sphinx)
Using cached alabaster-0.7.4.tar.gz
setuptools must be installed to install from a source distribution
I'm currently using my distribution's sphinx but It makes me pollute my conf.py and can't really find packages in autodoc.
Is it a known issue? Any workaround?
This is not a solution, but when I faced the same problem, it was a lot faster to reinstall the virtual environment than trying to solve the issue (I tried updating pip, setuptools, etc). After setting up a new virtualenv, I had no problem installing or updating packages again.
i'm trying to install pydot in python3 and i came up with some questions:
The packages referenced by pip3.3 are the same referenced by pip2.7 or there is a different repository for the packages ?
How does all the packaging/distribution work in python ?
What should i do for installing pydot through pip ?
Actually the creator say that python3 is not supported, but pydot is listed in pip3.3
A fork of pydot (https://bitbucket.org/prologic/pydot) working on Python3 exists, why it is not listed in pip?
Can I install pydot through pip?
Almost all package/program distribution in python is done with distutils. This is very good documented in the python documentation.
To your specific problem: pip usually searches the PyPI for the package and then downloads a distribution of that package. Most often this is a source-package and needs to be byte-compiled. If that succeeds the package is most probably compatible to the python version you're using, if it's not you will most probably get SyntaxErrors or something like that.
As i know PyPI has no other, ultimate-sure version classifiers.
So the most sure way to tell if the package is compatible, is to try to install it and then try if it works.