Ofek Lev

Yes, please! I'm unfamiliar with the code base, is there any reason to not support every option in the config file?

Hey there! I'm intrigued by your proposal and by instinct is to accept every contribution that doesn't regress performance or UX. However, I'm still getting up to speed with this...

Do we know why 3.14 is fine?

Is there a compelling reason to call that upon a deep copy? If not, then I'd prefer to also fix that in this PR.

I think breaking changes are fine since we are still sub-1.0 and we're also going to introduce others like https://github.com/jcrist/msgspec/pull/790. Both will come in the next minor release.

https://packaging.python.org/en/latest/specifications/core-metadata/#provides-extra-multiple-use > Two feature names `test` and `doc` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively. I think it's okay to recommend...

I can add an option to prevent this check but please understand that this mostly only affects redistributors because normally the latest version would be pulled on CI. How critical...

To get your package working for now you can add a metadata hook with the next few years of Python version classifiers: https://hatch.pypa.io/latest/plugins/metadata-hook/reference/#hatchling.metadata.plugin.interface.MetadataHookInterface.get_known_classifiers

Also, is it possible within the tooling of your distribution to remove Python classifiers from that section that are known to not work e.g. Python 3.13 wouldn't be on Debian...

Okay let me ask you both a question. Say the default of checking for invalid classifiers remains but there is an option as this issue requests for disabling this check....