xraylib
xraylib copied to clipboard
Provide builds for alternate python versions on RHEL / CentOS
RHEL / CentOS started to provide multiple python versions a while ago in their AppStream repo. For example on RHEL 8, they offer python36, python38 and python39 [1].
Centos Stream (which we use) provides 3 versions of numpy:
$ dnf search python3*-numpy
Last metadata expiration check: 0:04:55 ago on Thu 02 Sep 2021 02:29:28 PM CEST.
========================== Name Matched: python3*-numpy ===========================
python3-numpy.x86_64 : A fast multidimensional array facility for Python
python38-numpy.x86_64 : A fast multidimensional array facility for Python
python39-numpy.x86_64 : A fast multidimensional array facility for Python
In contrast to the system python (without a minor version), the additional packages are updated quite often. For example python39-numpy is version 1.19.4, while python3-numpy is version 1.14.3.
Naturally, I prefer to use the newer python versions which come with the new scipy/numpy packages. However, xraylib-python is only built for the system version, which forces me to either use the dated python or to compile xraylib manually.
Would it be possible for you to provide builds for the newer python versions, too?
Thanks in advance!
[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_installing-and-using-python_configuring-basic-system-settings
Don't think I will start supporting multiple Python versions again now that I managed to get rid of the Python 2.7 builds: this makes the SPEC file a lot neater. I don't think that there are many people using these RPM packages anyway.
In your case, I would recommend using an Anaconda/Miniconda installation: xraylib packages are available from the conda-forge channel.
That is understandable. Would you consider supporting the latest available version instead of the "system" python version, then? Technically, the system python version is intended for the distro scripts.
Anaconda is not really an option for us. The rpm and, when needed, a venv with pip works like a charm so there is no need to pull in another layer of complexity.
That is understandable. Would you consider supporting the latest available version instead of the "system" python version, then? Technically, the system python version is intended for the distro scripts.
That seems difficult, as the supported python version would then become a bit of a moving target.
I am not really familiar with the AppStream modules stuff, but if you would find a way to integrate that into the current spec file I will gladly take a look at it.
Nowadays, I barely have time to work on xraylib and my other old projects, as I have left the X-ray spectrometry field two years ago now, and I am unlikely to ever go back to it...
I am not really familiar with the AppStream modules stuff, but if you would find a way to integrate that into the current spec file I will gladly take a look at it.
I will try to make it work and open a pull request when I succeed.
Nowadays, I barely have time to work on xraylib and my other old projects, as I have left the X-ray spectrometry field two years ago now, and I am unlikely to ever go back to it...
Too bad we lost you. I really appreciate that you still work on xraylib, though!
These packages are now officially deprecated, as I will not be building any DEB and RPM packages going forward. I am currently still hosting the existing ones, but I expect to take these down in the not too distant future.