Skip to content

py-h5py: add 3.8.0#35960

Merged
adamjstewart merged 1 commit intospack:developfrom
michaelkuhn:py-h5py-3.8.0
Mar 31, 2023
Merged

py-h5py: add 3.8.0#35960
adamjstewart merged 1 commit intospack:developfrom
michaelkuhn:py-h5py-3.8.0

Conversation

@michaelkuhn
Copy link
Copy Markdown
Member

No description provided.

takluyver
takluyver previously approved these changes Mar 9, 2023
Copy link
Copy Markdown
Contributor

@tldahlgren tldahlgren left a comment

Choose a reason for hiding this comment

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

Confirmed the sha256.

@adamjstewart
Copy link
Copy Markdown
Member

Also being updated in #35195

@michaelkuhn
Copy link
Copy Markdown
Member Author

Also being updated in #35195

Should we update it separately or wait for #35195 (which seems to take a while)?

@michaelkuhn
Copy link
Copy Markdown
Member Author

@spackbot run pipeline

@spackbot-app
Copy link
Copy Markdown

spackbot-app bot commented Mar 10, 2023

I've started that pipeline for you!

@adamjstewart
Copy link
Copy Markdown
Member

I'm fine with updating it separately but this PR is missing some of the changes in the other PR (upper bounds on dep versions, etc.). If you want to steal them from that PR go ahead.

@michaelkuhn
Copy link
Copy Markdown
Member Author

I've pushed a new version that should now also include the correct upper bounds. I've left the setuptools@61: dependency commented out since that seems to cause problems for @kwryankrattiger.

@kwryankrattiger
Copy link
Copy Markdown
Contributor

I am okay with it being separate, I wasn't too thrilled about updating it in #35195 since it is outside of the scope of the changes in there.

@michaelkuhn michaelkuhn force-pushed the py-h5py-3.8.0 branch 2 times, most recently from 4cd1d12 to 40c13ec Compare March 11, 2023 18:53
@takluyver
Copy link
Copy Markdown
Contributor

takluyver commented Mar 12, 2023 via email

@adamjstewart
Copy link
Copy Markdown
Member

In that case I'll let @michaelkuhn decide what to do. It sounds like [email protected]: should be sufficient. We don't currently use any pip/build flags to ensure that dependencies are correct, but we might in the future. If we do, I can always change this to be technically correct later.

The pinned versions are roughly the first mpi4py versions that will conveniently work for each python version.

I'm guessing this means the first version where wheels are available, not the first version that supports that Python version? If it was the latter I would add these to the py-mpi4py package so we can remove old versions when we deprecate Python versions.

@takluyver
Copy link
Copy Markdown
Contributor

I'm guessing this means the first version where wheels are available, not the first version that supports that Python version?

That would be my guess too, though I don't know that we've applied that rule completely consistently.

@michaelkuhn
Copy link
Copy Markdown
Member Author

Sorry for dropping the ball on this. I've just pushed a new version that constrains mpi4py to @3.0.2: for all 3.x versions.

Copy link
Copy Markdown
Member

@adamjstewart adamjstewart left a comment

Choose a reason for hiding this comment

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

Looks fine to me as long as the other 2 maintainers don't see any issues.

@takluyver
Copy link
Copy Markdown
Contributor

LGTM.

The precisely versioned dependencies on numpy and Cython could probably be simplified, like with mpi4py (discussed above). They're similar cases where we've found compromises between a pure theoretical description of dependencies, and what practically works for Python-native tooling. But if they're not causing an issue, you may just want to leave them as they are and not risk breaking anything.

@kwryankrattiger
Copy link
Copy Markdown
Contributor

@spackbot run pipeline

@spackbot-app
Copy link
Copy Markdown

spackbot-app bot commented Mar 29, 2023

I've started that pipeline for you!

@kwryankrattiger
Copy link
Copy Markdown
Contributor

if no objections in the next couple hours, I am going to merge this today.

@adamjstewart adamjstewart merged commit 996442e into spack:develop Mar 31, 2023
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.

5 participants