search

tox-dev / platformdirs

A small Python module for determining appropriate platform-specific dirs, e.g. a "user data dir".
https://platformdirs.readthedocs.io
MIT License
593 stars 51 forks source link

pre-commit updates of pyproject.toml:[build-system]:requires #216

Closed priv-kweihmann closed 1 year ago

priv-kweihmann commented 1 year ago

I noticed a lot of update of [build-system]:requires in pyproject.toml lately. As much I see the advantage of automated of automated dependency updates, I'm having a hard time downstream to package up new releases of this library.

Background: With my packaging system (Yocto/bitbake) my (2nd) upstream provides a hatchling implementation to do my build, so I will run into a race condition between two upstreams, and as the build system does not allow for good reason to on-the-fly fetch new sources (such as a hatchling point update), I'm always failing on these kind of updates. And judging from what I see it's not really needed to bump every point release of a build system in the pyproject settings, just sticking it to a major/minor version seems to be good enough.

So in conclusion, I'd like like ask to stop bumping hatchling and all of it's plugins in point releases, if it's not technically necessary, but stick to a more "relaxed "~ 1.x" notation, which would make my life much much more easier downstream.

gaborbernat commented 1 year ago

if it's not technically necessary, but stick to a more "relaxed "~ 1.x" notation, which would make my life much much more easier downstream.

It is necessary. The only version of these packages I test with is the latest. Anything else is not guaranteed to still work, so would be a lie to not upgrade.

priv-kweihmann commented 1 year ago

Just to get back to it, the tests went well with hatchling 1.17.0 (which would be fine for me), but due to the nature of pyproject.toml and its hard version pinning I can't package up the latest, due to requiring a point release of the build tool (1.17.1).

Please don't get me wrong, but if a point of release of a build system as a breaking behavior, I wouldn't put much trust in this build system at all.

That said, when the release (which here is done with the help of github action, pulling in the latest matching the specification) is good, why is there still a need for point release pinning - everything should be covered by CI - every breakage from a point release of the build system in that case would be a bug in the build system (so a technical reason to bump here).

Or is there something in here I don't see?

gaborbernat commented 1 year ago

I do not regularly go back to see if the current state of the configuration still works for an older release or not. As such I cannot ensure the build still works with those older versions (be that a bug in the build system or changing our hatchling configuration). If I cannot ensure it still works with that I prefer to pin to a version I actually test with. Seems reasonable to me. Sounds to me like you should improve your build environment to allow easier to test with newer package versions. Feels unreasonable to make the world worse for everyone else to support a limited build environment.