Summary: | dev-python/cython (and other packages?): ImportError: cannot import name 'unique_everseen' from 'setuptools._vendor.more_itertools' (unknown location) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Seong-ho Cho <darkcircle.0426> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | gentoo, mgorny |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info log.
A collection of error log from many packages |
Description
Seong-ho Cho
2022-01-30 16:19:38 UTC
Please include: 1. emerge --info 2. the full buildlog (attach it) of something failing. What's your version and USE flags of dev-python/more-itertools? (In reply to Michał Górny from comment #2) > What's your version and USE flags of dev-python/more-itertools? my use flag for python version is ----- These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-python/more-itertools-8.12.0-r1::gentoo USE="-doc -test" PYTHON_TARGETS="python3_8 python3_9 python3_10 -pypy3" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB ----- Created attachment 764018 [details]
emerge --info log.
Created attachment 764019 [details]
A collection of error log from many packages
If you need more data something like EV, log, please let me know. thank you. Try: python3.8 -c 'from more_itertools import unique_everseen' python3.8 -c 'from setuptools.extern.more_itertools import unique_everseen' (In reply to Michał Górny from comment #7) > Try: > > python3.8 -c 'from more_itertools import unique_everseen' first line is ok (no message) > python3.8 -c 'from setuptools.extern.more_itertools import unique_everseen' but second line shows that, Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python3.8/site-packages/setuptools/__init__.py", line 18, in <module> from setuptools.dist import Distribution File "/usr/lib/python3.8/site-packages/setuptools/dist.py", line 31, in <module> from setuptools.extern.more_itertools import unique_everseen ImportError: cannot import name 'unique_everseen' from 'setuptools._vendor.more_itertools' (unknown location) I'm afraid this is gonna take some digging. How about: $ python3.8 -c 'import setuptools.extern.more_itertools; print(setuptools.extern.more_itertools)' <module 'setuptools.extern.more_itertools' (<setuptools.extern.VendorImporter object at 0x7efd19427430>)> $ python3.8 -c 'import setuptools.extern.more_itertools; print(setuptools.extern.more_itertools.unique_everseen)' <function unique_everseen at 0x7f9ffcb064c0> (In reply to Michał Górny from comment #9) > I'm afraid this is gonna take some digging. > > How about: > > $ python3.8 -c 'import setuptools.extern.more_itertools; > print(setuptools.extern.more_itertools)' > <module 'setuptools.extern.more_itertools' > (<setuptools.extern.VendorImporter object at 0x7efd19427430>)> > > > $ python3.8 -c 'import setuptools.extern.more_itertools; > print(setuptools.extern.more_itertools.unique_everseen)' > <function unique_everseen at 0x7f9ffcb064c0> Two commands for test are the same rather than we expect Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python3.8/site-packages/setuptools/__init__.py", line 18, in <module> from setuptools.dist import Distribution File "/usr/lib/python3.8/site-packages/setuptools/dist.py", line 31, in <module> from setuptools.extern.more_itertools import unique_everseen ImportError: cannot import name 'unique_everseen' from 'setuptools._vendor.more_itertools' (unknown location) and I found that there is no file related on the python3-8 at alpha /usr/lib/python3.8/site-packages/setuptools/_vendor/more_itertools/__pycache__ # ls -al 합계 404 drwxr-xr-x 2 root root 4096 1월 26일 21:48 . drwxr-xr-x 3 root root 4096 1월 26일 21:48 .. -rw-r--r-- 1 root root 237 2021년 7월 9일 __init__.cpython-310.pyc -rw-r--r-- 1 root root 231 2021년 5월 23일 __init__.cpython-37.pyc -rw-r--r-- 1 root root 235 2021년 7월 9일 __init__.cpython-39.pyc -rw-r--r-- 1 root root 109987 2021년 7월 9일 more.cpython-310.pyc -rw-r--r-- 1 root root 109638 2021년 5월 23일 more.cpython-37.pyc -rw-r--r-- 1 root root 109980 2021년 7월 9일 more.cpython-39.pyc -rw-r--r-- 1 root root 17963 2021년 7월 9일 recipes.cpython-310.pyc -rw-r--r-- 1 root root 17806 2021년 5월 23일 recipes.cpython-37.pyc -rw-r--r-- 1 root root 17900 2021년 7월 9일 recipes.cpython-39.pyc Is that a reason to vomit (?) an error message ? Could you try rebuilding dev-python/more-itertools and seeing if it replaces the wrong cache files and/or installs the right one? Also, please verify whether "echo $PYTHONPATH" as root outputs anything. (In reply to Michał Górny from comment #11) > Could you try rebuilding dev-python/more-itertools and seeing if it replaces > the wrong cache files and/or installs the right one? Sure, There is nothing occurs. It installed the right one to the right place. > Also, please verify whether "echo $PYTHONPATH" as root outputs anything. I declared manually into the .bashrc, alpha ~ # export | grep PYTHONPATH declare -x PYTHONPATH=":/usr/lib/python3.8/site-packages:/root/.local/lib/python3.8/site-packages" alpha ~ # (In reply to Seong-ho Cho from comment #12) > (In reply to Michał Górny from comment #11) > > Could you try rebuilding dev-python/more-itertools and seeing if it replaces > > the wrong cache files and/or installs the right one? > > Sure, There is nothing occurs. It installed the right one to the right place. > > > Also, please verify whether "echo $PYTHONPATH" as root outputs anything. > > I declared manually into the .bashrc, > > alpha ~ # export | grep PYTHONPATH > declare -x > PYTHONPATH=":/usr/lib/python3.8/site-packages:/root/.local/lib/python3.8/ > site-packages" > alpha ~ # Please try removing this. (In reply to Michał Górny from comment #11) > Could you try rebuilding dev-python/more-itertools and seeing if it replaces > the wrong cache files and/or installs the right one? > > Also, please verify whether "echo $PYTHONPATH" as root outputs anything. I have a simple question, in the last night I tried to comment out below, line 62 of setuptools-60.5.0-r1.ebuild 57 DOCS=( {CHANGES,README}.rst ) 58 59 src_prepare() { 60 # remove bundled dependencies, setuptools will switch to system deps 61 # automatically 62 # rm -r */_vendor || die <<<<<------ right here!! 63 64 # apply distutils patches to the bundled distutils 65 pushd setuptools/_distutils >/dev/null || die 66 # TODO: distutils C++ patch? 67 eapply -p3 "${WORKDIR}/${CPY_PATCHSET}/0006-distutils-make-OO-enable-both-opt-1-and-opt-2-optimi.patch" 68 popd >/dev/null || die and commit ebuild setuptools-60.5.0-r1.ebuild manitest compile merge; after then, I could emerge, configobj ipython_genutils notify2 prompt_toolkit protobuf-python and any other python-related packages. ........why I could do this? (In reply to Sam James from comment #13) > (In reply to Seong-ho Cho from comment #12) > > (In reply to Michał Górny from comment #11) > > > Could you try rebuilding dev-python/more-itertools and seeing if it replaces > > > the wrong cache files and/or installs the right one? > > > > Sure, There is nothing occurs. It installed the right one to the right place. > > > > > Also, please verify whether "echo $PYTHONPATH" as root outputs anything. > > > > I declared manually into the .bashrc, > > > > alpha ~ # export | grep PYTHONPATH > > declare -x > > PYTHONPATH=":/usr/lib/python3.8/site-packages:/root/.local/lib/python3.8/ > > site-packages" > > alpha ~ # > > Please try removing this. after then, there is no declaration of the $PYTHONPATH. Setting PYTHONPATH to system directory means that different versions of Python will use the site-packages directory of the wrong version. I'm afraid that at this point, you system might be broken beyond repair. (In reply to Michał Górny from comment #16) > Setting PYTHONPATH to system directory means that different versions of > Python will use the site-packages directory of the wrong version. I'm > afraid that at this point, you system might be broken beyond repair. is there something documentation I could refer? No. I'm afraid we didn't predict someone would deliberately tell Python 3.9 to use files of Python 3.8, etc. (In reply to Michał Górny from comment #18) > No. I'm afraid we didn't predict someone would deliberately tell Python 3.9 > to use files of Python 3.8, etc. Oh my :$ configurations are twisted. I have a while now, so a short explanation what happened: PYTHONPATH takes precedence over default search paths. When you added python3.8's site-packages directory to PYTHONPATH, python3.9, 3.10, etc. started importing modules from python3.8. The obviously visible side effect of this is that they byte-compiled modules in this directory, so your __pycache__ directory now contains .pyc files from other Python versions. These files aren't tracked by portage, so you'll have to remove them manually, or they're going to stay there forever and may cause trouble in the future (e.g. by keeping empty directories existing that normally should have been removed). The bigger issue are .so extensions. While pure Python code is most likely to work across different Python versions (unless some package is really hacky and installs different .py files depending on Python version), C extensions will work only on the implementation they were built for. Let's say you have 'foo' package containing 'bar' C extension. If you 'import foo.bar' on py3.9, it will load 'foo' from py3.8 and then won't be able to find 'bar' submodule because it's incompatible. As a result, random packages will fail. That said, I'm not sure why and how more_itertools are affected here. I suppose we should find some place to document this (but where?). I think the larger part of the issue would be resolved if you removed PYTHONPATH. However, long term you'd at least have to remove the extra .pyc files. Some packages may also generate extra files when imported. I think looking for orphan files may be a good first step, gentoolkit or portage-utils may have had a tool to help with that. Rebuilding everything from /usr/lib/python*/site-packages may be a good idea afterwards, e.g.: emerge -1v /usr/lib/python*/site-packages If you have more questions, we can try to help. |