Setuptools environment support logic incorrect

[jaraco]

I was looking at setup.py when I noticed ranged comparison in environment markers with older setuptools. It wasn't until setuptools 17.1 that environment markers supported ranged operators. So you may need a 1.5 level of support, or maybe you want to make 17.1 your minimum supported version for level 1 support.

[RonnyPfannschmidt]

thanks for the note, we will try to resolve qickly

[RonnyPfannschmidt]

@jaraco the comparison there is not ranged, its a plain < - my understanding is that those are supported

[jaraco]

Hmm. < was what I meant by ranged operators. I believe Setuptools prior to 17.1 only supports version comparisons of equality and inequality.

[nicoddemus]

Can we close this or is this still valid?

[RonnyPfannschmidt]

i believe we should sort this out by using https://github.com/pytest-dev/pytest/blob/master/pyproject.toml#L3 and forcing a setuptools version that's supported

[nicoddemus]

So it is just a matter of changing pyproject.toml to:

[build-system]
requires = [
  "setuptools>=17.1",
  "setuptools-scm",
  "wheel",
]

?

[RonnyPfannschmidt]

@nicoddemus personally id like to go for a much more modern one and drop all the legacy creep in setup.py

[nicoddemus]

@nicoddemus personally id like to go for a much more modern one and drop all the legacy creep in setup.py

I'm fine with that too. I think it is fair to require a reasonably recent version of setuptools and pip.

Which should be the minimum required version? This might be worth doing for the 3.9 release.

[RonnyPfannschmidt]

we have more leeway to choose good for the 4.0 one

[nicoddemus]

Hmm why is that? We have changed requirements of our dependencies in minor versions in the past.

[RonnyPfannschmidt]

@nicoddemus setuptools in various older versions is used as part of more convoluted build processes at various types of enduser - i believe breaking them that way should be done in a more major release

[nicoddemus]

OK thanks. I'm setting this to the 4.0 milestone then. 👍

[jaraco]

I’ve indicated setuptools >=30.3 in my projects’ pyproject.tomls with no ill effects. I recommend it and wouldn’t defer to a backward incompatible release.

[RonnyPfannschmidt]

@jaraco thanks for that note, i'öö do t right now then

[RonnyPfannschmidt]

@jaraco random other sidenote - is there anything in setuptools to have extensions for it obtain options from pyproject.toml - setup.cfg supports no extension at all (thus its a major pain for setuptools_scm)

[jaraco]

is there anything in setuptools to have extensions for it obtain options from pyproject.toml

I doubt setuptools will ever get anything from pyproject.toml... at least not until it completely adopts distutils. As long as it depends on distutils, it will be bound to setup.cfg, so supporting another file just adds confusion. If I'm missing something, though, let's do DDD (documentation-driven development) and describe what you'd like to see from setuptools around using pyproject.toml to extend setuptools.

I do think it would be worthwhile to allow entry points to extend the declarative config, the same way that distutils_keywords can extend imperative config.

[RonnyPfannschmidt]

@jaraco just trying to figure how to make extended setuptools_scm configuration less of a pain (that mapping is a pain to do correctly)