conda-forge packages

[tkittel]

Hi there,

As discussed with @gschnabel and @marquezj some time ago, it would be useful for us to have this package on conda-forge since we try to have everything we use available there for consistency.

So I just wanted to double-check that it is OK if I go ahead and start making + submitting such a recipe, and which github usernames you want to be listed as maintainers for it (I am thinking myself and @gschnabel ... others?).

Since this is currently a pure python package with almost no dependencies, I am hoping this will be straight forward :-)

Cheers,
Thomas

[tkittel]

I started a PR on conda-forge/staged-recipes#29368

[gschnabel]

Hello, that's fine with me.

You can state you and me as maintainers and I am sure we can update this list in the future if necessary.
I only want to mention that there is a C++ module in the package whose compilation and linking is triggered during the installation procedure (e.g. using pip install ...). In practice, this means that a user can interact with the package via the EndfParser class (pure Python) or the EndfParserCpp class using a dynamic link library created during installation (or downloaded as part of the binary wheel from PyPI). If possible, it will be nice to have this C++ component also on conda-forge as it speeds up most operations by a factor 50x - 300x. Even though the package is fully functional without the C++ dynamic link library, the speed up is large enough to significantly improve the user experience (especially using the package in an interactive shell).

[tkittel]

Yeah, I noticed after my first attempts at making a pure python package failed :-)

I believe it is indeed building the C++ module, but we should verify the output once the CI finishes. Can we continue the discussion about the details on conda-forge/staged-recipes#29368 ?

[tkittel]

So I guess this was done now :-)

https://anaconda.org/conda-forge/endf-parserpy/files

Hopefully the condaforge bots will automatically detect (within a few hours) when in the future you create a new vx.y.z version tag here. The only thing that usually require manual update is if you update your dependencies or something like that.

[gschnabel]

Thank you @tkittel for going through the procedure. It can be indeed installed now using the conda package manager. :-)

I realized that the endf-parserpy conda package only supports Python 3.12 because the binaries have been built using this version in the conda-forge build environment. I believe it should be possible to build for several Python versions. It would be perfect if we could do that for Python versions starting from 3.8 up to the most up-to-date one supported by conda-forge to match the specification in the pyproject.toml file. If that's easy for you to do, could you do it? Otherwise, I can also try to look into this.

Regarding the meta.yaml required for conda-forge, is it good practice to keep this file in the repo of the package? I failed to find it in the repos hosted at conda-forge (apart from going to your PR there).

[tkittel]

Right, I see the problem. I will see if I can rectify the recipe and get the packages updated!

[tkittel]

Working on this in: conda-forge/endf-parserpy-feedstock#4

[tkittel]

Sorry, I missed your question:

Regarding the meta.yaml required for conda-forge, is it good practice to keep this file in the repo of the package? I failed to find it in the repos hosted at conda-forge (apart from going to your PR there).

So since the original PR was accepted, we have now gotten a dedicated feedstock repo for the meta.yaml recipe:

https://github.com/conda-forge/endf-parserpy-feedstock

The file recipe/meta.yaml is actually more or less the only file in that repo that we will ever touch, all the other files are updated when we create a PR and trigger a "rerendering" as you can see I just did in conda-forge/endf-parserpy-feedstock#4 . On a normal release of your package (e.g. next time you push the v0.13.0 tag presumably), we could go and make a manual PR where we would update just the release number and tarball SHA checksum in recipe/meta.yaml. However, I have enabled that the bots will do that automatically for us (still, when you do a new release try to keep an eye on anaconda.org and watch that you have new packages there after a few hours - otherwise ping me).

And one word of caution: Never ever push directly to https://github.com/conda-forge/endf-parserpy-feedstock, and never create branches in that repo, because that breaks the conda-forge system. Always go through PRs from private forks if needed to e.g. update dependencies. Also, if (like I just needed to) we need to fix packages for a particular version where packages were already released, the build number in meta.yaml can be increased (so I just set the build number to 1 in my new PR).

That is more or less the most important things I believe :-)

[tkittel]

So I believe the issue is now fixed and there are packages for all the conda-forge python versions (3.9,3.10,3.11,3.12) published:

https://anaconda.org/conda-forge/endf-parserpy/files

I also went through the steps previously to ensure that osx-arm64 packages are built. I could also enable linux-aarch64 packages, but the CI is a bit slow for those.

[gschnabel]

Thanks @tkittel, also for explaining the feedstock repo update procedure. Now everything works as expected.

[tkittel]

FYI @gschnabel there are now also python 3.13 packages for endf-parserpy on conda-forge (some bot handled it, I just had to merge the PR).