pygobject
pypi lacks linux wheels
Although it's fairly easy for adepts to get pip to build wheels there may be a need to have prebuilt wheels which don't need any expertise.
To that end I created an action workflow and support script here https://github.com/replabrobin/pycairo.
Since it just adds new files it claims to be merge-able. Should I create a pull request for it?
The linux-wheels action takes about 40minuts to run.
Thanks, interesting.
The main problem is that binary wheels break all C API users since there would be multiple cairo libraries loaded at the same time (that breaks pygobject for example). The only workaround there is that every pycairo user would need to force no-binary mode when installing when they know there will be another cairo loaded at some point. From what I see poetry and uv now provide pyproject.toml setting for that at least, so you wouldn't need to remember doing it every time.
There are likely more pycairo users not needing the C API, so I get the need.
Your workflow is using the distro provided libraries?
Random thought: how about doing the inverse of what freetype-py is doing and trying to load the system library first and falling back to a bundled one?
@madig that might work as a default, but as a library pycairo can't know the intention of the developer that's calling it.
Whatever the default is there should be a mechanism to override it, since there are uses for both scenarios.
I've always found uharfbuzz's solution for this elegant -- default to bundled library, but with the option to use the system library instead -- would that be of interest here?
There seem to be moves afoot in the pypa maintainers and others to support binary dependencies at least for the main linux distros
https://discuss.python.org/t/pep-804-an-external-dependency-registry-and-name-mapping-mechanism/103891/17
I suspect implementation is a long way off as this is quite a hard problem
Virtualenv was released in 2007, making this an issue for python devs who use system libraries.
We can wait a few more years - really good to see it being tackled.
AFAIU, this tackles the problem of coordinating with (some/the system) packaging tool, but not the case of not wanting to install compilers and stuff on the machines where a Py package is supposed to be installed.
Reading it, it also seems to bind to one operating systems package manager, so doesn't solve the general problem.