'make -C devel/py-virtualenv stage' fails with 'AttributeError'... ============= . . ===> Staging for py39-virtualenv-20.23.0 ===> py39-virtualenv-20.23.0 depends on package: py39-distlib>=0.3.6 - found ===> py39-virtualenv-20.23.0 depends on package: py39-filelock>=3.4.1 - found ===> py39-virtualenv-20.23.0 depends on package: py39-platformdirs>=2.4 - found ===> py39-virtualenv-20.23.0 depends on file: /usr/local/bin/python3.9 - found ===> Generating temporary packing list /usr/local/bin/sphinx-build-3.9 -d /z1/local/poudriere/ports/clean-git/devel/py-virtualenv/work-py39 -b html -n /z1/local/poudriere/ports/clean-git/devel/py-virtualenv/work-py39/virtualenv-20.23.0/docs /z1/local/poudriere/ports/clean-git/devel/py-virtualenv/work-py39/stage/usr/local/share/doc/py39-virtualenv Running Sphinx v5.3.0 making output directory... done Exception occurred: File "/usr/local/lib/python3.9/site-packages/setuptools/_vendor/importlib_metadata/__init__.py", line 196, in load return functools.reduce(getattr, attrs, module) AttributeError: module 'virtualenv.create.via_global_ref.builtin.cpython.mac_os' has no attribute 'CPython2macOsArmFramework' The full traceback has been saved in /tmp/sphinx-err-f4yefhrs.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks! *** Error code 2 ============= This happens if py39-virtualenv-20.21.1 is currently installed. I renamed /usr/local/lib/python3.8/site-packages/virtualenv-20.21.1.dist-info/entry_points.txt to /usr/local/lib/python3.8/site-packages/virtualenv-20.21.1.dist-info/entry_points.txt.mv, and then it had no problem. Presumably deleting py39-virtualenv-20.21.1 would work as well. The following also worked for me (without renaming entry_points.txt or removing the 20.21.1 package): env PYTHONPATH=/usr/ports/devel/py-virtualenv/work-py39/stage/usr/local/lib/python3.9/site-packages stage That seems like a good thing - to have a port look in $WRKSRC first for modules in its own build tree before looking in $LOCALBASE and using elements from a previous install of the package. I wish more software builds were designed to look in the source tree first before looking outside it. It's more correct. I understand the urge to close this with WONTFIX, however, and instead just tell people to build in a "clean" environment.
(In reply to John Hein from comment #0) Hmm... I can't reproduce my success now with setting PYTHONPATH to look in the working source tree first. That doesn't seem to be enough to find the entry_points.txt in the staging area instead of the one in /usr/local/lib/python3.9. I guess I don't currently understand how it looks for entry_points.txt I might have to raise the white flag on this one.
Created attachment 242025 [details] Patch to fix stage target when there is another version installed Hi, could you try this patch, please?
I got the same issue and can confirm the patch works for me.
(In reply to Jekyll Chen from comment #3) Thanks for the feedback. Unfortunately that patch is not the solution, because it breaks the build in poudriere and from the ports when a user doesn't have a previous version of virtualenv installed. We need a different way...
(In reply to Nicola Vitale from comment #4) In that patch, the first part of your sed substitution should probably be %%PYTHON_MODULE%%, not %%PYTHON_WHEEL%%. And, yes, after making that change it is able to complete 'make stage' without the error from sphinx-build. But interestingly, if you don't fix the sed, it ALSO works with the unexpanded %% string. And for that matter, it works if you just comment out the sys.path.insert altogether. It's only when you have the old package installed and the new .whl file in sys.path that the error occurs. I am curious why that is.