Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restrict to numpy < 2 and setuptools < 72 for better compatibiltiy with CI pipeline #213

Merged

Conversation

BenjaminRodenberg
Copy link
Member

I would suggest to restrict the numpy version to numpy<2 since the newest numpy is not well supported by our CI pipeline (see #212).

@BenjaminRodenberg BenjaminRodenberg changed the title Restrict to numpy < 2 for better compatibiltiy with CI pipeline Restrict to numpy < 2 and setuptools < 72 for better compatibiltiy with CI pipeline Aug 27, 2024
Copy link
Member

@IshaanDesai IshaanDesai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable 👍

@BenjaminRodenberg
Copy link
Member Author

Will merge this now. One review should be sufficient.

@BenjaminRodenberg BenjaminRodenberg merged commit 75da6d8 into precice:develop Aug 27, 2024
10 checks passed
BenjaminRodenberg added a commit that referenced this pull request Aug 27, 2024
…th CI pipeline (#213)

* Restrict to numpy<2 since we do not support numpy 2 yet.
* Restrict to setuptools < 72 since the "test" command was removed in Setuptools 72. See #214.
@fsimonis
Copy link
Member

fsimonis commented Sep 2, 2024

@BenjaminRodenberg I do understand these restrictions for the v2.5.1 release to keep it simple, but not for develop.

numpy 2 works fine after #204. The bindings now actively prevent downstream projects (adapters and cases) from updating to numpy 2. This is a problem.

The setuptools restriction only affects testing. The rest works fine.
If we want to test, then we could instead install a working setuptools in the CI until we have a fix.
If there are special version requirements of the spack package should be handled in the spack package.

@BenjaminRodenberg
Copy link
Member Author

@BenjaminRodenberg I do understand these restrictions for the v2.5.1 release to keep it simple, but not for develop.

numpy 2 works fine after #204. The bindings now actively prevent downstream projects (adapters and cases) from updating to numpy 2. This is a problem.

The setuptools restriction only affects testing. The rest works fine. If we want to test, then we could instead install a working setuptools in the CI until we have a fix. If there are special version requirements of the spack package should be handled in the spack package.

Thanks for the info. I was not completely aware of this connection. We then basically need the restrictions as introduced here only for pyprecice 2.x; maybe for some pyprecice 3.x releases prior to #204. For all pyprecice 3.x releases after #204 we should loosen the restriction on numpy for the reasons you already mentioned above.

I'll open an issue for this that we don't forget. With spack it's unfortunately always a bit tricky to get things working properly since I'm not that deep into spack and properly testing different configurations takes some time.

This was referenced Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants