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.

Sign up for GitHub

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

Jump to bottom

Add setuptools and wheel dependencies to the setup.cfg #889

Merged
merged 4 commits into from
Jun 5, 2021
Merged

Add setuptools and wheel dependencies to the setup.cfg #889

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
fe12efd
setup.cfg: Add missing dependencies
jayvdb Jul 10, 2020
62af2e3
Merge branch 'master' into missing-deps
ssbarnea Jun 5, 2021
90bcd88
Update setup.cfg
ssbarnea Jun 5, 2021
1681e82
Merge branch 'master' into missing-deps
ssbarnea Jun 5, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions setup.cfg
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,9 +29,13 @@ setup_requires = setuptools_scm
packages = find:
zip_safe = false
install_requires =
# direct dependencies
click >= 7
pep517
pip >= 20.3
# indirect dependencies
setuptools # typically needed when pip-tools invokes setup.py
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it's allowed to put inline comments here because stdlib configparser treats them as part of the values... Even if some setuptools versions have workarounds for this, there's no guarantee that the end-user has them pre-installed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is correct. These comments will become part of the Requirement, and any tool which reads these must handle comments. Just like requirements.txt lines can contain comments.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to be compliant with some historical PEP, or minimum setuptools version, I'd appreciate knowing what to target. I know that setuptools has supported this for a long time, but I don't recall how far back it goes. Likewise packaging and more modern requirements toolkits.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW I did some checks on Ubuntu and here's setuptools shipped via apt (pulled in as a dependency of python3-pip):

  • focal -> 45.2.0
  • bionic -> 39.0.1
  • xenial -> 20.7.0
  • trusty -> 3.3

I don't know how old setuptools version should be supported but FYI Travis still allows running all Ubuntu versions all the way back to Precise and defaults to Xenial: https://docs.travis-ci.com/user/reference/overview/#which-one-do-i-use.

Debian:

  • buster -> 40.8.0
  • stretch -> 33.1.1
  • jessie -> 5.5.1

Now, what about something RPM-based? Let's look at the CentOS the same way:

  • 8 -> 39.2.0
  • 7 -> 39.2.0 # manylinux2014 wheels are to be built here
  • 6 -> 0.6.10-4.el6_9 (Python 2) # this version is used for manylinux2010 wheels
  • 5 -> none (it ships with Python 2.4.3) # interestingly, this is the version one is supposed to use when building manylinux1 wheels

RHEL:

  • 8 -> 39.2.0-5.el8
  • 7 -> 0.9.8-7.el7 (Python 2)
  • 6 (setuptools unavailable w/o a subscription but should be about the same as CentOS 6) — it's still around in some places, going EOL in the end of November

The above distros are popular in various server/CI envs (and are all available via docker registries). Though I'm not sure which versions are actually widely used nowadays.

If we look at Fedora, they usually ship modern developer-oriented ecosystem but it's mostly used on desktops (AFAICS):

  • 32 -> 41.6.0-2.fc32
  • 31 -> 50.1.0-1.fc34 (now sure why it pulled repos from rawhide distros)
  • 30 -> 40.8.0
  • 29 -> 40.4.3
  • 28 -> 39.2.0
  • 27 -> 37.0.0
  • 26 -> 37.0.0
  • 25 -> 25.1.1
  • 24 -> 20.1.1

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow. Very helpful.

I am pretty sure that using setup.cfg already breaks most of those versions of older setuptools.

No doubt you know setuptools adds features bit by bit, rarely (historically at least; im a bit out of the loop) fully implement a standard with adequate tests to have anything resembling compliance. And complimenting that, the setup.cfg syntax niceties has evolved over time. So medium age setuptools might work, but may degrade a bit unless we stick with very basic setup.cfg syntax.

WRT RHEL, anyone seriously using it will be using rpms, built from sdists and .spec and .patch files as needed, not needing pip/pip-tools or setuptools. And devs will be using latest RHEL with Rawhide or other additional channels.

So ... "bionic -> 39.0.1" feels like a good target to start with, as that will include manylinux2014. The reason I would want manylinux2014 support is because pip-compile-multi depends on pip-tools, and iirc there was another similar tool.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can pip-tools force isolated-builds instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A quick repo search didn't reveal any proposals to add pyproject.toml to this repo but I think its support in modern pip is stable enough nowadays that it's reasonable to add it. OTOH this comment chain is about the legacy systems that wouldn't know anything about PEP518/PEP517.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can still build a legacy setup.py project in isolated-build "mode"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, you can. As long as you actually have a modern PEP517 build front-end (like pip 10+). But I've listed a lot of platforms above for which it is not true.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pip-tools already depends on pip >= 20.1 so a pep517 frontend is always available

wheel # pip plugin needed by pip-tools

[options.packages.find]
exclude = tests
Expand Down