Some additional PGPLOT functions + Python2/3 supported in setup.py #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This version is a fork of:
https://github.com/npat-efault/ppgplot
merging in useful edits from:
https://github.com/cbassa/ppgplot (C. Bassa fork)
merged with edits to make ppgplot compileable and loadable on MacOSX and
Linux Python2 and 3
setup.py + src/__init__.py
modified to support both Python2, Python3:
print function, no '.has_key()' in Py3k
import _ppgplot.* does not work under Py3k so rewritten to work in
both 2 and 3
X11 library paths:
on (modern) Linux X11 is not in /usr/X11R6/... so try a few paths
and add if they exist
O/S support:
C. Bassa setup.py did not compile out of the box on MacOSX so only
useful edits migrated into this one
src/_ppgplot.c
modified to support both Python2, Python3:
C. Bassa fork had most of the Py3k work done but was not backward
compat with 2.7 so fixed that; now compiles fine under 2.7 and 3.6
PGPLOT functions:
- C. Bassa fork added pgerr[xy]
- C. Bassa fork changed pgcurs/pgband behaviour
- added pgqwin to query current window
The ppgplot extension may need to be linked to a different PGPLOT library than the system one - e.g. against a locally compiled Giza library(*) and both may need to co-exist. When $PGPLOT_DIR environment variable is set, 'setup.py' now looks for lib(c)pgplot.so under that directory and instruments distutils' setup(...) to link to that library. The linker is then also instructed to include the shared library's path(s) in the shared object such that import'ing it in Python should work irrespective of the user's LD_LIBRARY_PATH. Also added support for '--no-numarray', '--no-Numeric' and '--no-numpy' command line options to disable these as potential candidates for linking against. (*) http://giza.sourceforge.net/ "Giza also provides a drop-in, modern replacement for the PGPLOT graphics library (libpgplot and libcpgplot)."
Can now use python3 on MacOSX to link to giza as well using:
# when building giza:
# ./configure --prefix=/path/to/giza-root
# then do:
$> cd /path/to/ppgplot
$> export PGPLOT_DIR=/path/to/giza-root
$> /path/to/python[3] setup.py [...]
Added pgerr1 functionality
Added pgpt1 functionality
Open
Adding README.md and updating it for current use
The Numpy API stuff kept on warning, hopefully now defaults to using API that's installed on the current system w/o warning. Also gcc-12.2.0 (Debian 12.2.0-14) didn't like some of the pointer conversions in "tofloatmatrix()" so they were fixed
The [pkgconfig.configure_extension()](ihttps://pypi.org/project/pkgconfig/) is quite convenient except when it isn't.
On Deb12.2.0-14 it was adding an empty string to the extra_compile_args:
extension.extra_compile_args = [ '' ]
Which tricked the system into a command that looked like (irrelevant
info stripped):
/path/to/C-compiler [options] -o build/.../_ppgplot.o ""
Note the literal'""' at the end of the command; it resulted in the GCC
compiler deciding "Not performing linking because linker command file
cannot be found" (or words to that effect).
Stripping the empty string fixed it
With external depencies the user has to install manually
Those were examples for "numarray" and "Numeric" - very very very old stuff
Trying to backport the new pip install -e . stuff onto a Py3.6 host, just for checking. Wasn't easy at all, so decided to write up the howto and at least mention it on the master branch.
- chose package name python-pgplot - updated README.me to reflect this
- Removed Nick Patavalis from author list; would be listed as contact author of project. I woulnd't have minded, but he doesn't seem to be contactable (when I proposed a PR years ago didn't get a response) - Updated README.md to list NickP as original author explicitly - Updated setup.py to build the extension with the explicit 'name="python-pgplot"' argument
Because 1.5.0 is now already usurped by PyPI and cannot be reused, but we needed to fix some (meta)data settings. So 1.5.0 was deleted b/c it was 'wrong', but can't be reused anymore.
added 30 commits
August 6, 2025 11:47
... orelse the if ... ; then ... elseif ... fi don't work on windows-latest
This took a lot of time to figure out; several issues had to be
overcome.
giza-dev dependency not found when trying to cibuildwheel
---------------------------------------------------------
Linux:
Installing the giza-dev dependency on the runner's host-O/S does not make it
visible in the builder; cibuildwheel runs its builds into
yet-other-containers (multiple) images; these days based on Alma Linux.
That distro does not have giza-dev or giza-devel pkgs.
Solution: add a manual build step for Linux to pull giza tarball release
and build *inside* the build container (sheesh).
Support using yum or apt-get to install system dependencies.
See CIBW_BEFORE_ALL_LINUX.
MacOS:
the MacOS image has homebrew so can install deps there easily, no need
to build giza ourselves; see CIBW_BEFORE_ALL_MACOS
Follow advice from cibuild:repairwheel step:
packages/delocate/delocating.py", line 925, in _check_and_update_wheel_name
raise DelocationError(
<< many output skipped >>
/private/var/folders/y6/nj790rtn62lfktb1sh__79hc0000gn/T/tmp7vjagw4l/wheel/ppgplot/.dylibs/libXext.6.dylib has a minimum target of 14.0
Set the environment variable 'MACOSX_DEPLOYMENT_TARGET=14.0' to update minimum supported macOS for this wheel.
See CIBW_ENVIRONMENT_MACOS.
Upload wheels step fails
------------------------
At the end of a macos-latest buid got this error in the "upload wheels"
step:
Error: Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run
Need to get separate artifacts per OS without name conflicts.
Fixed by adding a build matrix variable to the artefact name:
name: python-pgplot-wheels-${{ matrix.os }}
Hardened build, add smoke-test
------------------------------
- restricted to "native" builds on MacOS, iso "universal" (homebrew
don't do universal)
- make PKG_CONFIG path persist so it will be retained in wheel
- add smoke-test (CIBW_TEST_COMMAND)
The setup.py extension configurator would look for libX11 (fine) but didn't add the path to the library to the library search path for the linker. Fixed.
Don't even try to build on windows. Found out that there are cp314t? cibuildwheel builds that are based on "musllinux" (wtf?) That distro doesn't seem to have either of apt-get or yum, so would have to figure out how to install (system)dependencies there and then build giza again. Disable building on *musllinux* images for now
In the build_wheels workflow we now have a working config; transplant it into the publish_to_pypi workflow
The workflow was enhanced to:
- download all artefacts ("dist/*")
- flatten the files into one dir ("dist/")
- clean up
- adds a job that builds a source distribution
- adds "twine check" to verify
- publishes to pypi
It was trying to configure Giza even when it was just expected to build a source distribution
If this file ends up on the main/default branch we can manually trigger it and have the option of skipping publishing to PyPI
- can be triggered manually if this ends up in the main/default branch - can be triggered by any push onto a branch named test-cicd*
This would trigger on each push, that's unnecessary now that building works. Next steps are to build-and-publish to (test)PyPI, and there's other workflows for that that trigger on tagging (official PyPI) and on pushes onto branches named test-cicd* Expect the workflows to end up onto the main/default branch soon, after which we can trigger this workflow manually
User on Fedora42 reporting issue: >>> import ppgplot RuntimeError: module was compiled against NumPy C-API version 0x14 (NumPy 2.3) but the running NumPy has C-API version 0x13. Check the section C-API incompatibility at the Troubleshooting ImportError section at https://numpy.org/devdocs/user/troubleshooting-importerror.html#c-api-incompatibility for indications on how to solve this problem. Traceback (most recent call last): File "<python-input-2>", line 1, in <module> import ppgplot File "/home/bram/.local/lib/python3.13/site-packages/ppgplot/__init__.py", line 1, in <module> from . _ppgplot import * ImportError: numpy._core.multiarray failed to import The Problem The extension was compiled against NumPy 2.3 (API version 0x14) but the user's system has NumPy with API version 0x13. This is a forward compatibility issue - the extension expects a newer NumPy API than what's available. Root Cause The issue is NPY_TARGET_VERSION NPY_API_VERSION which sets the target to whatever NumPy version was available at build time. When you built the wheels, you had NumPy 2.3, so it locked the extension to require NumPy 2.3+. Solution We need to set a lower, stable NumPy API version that's compatible with a wider range of NumPy versions.
Because there is no numpy2 on Python3.8, we drop support for that (although the extension would work Just Fine there) In order to be numpy v1.x and v2.x compatible one _has_ to build with numpy 2.x, see https://numpy.org/devdocs/dev/depending_on_numpy.html#numpy-2-0-specific-advice
The workflow is now also automatically triggered on branches that are called fix-* Having it only manually executed from the main/default branch is only so useful
The recipe would fail to build after a "conda build purge". Now it doesn't
Time to update some of the meta information about who contributed and make explicit what the license of the code is (LGPL). The LGPL is mentioned in PKG-INFO but no-one (recent) will look into that.
The intent was to trigger "build_wheels" workflow only on branches called "fix-*". The YAML file had the wrong syntax for it, but on account it being an effing stupid format (YAML) w/o proper grammar, no-one complained. It did explain why I got many builds triggered on branches where I didn't expect them. *sigh*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Dear mr Patavalis,
First of all: thanks a lot for the python PGPLOT binding! I use it a lot in my code and am very pleased with it!
In using it I've added
pgqwin()support and in this fork merged in a few additions/changes from the fork by Cees Bassa fork.I made
setup.pywork transparently on Python2 and 3; the Cees Bassa fork implemented Python3 support but broke Python2.One change in
setup.pymight be debatable. Ifsetup.pydetects PGPLOT_DIR is set, it will look under that directory forlibpgplot.soand hard link theppgplotmodule to that shared library.The latter was necessitated by the need to be able to support co-existing original FORTRAN PGPLOT libraries under
/usr/libas well as having Giza (https://github.com/danieljprice/giza - a drop-in PGPLOT replacement) installed somewhere else.I did not succeed in linking
ppgplotin such a way that supporting both libraries being installed on the same system and choosing at runtime using e.g.LD_LIBRARY_PATHactually worked. Maybe I missed some important step.