anaconda channel requires a license

[jjv5]

We believe the "anaconda" channel, specified in the environment yaml files for installation, now requires a license to use at organizations of more than 200 people.

Is there any chance a new installation method will be developed to sidestep this issue? At the very least this would involve not using the "anaconda" or "defaults" channels.

Our preference would be to port the whole thing to pixi.

[jjv5]

It also seems like the Intel channel is non-functional. Perhaps that is under the same license also.

[sroet]

Hey @jjv5,

Thanks for noticing!

Is there any chance a new installation method will be developed to sidestep this issue?

Would https://github.com/SBC-Utrecht/PyTom/blob/master/environments/pytom_full.yaml be suitable enough for you? it only requires the conda-forge channel (and is the one we propose to be used as installation in our current readme)

[jjv5]

Thanks for your quick response. I guess I misread the install instructions. Using pytom_full.yaml works nicely with pixi:

pixi init --import pytom_full.yaml

This completes first try.

[jjv5]

Just to clarify, I went to the Installation Wiki: https://github.com/SBC-Utrecht/PyTom/wiki/Installation

which shows using the other environment yaml files.

I did this because there is a link to it from the main readme.

[sroet]

Thanks for that pointer, will rewrite the wiki instructions to match the readme ones!

[sroet]

I have updated the wiki page to include the current install instructions. Thanks again for reporting, and feel free to reopen if you feel this issue has not been solved

[jjv5]

Install with pytom_full.yaml on a Rocky 9 system fails to start the compilation step because an include file is not found:

exe paths: ['/programs/x86_64-linux/pytom/1.1_jim_a9b/miniconda3/envs/pytom_env/bin', '/programs/x86_64-linux/pytom/1.1_jim_a9b/miniconda3/envs/pytom_env/bin', '/programs/x86_64-linux/pytom/1.1_jim_a9b/miniconda3/condabin', '/nfs/builders/sbgrid/bin', '/usr/X11R6/bin', '/programs/x86_64-linux/lmod/8.3/lmod_extlib/lmod-8.3-ydyz/lmod/8.3bin', '/usr/local/bin', '/usr/bin', '/usr/local/sbin', '/usr/sbin', '/programs/share/sbgrid/bin', '/build/bin'] lib paths: ['/programs/x86_64-linux/pytom/1.1_jim_a9b/miniconda3/envs/pytom_env/lib'] include paths: ['/programs/x86_64-linux/pytom/1.1_jim_a9b/miniconda3/envs/pytom_env/include', '/programs/x86_64-linux/pytom/1.1_jim_a9b/miniconda3/envs/pytom_env/include'] Searching : mpicc Found : True Searching : mpic++ Found : True Searching : libmpi.so Found : True Searching : mpi.h Found : True Searching : Python.h Found : True Searching : libpython3.12.so Found : True Searching : fftw3.h Found : True Searching : libfftw3.so Found : True Searching : type_traits.hpp Found : True Searching : ndarrayobject.h Found : False Searching : ndarrayobject.h Found : False Numpy include path not found! running build running build_py creating build creating build/lib creating build/lib/pytom

I can find ndarrayobject.h i the miniconda install but it is not part of the compile include directories apparently: find ./ -name ndarrayobject.h ./miniconda3/envs/pytom_env/lib/python3.12/site-packages/numpy/_core/include/numpy/ndarrayobject.h Before I go off manually trying to fix this, is it perhaps a known issue, some simple thing I'm overlooking? The miniconda install completed without errors.

[sroet]

Hmm, that should have been cough by these lines, but it seems like numpy changed their internal structure from core to _core, do you by any change know when that happened?

[sroet]

Seems like this was part of the numpy 2.0.0 release, we should probably move to numpy.get_include anyway

EDIT: this function first appears in numpy 1.18 and is well within SPEC0 dropping range, so we should push the minimum numpy version

[jjv5]

The change from numpy.core to numpy._core was introduced in NumPy 2.0, which was a major release with significant changes to the library's structure and API. This change was part of a broader effort to refine NumPy's Python API and improve its internal organization.Key points about this change:

1. The renaming of numpy.core to numpy._core was implemented as part of NumPy's 2.0 release

. This change was motivated by the desire to make the core namespace officially private, indicating that users should not directly access members from this submodule . The renaming affected both downstream libraries and NumPy's internal C code .

• To maintain backwards compatibility, NumPy 2.0 implemented several measures:A stub module that replicates numpy._core was created to ensure objects compiled with NumPy 1.x continue to work with NumPy 2.0

. A fallback import mechanism was implemented to handle different versions of NumPy at runtime . Special handling was added for pickle file compatibility

Users are advised to access NumPy functionality through the main np namespace rather than directly from _core . On Aug 22, 2024 at 9:48 AM -0400, Sander Roet @.***>, wrote:

Seems like this was part of the numpy 2.0.0 release, we should probably move to numpy.get_include anyway — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>