fix: don't lower bound anndata so high

[ilan-gold]

Why was this done in #1083 when the outcome of conda-forge/spatialdata-io-feedstock#14 was "this is an issue with conda dependency resolution"?

For example, releasing this change would immediately make you incompatible with anyone upper bounding anndata, of which there may be a few: https://github.com/search?q=%22anndata%3C0%22&type=code

Is there some other reason to lower bound this?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.93%. Comparing base (78f75ef) to head (5d4dcd1).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #1102 +/- ##
=======================================
Coverage 91.93% 91.93% =======================================
Files 51 51 Lines 7772 7772 =======================================
Hits 7145 7145 Misses 627 627 

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LucaMarconato]

My understanding is that with anndata==0.12.0 there is no pandas upper bound, leading to serialization problems, so I think the lowerbound should be between anndata>0.12.0 and the higher one I used. But higher than anndata>=0.9.1. On the other hand now that the conda issue is addressed by adding the explicit dependency we can leave 0.9.1 and let conda figure things out.

[ilan-gold]

Right, anyone installing new envs will get the functioning version combo, but that is probably true independent of what you do here (see below for the edge cases). Let's game out some of the possibilities:

• spatialdata keeps its high lower bound on anndata: Library foo comes along and wants to install anndata<0.12. Dependency resolution will simply break and error when you do pip install spatialdata foo. But ok, you wish to force the installation, so you install foo after installing spatialdata to sidestep this problem. But now you've not only gotten rid of the shared dependency resolution around anndata but also every other shared package between spatialdata and foo for which there are some sort of restrictions. As far as packages go, anndata's "breaking" minor version bumps are generally not that bad. But what if foo bounds dask in a way that installs one of the broken dask-dataframe versions (which are excluded by spatialdata)? That is very nasty!
  -spatialdata goes back to the old 0.9.1 low bound: The above situation doesn't happen, so that is an improvement. But to address your point, let's say foo has anndata<0.12.5 i.e., before the pandas bound. In this case pip install spatialdata foomight give pandas>=3 if no other dependencies have the upper bound - but then you can just add a constraint to the installation! That is resolvable! The above situation is not though.

This is my reasoning.

[LucaMarconato]

True that's a good argument, let's go with case 2 then. Thanks for chiming in!

[ilan-gold]

Why was this done in #1083 when the outcome of conda-forge/spatialdata-io-feedstock#14 was "this is an issue with conda dependency resolution"?

For example, releasing this change would immediately make you incompatible with anyone upper bounding anndata, of which there may be a few: https://github.com/search?q=%22anndata%3C0%22&type=code

Is there some other reason to lower bound this?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.93%. Comparing base (78f75ef) to head (5d4dcd1).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #1102 +/- ##
=======================================
Coverage 91.93% 91.93% =======================================
Files 51 51 Lines 7772 7772 =======================================
Hits 7145 7145 Misses 627 627 

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LucaMarconato]

My understanding is that with anndata==0.12.0 there is no pandas upper bound, leading to serialization problems, so I think the lowerbound should be between anndata>0.12.0 and the higher one I used. But higher than anndata>=0.9.1. On the other hand now that the conda issue is addressed by adding the explicit dependency we can leave 0.9.1 and let conda figure things out.

[ilan-gold]

Right, anyone installing new envs will get the functioning version combo, but that is probably true independent of what you do here (see below for the edge cases). Let's game out some of the possibilities:

• spatialdata keeps its high lower bound on anndata: Library foo comes along and wants to install anndata<0.12. Dependency resolution will simply break and error when you do pip install spatialdata foo. But ok, you wish to force the installation, so you install foo after installing spatialdata to sidestep this problem. But now you've not only gotten rid of the shared dependency resolution around anndata but also every other shared package between spatialdata and foo for which there are some sort of restrictions. As far as packages go, anndata's "breaking" minor version bumps are generally not that bad. But what if foo bounds dask in a way that installs one of the broken dask-dataframe versions (which are excluded by spatialdata)? That is very nasty!
  -spatialdata goes back to the old 0.9.1 low bound: The above situation doesn't happen, so that is an improvement. But to address your point, let's say foo has anndata<0.12.5 i.e., before the pandas bound. In this case pip install spatialdata foomight give pandas>=3 if no other dependencies have the upper bound - but then you can just add a constraint to the installation! That is resolvable! The above situation is not though.

This is my reasoning.

[LucaMarconato]

True that's a good argument, let's go with case 2 then. Thanks for chiming in!

[ilan-gold]

Why was this done in #1083 when the outcome of conda-forge/spatialdata-io-feedstock#14 was "this is an issue with conda dependency resolution"?

For example, releasing this change would immediately make you incompatible with anyone upper bounding anndata, of which there may be a few: https://github.com/search?q=%22anndata%3C0%22&type=code

Is there some other reason to lower bound this?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.93%. Comparing base (78f75ef) to head (5d4dcd1).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #1102 +/- ##
=======================================
Coverage 91.93% 91.93% =======================================
Files 51 51 Lines 7772 7772 =======================================
Hits 7145 7145 Misses 627 627 

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LucaMarconato]

My understanding is that with anndata==0.12.0 there is no pandas upper bound, leading to serialization problems, so I think the lowerbound should be between anndata>0.12.0 and the higher one I used. But higher than anndata>=0.9.1. On the other hand now that the conda issue is addressed by adding the explicit dependency we can leave 0.9.1 and let conda figure things out.

[ilan-gold]

Right, anyone installing new envs will get the functioning version combo, but that is probably true independent of what you do here (see below for the edge cases). Let's game out some of the possibilities:

• spatialdata keeps its high lower bound on anndata: Library foo comes along and wants to install anndata<0.12. Dependency resolution will simply break and error when you do pip install spatialdata foo. But ok, you wish to force the installation, so you install foo after installing spatialdata to sidestep this problem. But now you've not only gotten rid of the shared dependency resolution around anndata but also every other shared package between spatialdata and foo for which there are some sort of restrictions. As far as packages go, anndata's "breaking" minor version bumps are generally not that bad. But what if foo bounds dask in a way that installs one of the broken dask-dataframe versions (which are excluded by spatialdata)? That is very nasty!
  -spatialdata goes back to the old 0.9.1 low bound: The above situation doesn't happen, so that is an improvement. But to address your point, let's say foo has anndata<0.12.5 i.e., before the pandas bound. In this case pip install spatialdata foomight give pandas>=3 if no other dependencies have the upper bound - but then you can just add a constraint to the installation! That is resolvable! The above situation is not though.

This is my reasoning.

[LucaMarconato]

True that's a good argument, let's go with case 2 then. Thanks for chiming in!

[ilan-gold]

Why was this done in #1083 when the outcome of conda-forge/spatialdata-io-feedstock#14 was "this is an issue with conda dependency resolution"?

For example, releasing this change would immediately make you incompatible with anyone upper bounding anndata, of which there may be a few: https://github.com/search?q=%22anndata%3C0%22&type=code

Is there some other reason to lower bound this?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.93%. Comparing base (78f75ef) to head (5d4dcd1).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #1102 +/- ##
=======================================
Coverage 91.93% 91.93% =======================================
Files 51 51 Lines 7772 7772 =======================================
Hits 7145 7145 Misses 627 627 

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LucaMarconato]

My understanding is that with anndata==0.12.0 there is no pandas upper bound, leading to serialization problems, so I think the lowerbound should be between anndata>0.12.0 and the higher one I used. But higher than anndata>=0.9.1. On the other hand now that the conda issue is addressed by adding the explicit dependency we can leave 0.9.1 and let conda figure things out.

[ilan-gold]

Right, anyone installing new envs will get the functioning version combo, but that is probably true independent of what you do here (see below for the edge cases). Let's game out some of the possibilities:

• spatialdata keeps its high lower bound on anndata: Library foo comes along and wants to install anndata<0.12. Dependency resolution will simply break and error when you do pip install spatialdata foo. But ok, you wish to force the installation, so you install foo after installing spatialdata to sidestep this problem. But now you've not only gotten rid of the shared dependency resolution around anndata but also every other shared package between spatialdata and foo for which there are some sort of restrictions. As far as packages go, anndata's "breaking" minor version bumps are generally not that bad. But what if foo bounds dask in a way that installs one of the broken dask-dataframe versions (which are excluded by spatialdata)? That is very nasty!
  -spatialdata goes back to the old 0.9.1 low bound: The above situation doesn't happen, so that is an improvement. But to address your point, let's say foo has anndata<0.12.5 i.e., before the pandas bound. In this case pip install spatialdata foomight give pandas>=3 if no other dependencies have the upper bound - but then you can just add a constraint to the installation! That is resolvable! The above situation is not though.

This is my reasoning.

[LucaMarconato]

True that's a good argument, let's go with case 2 then. Thanks for chiming in!

[ilan-gold]

Why was this done in #1083 when the outcome of conda-forge/spatialdata-io-feedstock#14 was "this is an issue with conda dependency resolution"?

For example, releasing this change would immediately make you incompatible with anyone upper bounding anndata, of which there may be a few: https://github.com/search?q=%22anndata%3C0%22&type=code

Is there some other reason to lower bound this?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.93%. Comparing base (78f75ef) to head (5d4dcd1).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #1102 +/- ##
=======================================
Coverage 91.93% 91.93% =======================================
Files 51 51 Lines 7772 7772 =======================================
Hits 7145 7145 Misses 627 627 

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LucaMarconato]

My understanding is that with anndata==0.12.0 there is no pandas upper bound, leading to serialization problems, so I think the lowerbound should be between anndata>0.12.0 and the higher one I used. But higher than anndata>=0.9.1. On the other hand now that the conda issue is addressed by adding the explicit dependency we can leave 0.9.1 and let conda figure things out.

[ilan-gold]

Right, anyone installing new envs will get the functioning version combo, but that is probably true independent of what you do here (see below for the edge cases). Let's game out some of the possibilities:

• spatialdata keeps its high lower bound on anndata: Library foo comes along and wants to install anndata<0.12. Dependency resolution will simply break and error when you do pip install spatialdata foo. But ok, you wish to force the installation, so you install foo after installing spatialdata to sidestep this problem. But now you've not only gotten rid of the shared dependency resolution around anndata but also every other shared package between spatialdata and foo for which there are some sort of restrictions. As far as packages go, anndata's "breaking" minor version bumps are generally not that bad. But what if foo bounds dask in a way that installs one of the broken dask-dataframe versions (which are excluded by spatialdata)? That is very nasty!
  -spatialdata goes back to the old 0.9.1 low bound: The above situation doesn't happen, so that is an improvement. But to address your point, let's say foo has anndata<0.12.5 i.e., before the pandas bound. In this case pip install spatialdata foomight give pandas>=3 if no other dependencies have the upper bound - but then you can just add a constraint to the installation! That is resolvable! The above situation is not though.

This is my reasoning.

[LucaMarconato]

True that's a good argument, let's go with case 2 then. Thanks for chiming in!

[ilan-gold]

Why was this done in #1083 when the outcome of conda-forge/spatialdata-io-feedstock#14 was "this is an issue with conda dependency resolution"?

For example, releasing this change would immediately make you incompatible with anyone upper bounding anndata, of which there may be a few: https://github.com/search?q=%22anndata%3C0%22&type=code

Is there some other reason to lower bound this?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.93%. Comparing base (78f75ef) to head (5d4dcd1).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #1102 +/- ##
=======================================
Coverage 91.93% 91.93% =======================================
Files 51 51 Lines 7772 7772 =======================================
Hits 7145 7145 Misses 627 627 

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LucaMarconato]

My understanding is that with anndata==0.12.0 there is no pandas upper bound, leading to serialization problems, so I think the lowerbound should be between anndata>0.12.0 and the higher one I used. But higher than anndata>=0.9.1. On the other hand now that the conda issue is addressed by adding the explicit dependency we can leave 0.9.1 and let conda figure things out.

[ilan-gold]

Right, anyone installing new envs will get the functioning version combo, but that is probably true independent of what you do here (see below for the edge cases). Let's game out some of the possibilities:

• spatialdata keeps its high lower bound on anndata: Library foo comes along and wants to install anndata<0.12. Dependency resolution will simply break and error when you do pip install spatialdata foo. But ok, you wish to force the installation, so you install foo after installing spatialdata to sidestep this problem. But now you've not only gotten rid of the shared dependency resolution around anndata but also every other shared package between spatialdata and foo for which there are some sort of restrictions. As far as packages go, anndata's "breaking" minor version bumps are generally not that bad. But what if foo bounds dask in a way that installs one of the broken dask-dataframe versions (which are excluded by spatialdata)? That is very nasty!
  -spatialdata goes back to the old 0.9.1 low bound: The above situation doesn't happen, so that is an improvement. But to address your point, let's say foo has anndata<0.12.5 i.e., before the pandas bound. In this case pip install spatialdata foomight give pandas>=3 if no other dependencies have the upper bound - but then you can just add a constraint to the installation! That is resolvable! The above situation is not though.

This is my reasoning.

[LucaMarconato]

True that's a good argument, let's go with case 2 then. Thanks for chiming in!

[ilan-gold]

Why was this done in #1083 when the outcome of conda-forge/spatialdata-io-feedstock#14 was "this is an issue with conda dependency resolution"?

For example, releasing this change would immediately make you incompatible with anyone upper bounding anndata, of which there may be a few: https://github.com/search?q=%22anndata%3C0%22&type=code

Is there some other reason to lower bound this?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.93%. Comparing base (78f75ef) to head (5d4dcd1).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #1102 +/- ##
=======================================
Coverage 91.93% 91.93% =======================================
Files 51 51 Lines 7772 7772 =======================================
Hits 7145 7145 Misses 627 627 

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LucaMarconato]

My understanding is that with anndata==0.12.0 there is no pandas upper bound, leading to serialization problems, so I think the lowerbound should be between anndata>0.12.0 and the higher one I used. But higher than anndata>=0.9.1. On the other hand now that the conda issue is addressed by adding the explicit dependency we can leave 0.9.1 and let conda figure things out.

[ilan-gold]

Right, anyone installing new envs will get the functioning version combo, but that is probably true independent of what you do here (see below for the edge cases). Let's game out some of the possibilities:

• spatialdata keeps its high lower bound on anndata: Library foo comes along and wants to install anndata<0.12. Dependency resolution will simply break and error when you do pip install spatialdata foo. But ok, you wish to force the installation, so you install foo after installing spatialdata to sidestep this problem. But now you've not only gotten rid of the shared dependency resolution around anndata but also every other shared package between spatialdata and foo for which there are some sort of restrictions. As far as packages go, anndata's "breaking" minor version bumps are generally not that bad. But what if foo bounds dask in a way that installs one of the broken dask-dataframe versions (which are excluded by spatialdata)? That is very nasty!
  -spatialdata goes back to the old 0.9.1 low bound: The above situation doesn't happen, so that is an improvement. But to address your point, let's say foo has anndata<0.12.5 i.e., before the pandas bound. In this case pip install spatialdata foomight give pandas>=3 if no other dependencies have the upper bound - but then you can just add a constraint to the installation! That is resolvable! The above situation is not though.

This is my reasoning.

[LucaMarconato]

True that's a good argument, let's go with case 2 then. Thanks for chiming in!

[ilan-gold]

Why was this done in #1083 when the outcome of conda-forge/spatialdata-io-feedstock#14 was "this is an issue with conda dependency resolution"?

For example, releasing this change would immediately make you incompatible with anyone upper bounding anndata, of which there may be a few: https://github.com/search?q=%22anndata%3C0%22&type=code

Is there some other reason to lower bound this?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.93%. Comparing base (78f75ef) to head (5d4dcd1).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #1102 +/- ##
=======================================
Coverage 91.93% 91.93% =======================================
Files 51 51 Lines 7772 7772 =======================================
Hits 7145 7145 Misses 627 627 

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LucaMarconato]

My understanding is that with anndata==0.12.0 there is no pandas upper bound, leading to serialization problems, so I think the lowerbound should be between anndata>0.12.0 and the higher one I used. But higher than anndata>=0.9.1. On the other hand now that the conda issue is addressed by adding the explicit dependency we can leave 0.9.1 and let conda figure things out.

[ilan-gold]

Right, anyone installing new envs will get the functioning version combo, but that is probably true independent of what you do here (see below for the edge cases). Let's game out some of the possibilities:

• spatialdata keeps its high lower bound on anndata: Library foo comes along and wants to install anndata<0.12. Dependency resolution will simply break and error when you do pip install spatialdata foo. But ok, you wish to force the installation, so you install foo after installing spatialdata to sidestep this problem. But now you've not only gotten rid of the shared dependency resolution around anndata but also every other shared package between spatialdata and foo for which there are some sort of restrictions. As far as packages go, anndata's "breaking" minor version bumps are generally not that bad. But what if foo bounds dask in a way that installs one of the broken dask-dataframe versions (which are excluded by spatialdata)? That is very nasty!
  -spatialdata goes back to the old 0.9.1 low bound: The above situation doesn't happen, so that is an improvement. But to address your point, let's say foo has anndata<0.12.5 i.e., before the pandas bound. In this case pip install spatialdata foomight give pandas>=3 if no other dependencies have the upper bound - but then you can just add a constraint to the installation! That is resolvable! The above situation is not though.

This is my reasoning.

[LucaMarconato]

True that's a good argument, let's go with case 2 then. Thanks for chiming in!