conda-forge recipe for xraylarch

[maurov]

@newville I would like to maintain a conda-forge recipe for xraylarch (from PyPI via grayskull). I am ready to make a pull request (to conda-forge):

https://github.com/maurov/staged-recipes/blob/xraylarch/recipes/xraylarch/meta.yaml

For those who want to use Larch with Wx (and Jupyter), this would be as simple as conda/mamba install -c conda-forge xraylarch. This way we do not need to hard code single conda/mamba packages in .github/workflows and in the install scripts.

Do you have anything against it?

[newville]

@maurov it's OK with me to try to do this. I gave up maintaining conda packages, though I do sort of help out with existing conda-forge recipes for some packages, but those are relatively easy. I would suggest going through a few development cycles with it before committing to the idea.

Personally, I would much rather support pip install xraylarch.

It is fine with me to experiment with github workflows.

[maurov]

@newville thanks for being open to this. I will give it a try and will see how it goes. For now, nothing will change in the Larch distribution.

[maurov]

@newville I started the pull request of the recipe

conda-forge/staged-recipes#23026 (comment)

but the automatic bot tells me there is already a conda-forge recipe for xraylarch, so... I am puzzled. Did you do already it?

[newville]

@maurov @mrakitin

@newville I started the pull request of the recipe

conda-forge/staged-recipes#23026 (comment)

but the automatic bot tells me there is already a conda-forge recipe for xraylarch, so... I am puzzled. Did you do already it?

Nope, I do not have anything to do with https://github.com/conda-forge/xraylarch-feedstock/

conda-forge appears to have no governance rules about ownership, participation, or even notification of feedstocks. As a result, squatting on existing projects without even notifying upstream developers is actually pretty common: this has happened to me several times before. Conda-forge and maintainers can both plausibly assert that anyone can make any recipe on any channel they like, and then also advocate "conda-forge" as community-developed. It's sort of a systemic problem.

But, maybe you want to work with @mrakitin on this. Having multiple "authors" is always a good idea.

[mrakitin]

@newville, you are always welcome to join the maintainers' team in the linked conda-forge feedstock. I mentioned it in the past (e.g., via #280). There are guidelines in fact, please check https://conda-forge.org/docs/maintainer/adding_pkgs.html#recipe-maintainer.

[newville]

@mrakitin Thanks -- I guess I thought that discussion was about what to include as dependencies in a conda recipe in general and the NSLS-II feedstock. I guess that I forgot that you proposed a conda-forge feedstock. But, to be clear, it is perfectly fine with me that you (and/or other people) want to maintain such conda packages on any repos. Or other (deb, MacPorts, etc) packages.

The point I was trying (probably poorly!) to make is that while conda-forge sort of claims to be a de-facto standard repository of Python and Python-related (and maybe other scientific computing) packages, from the "conda" point-of-view it is just another "channel", and conda-forge does not do anything specifically to contact, involve, or review who has been developing or maintaining feedstocks. It's really sort of a complaint about conda-forge and their own not-quite-publicly stated claim to be a de-facto standard.

[mrakitin]

The feedstock https://github.com/conda-forge/xraylarch-feedstock/ already exists. I've invited @maurov to the maintainers' team.

[maurov]

@mrakitin thanks for adding me to the maintainers' team. I was not aware of an existing conda-forge package for Larch, this is why I initiated one from scratch. I will check the current recipe and propose a pull request soon. I would like to get uniform conda requirements between the Larch install scripts, github workflows and the conda-forge recipe. Is that fine with you?

@newville should we update the documentation to clearly state the possibility to install larch from conda forge?

[newville]

@maurov I'm OK with adding this to the docs. I am OK with adding a test using this. I am less OK with removing tests that use pip install.

I am going to continue to insist that pip install is the preferred installation method, and that no other package manager (conda, deb, yum, MacPorts, homebrew, ....) is required. If some people want to use any of those existing environments, that is fine. Supporting pip install ought to make it clear what the dependencies are for those other package managers. We don't endorse or give special treatment to conda or conda-forge. When we distribute installers, we might use one of those -- we currently do use anaconda-based tools and environments. We don't have immediate plans to change that, but we are not committed to those tools. They are a means to reach the goal of making easy-to-use installers.

[maurov]

@mrakitin I have been trying installing larch via conda-forge lately on various Linux (or Windows WSL) machines and unfortunately it never worked for me! Does it really work for you?

[maurov]

I put some news here. With the help of @t20100 we are advancing in packaging a working xraylarch package on conda-forge.

conda-forge/xraylarch-feedstock#25

Related:

• use --no-build-isolation to fix version seen by pip conda-forge/wxmplot-feedstock#16
• Build with --no-build-isolation conda-forge/wxutils-feedstock#5

@newville, we will make two packages: xraylarch-base (to use Larch as a library) and full one xraylarch with all dependencies in in