Skip to content

py-pyevtk: new package#4942

Merged
RikkiButler20 merged 3 commits into
spack:developfrom
tpadioleau:add-pyevtk
Jun 18, 2026
Merged

py-pyevtk: new package#4942
RikkiButler20 merged 3 commits into
spack:developfrom
tpadioleau:add-pyevtk

Conversation

@tpadioleau

Copy link
Copy Markdown
Contributor

A word of caution, the project PyEVTK comes originally from https://github.com/paulo-herrera/PyEVTK but was packaged and uploaded on PyPi from the fork https://github.com/pyscience-projects/pyevtk. I don't know how the Spack package should handle this. Also the license of the fork is not clear to me.

@tpadioleau

Copy link
Copy Markdown
Contributor Author

Pinging @renefritze and @xylar if they want to say a word

@xylar

xylar commented May 26, 2026

Copy link
Copy Markdown
Contributor

Hi @tpadioleau

The pyscience-projects/pyevtk fork exists primarily because the original author (Paulo Herrera) had been hosting PyEVTK on Bitbucket and was largely unavailable for collaboration. When contributors wanted to get the package onto PyPI and conda-forge, and needed fixes (notably Python 3 compatibility), they created this fork to be able to make releases independently. Paulo was eventually looped in and gave his blessing, but preferred to keep his own repo for his own use and left the PyPI/conda-forge maintenance to the fork maintainers.

The practical upshot for a Spack package is that the pyscience-projects fork is the canonical source for PyPI releases and has received the most packaging-related maintenance, Python 3 fixes, and community contributions. Pointing Spack at the original paulo-herrera/PyEVTK repo would mean tracking a repo that doesn't cut versioned releases in a coordinated way, whereas the fork has been the de facto distribution point for downstream consumers. Your note about the license being unclear on the fork is worth following up on, but the fork is otherwise the right source to use if you want to match what pip install pyevtk actually delivers.

A lengthy but relevant discussion from over 7 years ago can be found here: pyscience-projects/pyevtk#7

@tpadioleau

Copy link
Copy Markdown
Contributor Author

@xylar Thank you very much for your prompt reply. Then I think it makes sense to update the homepage to be in accordance with the release numbering.

When looking for dependencies, I extracted them from the pyproject.toml of https://github.com/paulo-herrera/PyEVTK. Are the dependencies still the same in https://github.com/pyscience-projects/pyevtk ?

Also do you feel like being co-maintainer of this Spack package ?

@spackbot-triage spackbot-triage Bot added new-package Additions of new packages to the Spack ecosystem new-version Modifications to packages' `depends_on()` directives python dependencies Modifications with a `depends_on()` directive labels May 26, 2026
@xylar

xylar commented May 26, 2026

Copy link
Copy Markdown
Contributor

Sure, I would be happy to be a co-maintainer.

Let me follow up in a moment on the dependencies. I have a meeting to attend right now.

@xylar

xylar commented May 26, 2026

Copy link
Copy Markdown
Contributor

Looking at the conda-forge package (https://github.com/conda-forge/pyevtk-feedstock/blob/main/recipe/recipe.yaml), it seems like what you have is right. We have some other build-time dependencies there but I would be surprised if they're required.

Update: I think versioneer might in fact be required at build time. It seems to be on spack already.

@xylar

xylar commented May 26, 2026

Copy link
Copy Markdown
Contributor

Regarding the license, I think we just weren't aware of Paulo Herrera having made that switch. I have pulled over his license changes to our fork in pyscience-projects/pyevtk#44. We'll try to get that in soon and figure out making a new tag.

@tpadioleau

Copy link
Copy Markdown
Contributor Author

Sure, I would be happy to be a co-maintainer.

Thank you very much!

Update: I think versioneer might in fact be required at build time. It seems to be on spack already.

Sure, will update

Regarding the license, I think we just weren't aware of Paulo Herrera having made that switch. I have pulled over his license changes to our fork in pyscience-projects/pyevtk#44. We'll try to get that in soon and figure out making a new tag.

Sure, do you think we can let MIT in the Spack package ?

@xylar

xylar commented May 26, 2026

Copy link
Copy Markdown
Contributor

Sure, do you think we can let MIT in the Spack package ?

Yes, I think we should. I just made a PR to update the license in the the fork:
pyscience-projects/pyevtk#44

I have a follow-up PR to clean up the dependencies in the pyproject.toml:
pyscience-projects/pyevtk#45

@tpadioleau

Copy link
Copy Markdown
Contributor Author

Sure, do you think we can let MIT in the Spack package ?

Yes, I think we should. I just made a PR to update the license in the the fork: pyscience-projects/pyevtk#44

Great!

I have a follow-up PR to clean up the dependencies in the pyproject.toml: pyscience-projects/pyevtk#45

Thx, I now see:

[build-system]
requires = ["setuptools>=61", "wheel", "versioneer[toml]>=0.29"]
build-backend = "setuptools.build_meta"

are there dependencies and versions necessary for version 1.6.0 or only for the upcoming release ?

@xylar

xylar commented May 27, 2026

Copy link
Copy Markdown
Contributor

Those versions apply to 1.6.0.

Sorry, not true. I think those constraints are both related to pyproject.toml support so will apply to the next release.

@xylar

xylar commented May 29, 2026

Copy link
Copy Markdown
Contributor

Just a note that https://github.com/pyscience-projects/pyevtk/releases/tag/v1.7.0 has been tagged. This addresses the license and dependency issues that you brought up, @tpadioleau. But I also think it would be fine to add that version after this PR goes in so that it isn't a moving target for reviewers. Up to you.

@tpadioleau

Copy link
Copy Markdown
Contributor Author

Just a note that https://github.com/pyscience-projects/pyevtk/releases/tag/v1.7.0 has been tagged. This addresses the license and dependency issues that you brought up, @tpadioleau. But I also think it would be fine to add that version after this PR goes in so that it isn't a moving target for reviewers. Up to you.

Fine for me. Is the current version of the package ok for you ? We can then let spack devs do their final review.

@xylar xylar left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@tpadioleau, yes looks good to me.

@alecbcs alecbcs changed the title PyEVTK: new package py-pyevtk: new package Jun 2, 2026
@tpadioleau tpadioleau mentioned this pull request Jun 10, 2026

@RikkiButler20 RikkiButler20 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Looks good to me.

@RikkiButler20
RikkiButler20 merged commit 1416b32 into spack:develop Jun 18, 2026
33 checks passed
@RikkiButler20 RikkiButler20 self-assigned this Jun 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Modifications with a `depends_on()` directive new-package Additions of new packages to the Spack ecosystem new-version Modifications to packages' `depends_on()` directives python

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants