Closed wkliao closed 1 year ago
To be clear, a Python developer should be able to iterate on the Python code, and depend on its static version string, without caring about any of the autotools/autoconf stuff.
I can remove the 2nd commit which involves pydarshan.
From my experience on netcdf, I think making separate packages, i.e. darshan runtime, darshan util, and pydarshan is a mistake, because it allows users to mix different versions of the packages, i.e. use darshan-runtime version 3.4.0 together with darshan-util 3.3.0. There may be unexpected results.
Changes look good to me, this will simplify releases a bit.
I agree with limiting any sort of dependencies between PyDarshan and the traditional Darshan build system -- we've made this a point in the past as it seems to give us needed flexibility to accomplish what we want on both ends. Ultimately it would be nice if we could automate how PyDarshan captures these versions (as well as C headers in include
), but I'm not sure we need to do it by adopting Autotools in PyDarshan -- it doesn't seem to be used generally in Python projects.
Ok, the Python stuff was removed, Shane approved, and you got a code review from an experienced build system developer (Eli) as well, so I merged it.
Incidentally, the CI only ran for Python on MacOS M1 native, I'm not actually sure what CI we'd want to flush for these changes normally.
Re: CI tests, I added the [skip actions]
key word on my commit since it just modified a doc. I guess that annotation doesn't affect the Cirrus stuff?
Ah understood, yeah the services have different flags. Another project I work on summarizes some of them here, though I believe for some they added some custom handlers we could copy if we wanted https://scipy.github.io/devdocs/dev/contributor/continuous_integration.html#skipping
This simplifies the future version string update, by just editing file ./darshan.version.