Merge pull request #20 from i4Ds/542-constrain-xarray

542 constrain xarray

README.md

@@ -29,6 +29,8 @@ A normal build-string for a python package (according to [conda-variants doc](ht
 
 Errors in the build-string can occur if they have an `-` (see [Build number and string](https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html#build-number-and-string)). **Attention**: For some reason, the build-string of the according `meta.yaml` gets ignored in some builds and therefore the package-hash is missing in the build-string. Not sure why this is happening. There were cases where the [Host](https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html#host) and/or the [Build](https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html#build) section of the `meta.yaml` were corrupted (e.g. too many unnecessary tools installed) and then the build-string was not build like specified in the according `meta.yaml`. This can have a huge impact if you don't know what you're doing if you trigger a new build. If you don't set the build-number properly, it can easily overwrite an existing live-build on [anaconda.org](https://anaconda.org/i4Ds). This is because if a package is overwritten or not solely relies on the uniqueness of the build-string, and without the hash it just consists of the package-version and the build-number. However, if you use a dev-build, you don't have to worry (make sure that the flag is set!!!), since they have an offset of the build-number of +1000).
 
+**Updating an already existing Wheel**: It may happen that an update of a dependency (direct or transversal) introduces a breaking change in a future release. Then, the current constraints of an existing conda-wheel is outdated an will most likely result in a broken environment. To prevent this, updating the according meta.yaml and increase the build-nr is not enough, because the solver doesn't just consider the largest build-numbers of conda-wheels. So, to fix this for current and also older releases, you have to relabel oudated conda-wheels to `legacy`. Also do a comment in the meta.yaml, why you did constrain the dependency. This makes future builds where the constraints may have to be reconsidered way easier. It was already mentioned in this paragraph, but don't forget to increase the build-number.
+
 ## About MPI
 
 **General**: Currently, there are three different options on how a conda-wheel can be build with mpi. It's either "nompi", "openmpi" or "mpich". It seems like other packages like [h5py](https://anaconda.org/conda-forge/h5py/files) include this in their build-string and so should we if we build an mpi-wheel. This makes it clear to others which packages use mpi and which mpi implementation they were built with by using `conda list | grep mpi`. The way to install mpi-wheels should be handeled by the end-user to enable maximal flexibility of a conda-wheel. This means that mpi-builds should be built with `nompi`, `mpich` and `openmpi` (using conda_build_config.yaml) & you shouldn't refer to mpi-wheel depencencies in the `meta.yaml` of the feedstock, and thus at building-time of Karabo at earliest. Be aware that openmpi nor mpich is windows-compatible. But since we don't support windows you shouldn't have to worry too much. Wheels 

ska-sdp-func-python/meta.yaml

@@ -34,7 +34,7 @@ requirements:
     - scipy                 >=1.10.1
     - ska-sdp-datamodels    ={{ SKA_SDP_DTMDL_VERSION_ALT }}
     - ska-sdp-func          ={{ SKA_SDP_FUNC_VERSION_ALT }}
-    - xarray                <=2023.2  # see issue #542 of Karabo
+    - xarray                =2023.2  # see issue #542 of Karabo
 
 about:
   home: https://gitlab.com/ska-telescope/sdp/ska-sdp-func-python/