requests

ms for e.g. Zed and Helix), Sublime's plugin API has low-level access to the editor, and the runtime has full OS access. I think Sublime was smart to bet on Python for the plugin system. They released the plugin system in 2009, before Python was everywhere. The super flexible plugin API and the huge package ecosystem is a powerful combo.

(in 2.5), reference counting was useful for deterministic cleanup. > The absolutely weak support for functional programming, which then was patched by list comprehensions and co later I'll give you this one. GvR actually didn't like this stuff very much, which is how `reduce` lost its builtin status. The basics can take you really far, though. The important thing is that functions are first-class objects. > venv and other solutions to isolate dependencies for a project There is nothing fundamentally wrong with venvs. 99% of the complaints I hear about venvs are not actually the venv's fault. (They're usually pip's fault. Pip is bad.) A venv is literally just a place to put packages (organized roughly the same way the system packages are) and a simple scheme for enabling Python to understand where that place is (so that `sys.path` can be modified at startup). Every other possibility has the same problem: either you have to learn one or more options for telling Python to use that package location, or it works by magic (which means eventually you have to understand the magic, and anyway "Explicit is better than implicit"). > The pyproject.toml format is under-specified, comes decades too late for a problem that has been solved good enough by Apache Maven more than 2 decades ago pom.xml is not at all "good enough". The pyproject.toml format is actually quite detailed (https://packaging.python.org/en/latest/specifications/pyproj...). It also has explicit design goals of a) allowing arbitrary tools to store their config and b) being human-readable and -writable. More importantly, Python didn't have something like Maven in 2004 alongside Maven because Maven only has to worry about Java code; the Python packaging system has to worry about potentially every programming language, and very commonly C, C++, FORTRAN and now Rust. In 2003 (with Python 2.2) it got `distutils`. That was designed (and Setuptools picked up the torch) to use code in `setup.py` for everything, because nobody had any concept of a real "ecosystem" yet (see if you can find some archives of the Cheeseshop from its first year, if you dare) and it was simple and seemed Pythonic at the time. And now we're in a thread where OP is upset that Python code doesn't work for 30 years, which seems like a pretty common take. It turns out that when you accommodate backwards compatibility, it gets in the way of actually fixing old problems quite a bit. There are still projects out there that are just Python code that could be perfectly well built using Flit, that are using (slow!) legacy setup.py-based build setups. Not because there's anything wrong with pyproject.toml for their purposes (there absolutely isn't), but because nobody is forcing them. People don't even keep their setup.py contents up to date, let alone pay attention to any kind of deprecation warnings. Literally the only thing that gets anyone to do anything is to break their setup, and then for most of them their action is to complain and make the Setuptools team put things back how they were. I'm not just talking about random developers on tiny forgettable projects, either. I'm talking about PSF-managed projects like Requests that: * are pure Python code * are among the most popular packages on PyPI (Requests is top ten) * had their "source builds" break this year (https://github.com/psf/requests/issues/6775) because of a removed import in setup.py for something that nobody has actually used for years (a legacy testing setup that has been completely abandoned since the project uses tox) * already had a `pyproject.toml` file but weren't actually using it to store even basic build configuration (still in `setup.cfg`, so they had all three files for really no reason). (Thankfully, something is actually getting done in Requests. Supposedly. The work for this was apparently "already done" in May 2024 and is supposed to appear "in the next minor version release". The last release as a patch release this August. The main branch of the repo doesn't reflect this work.)

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.

sf/requests/pull/6667 [3] https://github.com/psf/requests/issues/6730 [4] https://github.com/psf/requests/pull/6731