Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Support setuptools > v65.7.0 #676

Open
hcoona opened this issue Dec 9, 2024 · 0 comments
Open

[Feature Request] Support setuptools > v65.7.0 #676

hcoona opened this issue Dec 9, 2024 · 0 comments

Comments

@hcoona
Copy link

hcoona commented Dec 9, 2024

Background

The current SuperBenchmark project pins setuptools to v65.7.0 to avoid breaking changes introduced in setuptools v66.0.0. This pin was added in PR #483 to handle changes from pypa/setuptools#2497 and pypa/setuptools#3772.

Problem

However, this pin is becoming increasingly problematic:

  1. More and more projects are using newer versions of setuptools, leading to potential conflicts when using SuperBenchmark alongside these projects.

  2. The original issue that prompted the pin (removal of LegacyVersion support in v66.0.0) has been fully resolved in the Python ecosystem. The majority of packages now use PEP 440 compliant versions.

  3. Users are missing out on important improvements and bug fixes introduced in newer setuptools versions, including:

  • Support for PEP 625 package name normalization (v69.3.0)
  • Improved metadata handling and PKG-INFO generation (v68.2.0)
  • Better atomicity when writing PKG-INFO files (v68.2.0)
  • Enhanced PyProject.toml support (v68.1.0)
  • Various performance improvements and bug fixes

Proposal

I propose we:

  1. Remove the setuptools pin from SuperBenchmark requirements
  2. Test compatibility with latest setuptools version
  3. Update any necessary code to work with newer setuptools features
  4. Update documentation to reflect the changes

This will allow users to benefit from newer setuptools features while maintaining compatibility with modern Python packaging practices.

Impact

The change should be low risk since:

  1. The original issue that prompted the pin (LegacyVersion support) is no longer relevant in today's Python ecosystem
  2. Most packages now follow PEP 440 version guidelines
  3. Recent setuptools versions have been stable and widely adopted

The benefit would be improved compatibility with the broader Python ecosystem and access to newer packaging features.

Does this seem like a reasonable approach? I'd be happy to help with implementation and testing if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant