You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As in the title, the current hard-coded pycairo flags in setup.py hinder installs where Python and pycairo have different prefixes.
Clarification
In a nutshell, if pycairo resides outside of Python's sys.exec_prefix, the current setup.py behavior is incorrect.
See this Dockerfile gist for an example of this issue in a python:3.8-slim-based container that uses Debian's python3-cairo-dev package to provide pycairo.
It looks like someone tried to leverage pkg-config at some point but ultimately disabled it.
Suggestion
I am attaching a patch that aims to give us the best of both worlds: flags sourced from pkg-config when viable with backward compatible fallback flag values when pkg-config detection fails.
This could be rolled up into a slightly better generic pkg-config pattern if other dependencies could benefit from similar behavior but I made the patch solely for pycairo since that was the only preexisting use case of pkg-config in setup.py.
The text was updated successfully, but these errors were encountered:
jwilges
added a commit
to jwilges/python-mapnik
that referenced
this issue
Nov 13, 2020
Allow pkg-config to detect flags for either:
- `py3cairo`, or
- `pycairo`
The previous method of always using `sys.exec_prefix` to locate pycairo
headers is insufficient on systems where Python and pycairo have
different install prefixes (e.g. `/usr` vs. `/usr/local`).
For backward compatibility, the previous method is still the default
behavior when `pkg-config` cannot detect appropriate flags at runtime.
Resolves issue mapnik#234.
jwilges
added a commit
to jwilges/python-mapnik
that referenced
this issue
Nov 13, 2020
Allow pkg-config to detect flags for either:
- `py3cairo`, or
- `pycairo`
The previous method of always using `sys.exec_prefix` to locate pycairo
headers is insufficient on systems where Python and pycairo have
different install prefixes (e.g. `/usr` vs. `/usr/local`).
For backward compatibility, the previous method is still the default
behavior when `pkg-config` cannot detect appropriate flags at runtime.
Resolves issue mapnik#234
Thanks for this patch, but maybe we should also expose this as a system variable. I've installed pycairo in a venv and it doesn't come with a pkg-config configuration. So neither the original one nor your code finds the files inside the venv.
Issue
As in the title, the current hard-coded pycairo flags in
setup.py
hinder installs where Python and pycairo have different prefixes.Clarification
In a nutshell, if pycairo resides outside of Python's
sys.exec_prefix
, the currentsetup.py
behavior is incorrect.See this Dockerfile gist for an example of this issue in a
python:3.8-slim
-based container that uses Debian'spython3-cairo-dev
package to provide pycairo.Reference
Current
setup.py
:It looks like someone tried to leverage
pkg-config
at some point but ultimately disabled it.Suggestion
I am attaching a patch that aims to give us the best of both worlds: flags sourced from
pkg-config
when viable with backward compatible fallback flag values whenpkg-config
detection fails.This could be rolled up into a slightly better generic
pkg-config
pattern if other dependencies could benefit from similar behavior but I made the patch solely for pycairo since that was the only preexisting use case ofpkg-config
insetup.py
.The text was updated successfully, but these errors were encountered: