Open hynek opened 3 months ago
This issue also affecting pypa/setuptools#4533.
Thanks for notifying me!
Would it be possible to create a release which limits the version of the towncrier dependency?
@commonism it'd be pointless as pip's depresolver would just backtrack to the previous version.
@commonism it'd be pointless as pip's depresolver would just backtrack to the previous version.
Pip does not do that
I can assure you, with my PyPA hat on, that pip's dependency resolver (resolvelib
) does exactly that in exactly this corner case, unless the end-user adds a constraint that would prevent it from considering those versions, which is already possible, anyway.
If sphinxcontrib-towncrier==0.4.1
will have a constraint towncrier<24.7
, and user installs sphinxcontrib-towncrier
without any explicit version constraint, then pip will install sphinxcontrib-towncrier==0.4.1, towncrier==23.11.0
. I don't see why pip will apply some kind of backtracking in this case.
Of course, things may be more complicated if some other package passed to pip install
depends on other towncrier version, or specific package version is not available on current environment (Python version and so on).
That's it. You still have to manually constrain the user request on what to install. But if you don't — backtracking happens. OTOH, you can already constrain it now, even without a release with different metadata. And arguably, you should pin your entire environment, not just bits and pieces: https://hynek.me/articles/semver-will-not-save-you/#taking-responsibility.
That said, I don't see how this would be different with or without a release just bumping the metadata. When I find time to work on this, I won't be looking into trivial stop-gaps and will just fix the incompatibility :man_shrugging: It doesn't make sense to me to spend that time twice.
@webknjaz I was just about to offer some help on fixing this issue but it looks like you have something planned for tomorrow already :-)
In case you haven't looked into this in any detail yet I will summarise my progress so far: from a quick review of the update to Towncrier they have switched the find_fragments()
function to taking in the Config
dataclass, rather than only some components from it. I note that in this project currently the Towncrier config is only used in the lookup_towncrier_fragments()
function. At the moment it is loaded through _towncrier.get_towncrier_config()
which has various contortions to cope with different Towncrier versions, including converting the dataclass Config
object (since Towncrier 22.12.0rc1) back into the dict it used to be. However, since only the one lookup_towncrier_fragments()
uses this function, it should be safe to allow the function to return the dataclass instead.
There are basically then three pathways based on the version of Towncrier:
find_fragments()
with the dataclass configfind_fragments()
with attributes of the dataclass config (or convert it to a dict and go for option 3.)find_fragments()
with parameters extracted from the dict configThe main question is how to distinguish pathway 1 from 2: checking for the current TypeError is not ideal because if another parameter is added to the new find_fragments()
in a future Towncrier version then it will break. We could use importlib.metadata
as advocated here https://setuptools-scm.readthedocs.io/en/latest/usage/ if you are happy to go to Python>=3.8 or add the backport as a dependency.
Happy to put together a PR if that would be helpful, just let me know your thoughts.
@bennyrowland well, I added it on the board of the aiohttp sprint because it's used in the infra and it would be nice to have. IIRC I was trying hard to keep Python 3.6 support for one final release and was planning to drop all EOL versions right after, shrinking the matrix by a lot. But I didn't take into account some bits of this repos infra and broke it. Never had time to pick it up. Feel free to work on this, I do not think if someone would be able to do so tomorrow anyway, just trying to fill the board with possibilities. FWIW, seeing that I don't have as much time as I'd like (I'm writing this at VIE awaiting my flight to LHR to lead that Man Group hackathon sprint on aiohttp), it's okay to drop all EOL versions already. I recommend starting with an infra cleanup/fix PR, followed by the new towncrier compat. It could be more PRs — the smaller it is the higher the chance of a quick review. Thanks for offering to help! If you're not going to work on this today, I recommend waiting until Saturday noon to see if someone picks it up. Otherwise, I can assign you for visibility whenever.
Looks like the just-released Towncrier 24.7 has broken some API you're using:
See https://github.com/python-attrs/attrs/actions/runs/10176118290/job/28144823882#step:6:29 for full CI failure.