This is the full patch that seems to allow for py-netcdf4~mpi ^hdf5+mpi (at least, the Debian-provided GNU patch 2.7.6 does not have problems with it):

--- a/include/netCDF4.pxi
+++ b/include/netCDF4.pxi
@@ -7,2 +7,2 @@
-cdef extern from "H5public.h":
-    ctypedef int herr_t
+ctypedef int herr_t
+cdef extern from *:
--- a/setup.py
+++ b/setup.py
@@ -395 +395 @@
-    has_parallel_support = check_has_parallel_support(inc_dirs)
+    has_parallel_support = False

--- a/include/netCDF4.pxi
+++ b/include/netCDF4.pxi
@@ -4,8 +4,8 @@
   ctypedef long ptrdiff_t

# hdf5 version info.
-cdef extern from "H5public.h":
-    ctypedef int herr_t
+ctypedef int herr_t
+cdef extern from *:
   int H5get_libversion( unsigned int *majnum, unsigned int *minnum, unsigned int *relnum ) nogil

cdef extern from *:
--- a/setup.py
+++ b/setup.py
@@ -392,7 +392,7 @@
      (netcdf_lib_version > "4.4" and netcdf_lib_version < "4.5"):
       has_cdf5_format = True

-    has_parallel_support = check_has_parallel_support(inc_dirs)
+    has_parallel_support = False
   has_has_not = "has" if has_parallel_support else "does not have"
   print(f"netcdf lib {has_has_not} parallel functions")

We apply the patch as follows:

    with when("@1.7:~mpi"):
        patch("disable_parallel_support.patch", when="^netcdf-c+mpi")
        patch("disable_parallel_support.patch", when="^hdf5+mpi")

It might be enough to apply the patch only when ^hdf5+mpi (because ^netcdf-c+mpi implies ^hdf5+mpi) but netcdf-c~mpi might be an external package built against hdf5+mpi. I don't know how Spack handles that at the moment. Some (long) time ago it used to drop the dependencies of external packages from the specs.

And Wow! It looks like all that is just to emit an obsolete warning under a broken condition.

I updated the patch and package as you suggested, and I built py-netcdf4~mpi ^netcdf-c~mpi ^hdf5+mpi successfully.

It would be good to not let this stagnant, is there anything I can test to help move this along?

Friday evening is for sure not the best time for a reminder like this :) But thank you, I will try my best to take a look at this on Monday.

@skosukhin Sorry that I apparently missed your request for changes three weeks ago. I applied the suggestions and built py-netcdf4 ~mpi with netcdf-c +mpi successfully on my laptop (gcc@13).

@climbfuji are you just waiting on a review for this?

Some (long) time ago it used to drop the dependencies of external packages from the specs.

For the record, Spack still trims the dependencies of external packages

@skosukhin I had to revert part of the patch in commit 8976169 that you contributed a while ago. With that patch, I got the errors reported in #48694 (comment). Would you be able to review again and merge if it looks ok?

@climbfuji what is the value of this MR then? What is the spec that you couldn't install and that can be installed with these changes?

@climbfuji what is the value of this MR then? What is the spec that you couldn't install and that can be installed with these changes?

py-netcdf4 ~mpi ^netcdf-c+mpi

It turns out that we cannot even spack install py-netcdf4 (see #50184).

It turns out that we cannot even spack install py-netcdf4 (see #50184).

I am still on the last commit before the compilers-as-nodes changes were merged (three weeks-ish ago) and py-netcdf4 builds fine for me. This PR started months ago when that code wasn't in develop yet. We should merge this PR and then add the updates for the new compiler dependencies features in a separate PR, since it is a separate issue.

@skosukhin I have also had issues with mpi on the recent py-netcdf

#50075

As it ingests a header that has mpi (when +mpi)

I think this should be merged and then I can rebase #50075 on top of this PR.

Please, fix the PR description.

and when netCDF was built with +mpi but hdf5 was built with ~mpi

1. It's not possible to have netcdf-c+mpi ^hdf5~mpi.
2. We can't have netcdf-c~mpi ^hdf5+mpi after you removed the respective part of the patch.

Done, thanks.

@alalazo could you merge this, please?