FR: Publish a fully packaged source wheel

[nairb774]

While the current distribution is workable, it would be nice to get a full wheel published as well.

Right now, when installing plaid-python with uv, it goes through the process of building the plaid-python package. While quick, this does add up over time.

We don't see this sort of issue with other source-only packages, so I'm guessing it is the lack of a published wheel that is triggering this. For example, we don't see this behavior with Celery. Comparing the files for celery and plaid-python on PyPi, we can see that the plaid-python package is missing a *-py3-none-any.whl style file.

I'm by no means a python packaging expert, but mostly looking for simple optimization wins.

[dimbleby]

#537

[duckduckgrayduck]

A similar but related issue to the current setup of plaid-python packaging is that it uses the old packaging system for Python - setup.py which relies on setuptools. As of setuptools 82, pkg_resources has been removed.

When installing plaid-python without pinning setuptools<81, you will run into a module not found error for pkg_resources because it was removed similar to this one:
UserWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html. The pkg_resources package is slated for removal as early as 2025-11-30. Refrain from using this package or pin to Setuptools<81.

Setuptools prior to 78.1.1 just this past year had a CVE: https://nvd.nist.gov/vuln/detail/CVE-2025-47273

This means that 78.1.1 <= setuptools < 81 are safe and compatible, for now. Eventually though, I suspect that this will become a problem. Given how many companies use plaid and the importance of the data, the package maintainers for plaid-python should do the responsible thing and move to the new packaging standard which is to use a pyproject.toml file in order to avoid being left behind.
https://packaging.python.org/en/latest/guides/writing-pyproject-toml/

[dimbleby]

Using pyproject.toml is independent of using setuptools as the backend, and neither has anything much to do with this issue.

What is relevant is that if maintainers published wheels, then users would not be exposed to breakages in wheel-building (eg by setuptools making breaking changes).

[duckduckgrayduck]

Using pyproject.toml is independent of using setuptools as the backend, and neither has anything much to do with this issue.

What is relevant is that if maintainers published wheels, then users would not be exposed to breakages in wheel-building (eg by setuptools making breaking changes).

Right, ideally they would both publish the wheels and fix the outdated build system for maintainability.

[dimbleby]

if you have a new request it would be appropriate to raise a new issue, rather than confuse this one