fix: require minimum versions of depenencies

[henryiii]

This fixes issues where an old version of requirements are cached on a users system, causing build to break on install. Testing by manually loading old versions of packages in tox. Closes #263.

Mostly selected min versions based on changelogs or just trying old versions and slowly increasing until one passed, except for packaging, where I thought 19+ seemed fine and started with that.

@gaborbernat, I'm better with nox than tox, there might be ways to clean this up? Also, is there any nice trick to get pip load the oldest possible versions instead of the latest, without manually listing them?

[uranusjr]

Also, is there any nice trick to get pip load the oldest possible versions instead of the latest

Not sure I understand this line, oldest as in like packaging 1.0?

[layday]

Not sure I understand this line, oldest as in like packaging 1.0?

The minimum version that meets the dependency specification, as in pypa/pip#8085.

[henryiii]

Yes, that's exactly what I meant, will watch that issue! If you specify a version range, it's possible a user will get the oldest possible version, so it's important for testing. If no minimum version is specified, yes, that's the oldest version on PyPI, because a user could get that if it's already installed or cached. If you don't support the lowest version you allow, you can get broken installs. If you have enough users of your package, it eventually comes up. I'd really like to test this on most packages.

[henryiii]

Oops, I don't think the extra tests are running due to the way the GitHub Actions are set up to manually run each environment.

[layday]

Why is this only being tested on 3.5 and 3.6?

[henryiii]

Because the oldest possible requirements may not work on the newer Pythons, as they generally predate them. Generally, I'd put the oldest version only here, but 2.7 and 3.5 are different enough to include both, and 3.6 might become the new minimum eventually and was trivial to add, so I added that too (but could easily remove). Might be helped by a new "minimum" solver in Pip, but maybe not, since Pip doesn't know what version was the first to support Python x.y. Even the maintainer doesn't know that till after the Python release, sometimes. ;)

[henryiii]

On a newer Python, you should not have a dependency sitting around cached older than the Python version itself, so I think just checking the oldest Python supported (+/- the current special cases) is fine for this check.

[gaborbernat]

This makes the CI even slower, but is the price we have to pay for correctness I guess.

[henryiii]

I don't think this is testing was hoping it would test. By adding the min values to an extra, I was hoping it would be easier to see if it was out of date, and also to get an immediate error from the minversion test if the locked version was not allowed by the range in the install requires. But the installed versions do not seem to be the locked versions.

[layday]

It looks like this behaviour changed sometime between pip 20.2.3 and 21.0.1; the latter does respect the extra dependency versions.

[henryiii]

Intentionally? A lot changed in 20.3 with the new solver.

[layday]

I can't say if it was intentional but I assume tox in CI calls an older version of pip with the old resolver.

[layday]

Erm, actually, this only happens when you prefix the Python version - tox -e minversion installs the lockminversions dependencies but tox -e py39-minversion doesn't. Perhaps someone familiar with tox's internals could explain what's going on here.

[FFY00]

I think this is a good idea, though right now I don't have time to check the details, so I'll leave that to the other maintainers.
I just have one note, please use setup.cfg as the prefix, as that is the location of the core change. In our currently adopted commit message model, the prefix indicates location, not action.

[henryiii]

please use setup.cfg as the prefix

I changed to that structure before unmarking as draft. (I had to dig back a bit to see if it was "setup", "setup-cfg", or "setup.cfg", but I found a commit with the latter).

[henryiii]

I've included everything except pre-building a wheel. Do we want to do that?

[gaborbernat]

[layday]

LGTM, thanks for working on this.

[henryiii]

Thanks everyone!