question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Errors with v49.2.0's distutils adoption

See original GitHub issue

Related to #2256 / #2259.

When upgrading to setuptools>=49.1.3 for the https://github.com/pypa/setuptools/pull/2249 fix for Pillow, we get the new warning in v49.2.0:

/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/setuptools/distutils_patch.py:25: UserWarning: Distutils was imported before Setuptools. This usage is discouraged and may exhibit undesirable behaviors or errors. Please use Setuptools’ objects directly or at least import Setuptools first.

This also causes some C build issues and this sanity test failure; Pillow checks the version in the lower-level C code (“Core version”) matches that in the user-facing Python code (“Pillow version”):

/home/travis/virtualenv/python3.9-dev/lib/python3.9/site-packages/Pillow-7.3.0.dev0-py3.9-linux-x86_64.egg/PIL/Image.py:115: RuntimeWarning: The _imaging extension was built for another version of Pillow or PIL: Core version: None Pillow version: 7.3.0.dev0


Moving the setuptools import before distutils in our setup.py removes the warning but not the error.

https://travis-ci.org/github/hugovk/Pillow/builds/707730154

I’ve not dug into this further, but it’s happening at least on all the Linux/Python versions tested on Travis (3.5-3.9), and wanted to let you know.

More details at https://github.com/python-pillow/Pillow/pull/4784#issuecomment-657727387.

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:14 (13 by maintainers)

github_iconTop GitHub Comments

1reaction
hugovkcommented, Jul 17, 2020

One option to replace distutils.version is packaging.version.parse:

0reactions
jaracocommented, Nov 19, 2021

is there a firm commitment from setuptools that these (admittedly obscure) functions and attributes, that many projects depend on, will not change without a migration path and a clear deprecation cycle that matches the release cycle of the scientific python stack?

I wouldn’t say there’s a firm commitment, but I would say there is a strong commitment to helping the community transition off of distutils in the stdlib, preferably to something other than distutils, but providing distutils in the meantime in a compatible way and communicating changes through semver. Setuptools/distutils will rely heavily on the community (numpy, PyPy, and others) to contribute to the solution to provide the smoothest transition.

If more of a commitment is needed, please open an issue.

Read more comments on GitHub >

github_iconTop Results From Across the Web

No results found

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found