setuptools

project's packaging to Flit ;) ) The import name for Python code is untouched; if you're affected, you need only add `-new` to `stringcase` in your dependency specifications. Versioning is also intended to maintain continuity. The 1.2.2 release should behave identically to 1.2.0, just in case you need a bug-compatible version with modern packaging; 1.2.3 will incorporate the author's apparent planned fixes for 1.2.1, as well as bugfixes from the community where appropriate. I'm trying to be quite conservative with this. If you want fixes and additional functionality, and don't mind a different import name, you may prefer to switch to Casefy [6], which has become popular in its own right [7]. The process [8] for recovering names on PyPI for abandoned projects can take a very long time, but I've been encouraged to follow up on that. If I ever do get the `stringcase` name on PyPI I will rebuild the releases (to fix metadata) and make them available under the original name as well. If you know anyone with a project depending on `stringcase`, including transitively, please let them know. One major dependent is `frictionless` [9], who apparently have decided to vendor `stringcase` [10]. (Keep in mind you are not future-proofed if you pin or cap the `frictionless` version.) I'd also like to specifically thank Damian Shaw [11] of the Pip maintenance team for extraordinary efforts (e.g. [12]) in coordinating discussion (and contributions to existing discussion) around the underlying problems that allowed removal of a trivial, years-deprecated feature from Setuptools to be so disruptive. This isn't just about Setuptools' policies and abandoned projects: other build backends can learn from this, build frontends (including installers) can offer better overrides for build backend versions used in build isolation, and both sides can coordinate to make deprecation warnings more visible to developers. And hopefully, maybe, one day Setuptools will become just a build backend, like it seemingly wants to be [13]. [0]: https://pypi.org/project/stringcase [1]: https://pypistats.org/packages/stringcase [2]: https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-pure-python [3]: https://github.com/pypa/setuptools/issues/4910 [4]: https://github.com/zahlman/stringcase-new [5]: https://pypi.org/project/stringcase-new [6]: https://github.com/dmlls/python-casefy [7]: https://pypistats.org/packages/casefy [8]: https://peps.python.org/pep-0541/#how-to-request-a-name-transfer [9]: https://github.com/frictionlessdata/frictionless-py [10]: https://github.com/frictionlessdata/frictionless-py/pull/1727 [11]: https://github.com/notatallshaw [12]: https://discuss.python.org/t/_/85847 [13]: https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html

project.toml only for tool config, and relies on both a setup.cfg and setup.py. Developers and maintainers in 2021 should have been well aware of standards like https://peps.python.org/pep-0621/, and have heard of the problems caused by setup.py-based metadata. The code is 100% Python (even Ansible itself is, as far as I can tell) so a setup.py is completely unnecessary. (Ansible includes a "dummy" setup.py "for compatibility with older tools", but the ecosystem really is supposed to have moved on from that by now.) * But none of this should have been a problem for the OP anyway, because - being 100% Python - the ansible-vault package should have been distributing a wheel (https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-pure-...), but doesn't (https://pypi.org/project/ansible-vault/#files). (Yes, I did notice that Mr. Gedam published that article at the end of 2022. Education efforts about Python packaging around 2020-2021 were apparently quite lacking.) * The purpose of 78.0.1 was to "temporarily remove Requests from integration tests" (https://github.com/pypa/setuptools/pull/4909). In other words, they knew that this would break the build for Requests. Fortunately, Requests does follow good practice and publish a wheel, or there would have indeed been a problem worthy of a sensationalized title. (It's one of the most popular packages out there, and the stats don't even count the vendored copies included in Pip.) * Requests has been bitten by a Setuptools removal before, last July (https://github.com/psf/requests/issues/6775). That time, the removal was the only reason for bumping the version number, and then it got promptly restored in 72.1.0 anyway. This time, there was only a bugfix besides the one removal in 78.0.0, and now it's been undone in 78.0.2. (So undoing a removal is sometimes a minor update and sometimes a patch, interesting...) * When that problem occurred in July, I proposed that the packaging system should be modernized - and was told by a Requests maintainer that this was already planned since the previous release last May, to appear in the next minor version (2.33). But it's been almost a year and that release hasn't appeared yet. (I have to wonder what else they're planning to include...) * The history of the decision for the original deprecation (https://github.com/pypa/setuptools/issues/1608) is also rather interesting.