Incorrect Python version requirement for orix release 0.13.3 in conda-forge metadata?

[gsparks3]

When installed using conda, orix release 0.13.3 seems to specifically require Python 3.10, rather than what I assume was intended to be a range from 3.10-3.12 (as the release notes for release 0.13.1 indicate that support for Python 3.12 was added, and support for Python 3.8 and 3.9 was removed).

When creating an environment, if I specify both Python 3.12 and orix 0.13.3, I get this message:

If I specify only orix 0.13.3, conda successfully creates an environment using Python 3.10, which is apparently the latest compatible Python version according to the environment solver.

If I create an environment with orix (without specifying the version of orix or Python), conda selects orix 0.13.2 and Python 3.12 (avoiding the latest orix release in order to use a later Python version).

Orix 0.13.1 and 0.13.2 both seem to allow use of Python 3.12; not sure why there was a regression in release 0.13.3.

[CSSFrancis]

That's a bit strange. It should be that the minimum is set to 3.10.

For reference this is defined here: https://github.com/conda-forge/orix-feedstock/blob/main/recipe/meta.yaml

The python_abi package should be installed with the python version. Hmmm I'm a little confused

[CSSFrancis]

@gsparks3 Can you try:

conda create -n test python==3.12 orix-base==0.13.3

[CSSFrancis]

@hakonanes This is probably because of numpy-quaternion right?

[hakonanes]

Hi @gsparks3 (and @CSSFrancis),

Thank you for raising this issue. The solution is to install orix-base: conda create -n ox-dev python=3.12 orix-base=0.13.3.

This is listed as an option in our installation guide, https://orix.readthedocs.io/en/stable/user/installation.html#with-anaconda.

We can confirm that numpy-quaternion is the issue

mamba create -n ox-dev python=3.12 numpy-quaternion
conda-forge/noarch                                          Using cache
conda-forge/osx-arm64                                       Using cache
default/noarch                                     116.0 B @ 482.0 B/s  0.0s
default/osx-arm64                                  125.0 B @ 269.0 B/s  0.2s

error    libmamba Could not solve for environment specs
    The following package could not be installed
    └─ numpy-quaternion =* * does not exist (perhaps a typo or a missing channel).
critical libmamba Could not solve for environment specs

We should add an "info" admonition to the Anaconda part of the installation guide mentioning this.

[CSSFrancis]

@hakonanes would it be worth it to pull numpy quaternion entirely?

I know it's a small slow down but this problem is only going to get worse.

Or have the default be what is now orix-base and then have an orix-fast option as well

[hakonanes]

Or have the default be what is now orix-base and then have an orix-fast option as well

That is a good option, having:

• orix: bare minimum
• orix-all: all dependencies

Two options should be enough. If people only want to have some of the optional dependencies (not all), they can install the ones they want.

[argerlt]

Just my two cents, I would rather have

- orix: all the normal extras, including numpy-quaternion
- orix-fast: orix minus the packages that occasionally go out of date.

I recently did PR #555 to address a similar issue with matplotlib-scalebar, and while i do think it was good to have a version of ORIX that works even when dependency problems occur, it didn't sit well with me that such a useful package got taken out of the default branch because it was out of date for (I think?) two weeks.

That said, I could go either way. I'm familiar enough with ORIX that switching from orix toorix-all isn't going to affect me; this is just me thinking about the experiences of future users.

Actually, coming back to this, I would prefer @hakonanes suggestion.

[gsparks3]

gsparks3 Can you try:

conda create -n test python==3.12 orix-base==0.13.3

I can confirm that using orix-base instead of orix works, so it seems the issue is indeed one of the dependencies.

However, numpy-quaternion does not seem to be the actual issue - the name for this package on conda is quaternion, not numpy-quaternion (the latter is used on PyPI), and quaternion seems to install just fine with Python 3.12 (although I had to use no-default-packages to stop my condarc from interfering with testing).

If I try to use conda to search for or install numpy-quaternion, it fails to find the package as shown in @hakonanes comment above, since no package with that name exists on conda-forge.

[hakonanes]

You're right, sorry for the misleading comment, @gsparks3. The quaternion package installs without issues. Then I don't know what causes the error. The only difference in orix and orix-base is the quaternion package: https://github.com/conda-forge/orix-feedstock/blob/262a9f1421095602cd7d0ddd82fde54a174af047/recipe/meta.yaml#L75-L76

[gsparks3]

The only difference in orix and orix-base is the quaternion package.

Given the above, and that both orix-base and quaternion have no issues with Python 3.12 when installed independently, I suspect an error snuck into the meta.yaml file somehow. It works in orix 0.13.2, and doesn't work in 0.13.3. My guess is that it's something in this commit. There are only two commits between 0.13.2 and 0.13.3, and the other one is so minimal I have a hard time imagining it would have any effect here.

Notably, in several places that first commit replaces either - python or - python >=3.10 with - python {{ python_min }} (plus an earlier {% set python_min = '3.10' %}), which would seem to imply a strict requirement for Python 3.10. However, those are all under either host or test headers; the run header still uses - python >={{ python_min }}, so I am unsure if this is actually meaningful. This goes double given that the orix-base install works just fine with Python 3.12 under orix 0.13.3, and has the same replacements to its host and test headers as orix does in that metadata file. Maybe something changed in the conda-forge parsing engine?

[hakonanes]

Thanks for looking into the commits. It may be that building the package with Python 3.10 is different from building with 3.11 or 3.12, I don't know.

Let's leave this open until we've tried to make a new conda-forge release.