setuptools: build with setup.py errors with 60.9.1 [BUG]

setuptools version

setuptools==60.9.1

Python version

Python 3.7.6

OS

Linux

Additional environment information

This was encountered on TravisCI using the pypi deployment provider, happens with multiple linux versions from precise to xenial. Not tested on Linux outside of Travis. Cannot reproduce it on MacOS.

Description

Running python setup.py sdist bdist_wheel errors with newest version of setuptools errors. Fixed by using version previous to 60.9.

This might be related to #3113 as the error occurs at setuptools/_vendor/importlib_metadata/__init__.py

Expected behavior

dist/* to be built without errors

How to Reproduce

  1. Have a python package using setup.py calling setup()
  2. Have TravisCI build distributions during it’s deploy step
deploy:
  provider: pypi
  distributions: "sdist bdist_wheel"
  username: ${PYPI_USERNAME}
  password: ${PYPI_PASSWORD}

that boils down to the following commands that can be reproduced

script:
  # mimic travis deploy steps concerning build during deployment step
  # https://github.com/travis-ci/dpl/blob/v1.10.16/lib/dpl/provider/pypi.rb
  # https://github.com/travis-ci/dpl/blob/b577682ac17ff10b7f3fe58c5da1113b05e68cb7/lib/dpl/provider.rb#L187
  - |
    if [ -z ${VIRTUAL_ENV+x} ]; then export PIP_USER=yes; fi && \
    wget -nv -O - https://bootstrap.pypa.io/get-pip.py | python - --no-setuptools --no-wheel && \
    pip install --upgrade --upgrade-strategy eager setuptools twine wheel
  - python setup.py sdist bdist_wheel

This can be fixed by reverting to version previous to 60.9. For example on travis they provide a parameter:

deploy:
  provider: pypi
  distributions: "sdist bdist_wheel"
  username: ${PYPI_USERNAME}
  password: ${PYPI_PASSWORD}
  setuptools_version: "60.8.2"

Output

Deploying application
Traceback (most recent call last):
  File "setup.py", line 8, in <module>
    setup()
  File "/home/travis/virtualenv/python3.7.6/lib/python3.7/site-packages/setuptools/__init__.py", line 155, in setup
    return distutils.core.setup(**attrs)
  File "/home/travis/virtualenv/python3.7.6/lib/python3.7/site-packages/setuptools/_distutils/core.py", line 109, in setup
    _setup_distribution = dist = klass(attrs)
  File "/home/travis/virtualenv/python3.7.6/lib/python3.7/site-packages/setuptools/dist.py", line 462, in __init__
    for k, v in attrs.items()
  File "/home/travis/virtualenv/python3.7.6/lib/python3.7/site-packages/setuptools/_distutils/dist.py", line 293, in __init__
    self.finalize_options()
  File "/home/travis/virtualenv/python3.7.6/lib/python3.7/site-packages/setuptools/dist.py", line 850, in finalize_options
    for ep in sorted(loaded, key=by_order):
  File "/home/travis/virtualenv/python3.7.6/lib/python3.7/site-packages/setuptools/dist.py", line 849, in <lambda>
    loaded = map(lambda e: e.load(), filtered)
  File "/home/travis/virtualenv/python3.7.6/lib/python3.7/site-packages/setuptools/_vendor/importlib_metadata/__init__.py", line 196, in load
    return functools.reduce(getattr, attrs, module)
AttributeError: type object 'Distribution' has no attribute '_finalize_feature_opts'

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 12
  • Comments: 17 (5 by maintainers)

Commits related to this issue

Most upvoted comments

is this something we can expect to go away with future versions independent of travis fixing the virtual environment? Or is this not something you plan to accommodate for?

I’m not confident there’s anything Setuptools could do here, and until we have a repro that can be used to locally investigate, we’re kinda stuck. Besides some of the workarounds described above, there may be other options, such as writing a routine to clear out manually old versions of setuptools before running build tools.

If we could identify something that could be patched in the current or perhaps a past version of Setuptools that would hepl the situation, I’d consider it, but at this point I’ve no options to consider.

Quick follow up on this, I found that building in Travis CI with python 3.9 works around this problem.

Hello,

I’ve the same issue in a venv while I was installing cffi. It was on ARMv7 on debian bullseye with setuptools from system version 52.0.0-4 and when setuptools in the venv is version 62.3.2. Downgrading setuptools in the venv to version 60.8.2 fixed the issue on my side.

I hit something similar with Travis Enterprise using the default (currently ubuntu bionic) image. I had to upgrade the pypi deploy job from python 3.6 (the default in the image) to 3.8 because the travis dpl tooling no longer supports 3.6 (not a surprise). Then I hit this issue. The travis image already had setuptools 60.5.0 installed and then the dpl tooling upgraded to the latest (currently 62.1.0). I’m guessing those mixed versions are somehow interfering with each other, or the pip uninstall of the already installed 60.5.0 didn’t clean everything up.

I tried adding an install script hook to upgrade setuptools before the deploy ran but that didn’t work - it was basically the same thing as the dpl tooling upgrading setuptools.

The workaround I heard from someone else with the same issue was to pin the pypi deploy in Travis build config to the same version of setuptools that was already in the image using the setuptools_version option. That worked as my workaround.

I’m hoping that maybe when Travis Enterprise supports Ubuntu Focal I can try again without the pinned setuptools version.

I appreciate that it’s reproducible in your CI environment. Unfortunately, unless we can somehow ascertain the factors that make it fail in CI and reproduce those in a local environment, it will be near impossible to diagnose. I do suspect there’s something about having two different versions of setuptools installed, on of which is >42,<46. I just yet don’t know what other factor(s) are relevant.