I have a project which needs to depend on the latest commit of pysam, because I'm working in python 3.11.
This means building the package from source, so I do the following:
poetry add git+https://github.com/pysam-developers/pysam
However, I get an error which I think boils down to poetry not including cython in the build environment:
Unable to determine package info for path: /Users/agreen/Library/Caches/pypoetry/virtualenvs/rnacentral-pipeline-GU-1IkEM-py3.11/src/pysam
Fallback egg_info generation failed.
Command ['/var/folders/sg/3858brmd79z4rz781g0q__940000gp/T/tmpw8auvhsm/.venv/bin/python', 'setup.py', 'egg_info'] errored with the following return code 1, and output:
# pysam: no cython available - using pre-compiled C
Traceback (most recent call last):
File "/Users/agreen/Library/Caches/pypoetry/virtualenvs/rnacentral-pipeline-GU-1IkEM-py3.11/src/pysam/setup.py", line 345, in <module>
raise ValueError(
ValueError: no cython installed, but can not find pysam/libchtslib.c.Make sure that cython is installed when building from the repository
Cython is definitely installed, its in the pyproject.toml, and I can call it from the poetry shell, or import it in a python started in the poetry virtualenv. However, If I use the python from the command poetry is running, then indeed cython is not available.
I think I'm missing some configuration of the build, or some extra option to poetry add. The documentation isn't particularly clear about this use of cython - as far as I can tell it's all about using cython in the package I'm writing, which is not quite what I want.
Cython is a build dependency of pysam, but apparently pysam does not have a pyproject.toml and thus does not declare its build dependencies (Cython and maybe others). So this is a dead end.
If I were you I would build a wheel of pysam myself and tell Poetry to use this wheel until pysam releases wheels for Python 3.11 on PyPI themselves. Or I would use Python 3.10.
It seems like it is being worked on: https://github.com/pysam-developers/pysam/pull/1168
When starting my server (python manage.py run server) I get the following error.
File "/Users/thomasallen/PycharmProjects/Channels_and_Signals/venv/lib/python3.9/site-packages/asgi_redis/core.py", line 19, in
from asgiref.base_layer import BaseChannelLayer
ModuleNotFoundError: No module named 'asgiref.base_layer'
The offending line 19 in .../core.py is
from asgiref.base_layer import BaseChannelLayer
The packages I have installed are:
Django 3.2.4
channels 3.0.3
channels-redid 3.2.0
aspired 3.3.4
asgi-redis 1.1.0
I'm not sure where the mismatch is.
It's because asgi_redis 1.1.0 depends on an old version of asgiref (listed without an upper bound as asgiref>=1.0.0 in their setup.py) which used to have this code. But you have a more recent version installed because Django depends on asgiref >= 3.3.2.
You shouldn't have both asgi_redis and channels_redis installed, they are different versions of the same package. See note in the channels_redis git repo:
Note: Prior versions of this package were called asgi_redis and are still available under PyPI as that name if you need them for Channels 1.x projects. This package is for Channels 2 projects only.
Your solution is to not use asgi_redis and use channels_redis instead.
I use poetry to build my package with cython extensions, so install package flag is enabled. I'd like to host documentation via readthedocs. Poetry uses build.py file to generate setup.py with poetry build command. However readthedocs does not support build.py so I provided setup.py with following contents:
from setuptools import setup
from build import *
global setup_kwargs
setup_kwargs = {}
build(setup_kwargs)
setup(**setup_kwargs)
To get rid of requirements.txt file in docs folder, I would like to add extras_require parameter to setup, so the last line in setup.py:
setup(extras_require={'docs': ['toml']}, **setup_kwargs)
Readthedocs calls /<path>/envs/latest/bin/python -m pip install --upgrade --upgrade-strategy eager --no-cache-dir .[docs]
WARNING: does not provide the extra 'docs' and importing toml from docs/conf.py fails
If I add extras to pyproject.toml:
[tool.poetry.extras]
docs = ['toml']
Warning disappears but still rtd fails to import toml.
My .readthedocs.yml:
version: 2
sphinx:
configuration: docs/conf.py
formats: all
python:
version: 3.7
install:
- method: pip
path: .
extra_requirements:
- docs
submodules:
include: all
I'm using python 2.7.6 on Ubuntu 14.04.2 LTS. I'm using mock to mock some unittests and noticing when I import mock it fails importing wraps.
Not sure if there's a different version of mock or six I should be using for it's import to work? Couldn't find any relevant answers and I'm not using virtual environments.
mock module says it's compatible with python 2.7.x: https://pypi.python.org/pypi/mock
mock==1.1.3
six==1.9.0
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from mock import Mock
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.7/dist-packages/mock/__init__.py", line 2, in <module>
import mock.mock as _mock
File "/usr/local/lib/python2.7/dist-packages/mock/mock.py", line 68, in <module>
from six import wraps
ImportError: cannot import name wraps
also tried with sudo with no luck.
$ sudo python -c 'from six import wraps'
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: cannot import name wraps
Installed mock==1.0.1 and that worked for some reason. (shrugs)
edit: The real fix for me was to updated setuptools to the latest and it allowed me to upgrade mock and six to the latest. I was on setuptools 3.3. In my case I also had to remove said modules by hand because they were owned by OS in '/usr/local/lib/python2.7/dist-packages/'
check versions of everything
pip freeze | grep -e six -e mock
easy_install --version
Update everything
wget https://bootstrap.pypa.io/ez_setup.py -O - | sudo python
pip install mock --upgrade
pip install six --upgrade
Thanks #lifeless
I encountered the same issue on my mac, which I was able to fix by realizing that my python's sys.path contained both
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/
and
/Library/Python/2.7/site-packages/
with the former earlier than the latter.
You can test if this is happening to you by running the following in the python console.
import six
six.__version__
my python was loading an outdated six.py from the former directory (which didn't have wrapper), even though pip had installed a newer version six in the second directory. (It seems mac's framework comes with a version of six by default.)
I was able to fix it by moving six.py and six.pyc out of the first directory (requires sudo access), so that python would find the newer version of six in the second directory. I'm sure you could also change the ordering of the paths in sys.path.
To find the older version of six that need to be deleted run this from the terminal console
find /System/Library/Frameworks/Python.framework/Versions -name six.py*
so mock 1.1.1 and above defines a versioned requirement on six 1.7 or above:
https://github.com/testing-cabal/mock/blob/master/requirements.txt#L6
This gets reflected into setuptools metadata by pbr, which there is a versioned setup_requires dependency on:
https://github.com/testing-cabal/mock/blob/master/setup.py#L17
So there are a couple of possibilities:
1) six 1.7 is not new enough
2) there's a distro six package claiming to be 1.9.0 that doesn't have wraps for some reason
3) the setuptools in use didn't integrate properly with pbr and deps are missing
4) the wheel metadata isn't being interrogated properly by your pip/setuptools combination.
We do have a hard requirement for setuptools 17.1, and that was only explicitly reported by setup.py more recently. I'd love it if you can figure which of these is the case and update https://github.com/testing-cabal/mock/issues/298 so that we can fix whatever interaction is leading to this silent failure of setup.py / wheels.
On Mac OSX, the previously installed version of six was blocking my upgraded version from being used. I verified this, as previously suggested by running the following in my interpreter:
import six
six.__version__
To fix this I moved the file:
mv/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/six.py
/tmp/old_six.py
This is stated already in another answer on this site, but I wanted to provide a more streamlined response.
I originally had an issue with old "OS-owned" versions of and pip/setuptools. After I installed pip manually, like so:
wget https://bootstrap.pypa.io/get-pip.py
sudo python get-pip.py
sudo ln -s /usr/local/bin/pip /usr/bin/pip
And then installing the latest version of pip, mock and six, I still had the problem you've described above. Turns out that I had six installed twice in:
/usr/lib/python2.7/dist-packages/
and in
/usr/local/lib/python2.7/dist-packages/
After I removed the six from /usr/lib/ it worked fine:
rm /usr/lib/python2.7/dist-packages/*six*
I did a pip install of six==1.9.0 and it took the new version. It seems like mock==1.3.0 doesn't properly define the version of six that it needs to get wraps support.
Another solution is setting your PYTHONPATH environment variable to point to the installed packages.
Setting my environment variable in my bash config so that:
PYTHONPATH=/Library/Python/2.7/site-packages
Allowed me to run tests in terminal (without removing/renaming any libraries, etc).
However, when using PyCharm, it was less-than-helpfully not correctly importing this environment variable. Even though PyCharm was showing as including parent variables (with that listed in the ones it showed importing), it seems this import wasn't working correctly.
Manually setting the environment variable to the above in the PyCharm run configuration resolves this.
I am unsure if PyCharm overwrites the PYTHONPATH variable after importing it from system environment variables or some other trickery, but this did resolve the error for me.
Though you aren't using a virtual environment like virtualenv, it's certainly a great use case for it. By sandboxing your Python installation and all the dependencies for your project, you can avoid hacking away at the global/default python installation entirely, which is where a lot of the complexity/difficulty comes from.
This is what I used when I got the wraps error - requirements.txt contains mock==2.0.0 and six==1.10.0:
cd <my_project>
virtualenv venv
source venv/bin/activate
sudo pip install -r requirements.txt
Not only is this simpler to use in my opinion, it's also simpler to document for people who might want to run your code.
I found a interesting things!
There is a file named "functools.py" in my project root path, and while I run my project , pycharm will raise ImportError.
So I rename my file fix this problem~~
My pyflakes portion of flake8 is not running for my global python instance (/usr/bin/python, not virtualenv).
flake8 --version
2.2.3 (pep8: 1.5.7, mccabe: 0.2.1) CPython 2.7.5 on Darwin
It doesn't seem like pyflakes is getting attached to flake8. pip freeze confirms that pyflakes==0.8.1 is installed. I installed on my global site-packages ($ sudo pip install flake8).
However, when running inside of a virtualenv, pyflakes is in the list and flake8 works as expected.
I had a similar problem with conda's flake8. Here are some debugging notes:
flake8 registers the pyflakes checker in its setup.py file:
setup(
...
entry_points={
'distutils.commands': ['flake8 = flake8.main:Flake8Command'],
'console_scripts': ['flake8 = flake8.main:main'],
'flake8.extension': [
'F = flake8._pyflakes:FlakesChecker',
],
},
...
When checking a file, flake8 loads the registered entry points for 'flake8.extension' and registers found checkers:
...
for entry in iter_entry_points('flake8.extension'):
checker = entry.load()
pep8.register_check(checker, codes=[entry.name])
...
conda's flake8 seems to have problems writing those entry points.
from pkg_resources import iter_entry_points
list(iter_entry_points('flake8.extension'))
returns an empty list for me, which is why pyflakes won't be registered and thus does not work, even though it is installed and importable.
Updating setuptools and installing via pip install flake8 fixes the problem for me.