linux manjaro install fails

[toqduj]

perhaps related to #2416 , but when installing it on a fresh manjaro with the latest anaconda, I get the following issue:

(sasview) [brian@slab Downloads]$ sasview
Attribute Qt::AA_EnableHighDpiScaling must be set before QCoreApplication is created.
15:01:36 - INFO: Custom config path: <module 'custom_config' from '/home/brian/.sasview/config/custom_config.py'>
Traceback (most recent call last):
File "/home/brian/anaconda3/envs/sasview/bin/sasview", line 11, in
sys.exit(run_sasview())
File "/home/brian/anaconda3/envs/sasview/lib/python3.9/site-packages/sas/qtgui/MainWindow/MainWindow.py", line 112, in run_sasview
mainwindow = MainSasViewWindow(screen_resolution)
File "/home/brian/anaconda3/envs/sasview/lib/python3.9/site-packages/sas/qtgui/MainWindow/MainWindow.py", line 44, in init
from .GuiManager import GuiManager
File "/home/brian/anaconda3/envs/sasview/lib/python3.9/site-packages/sas/qtgui/MainWindow/GuiManager.py", line 54, in
import sas.qtgui.Perspectives as Perspectives
File "/home/brian/anaconda3/envs/sasview/lib/python3.9/site-packages/sas/qtgui/Perspectives/init.py", line 6, in
from .Inversion.InversionPerspective import InversionWindow
File "/home/brian/anaconda3/envs/sasview/lib/python3.9/site-packages/sas/qtgui/Perspectives/Inversion/InversionPerspective.py", line 15, in
from sas.sascalc.pr.invertor import Invertor
File "/home/brian/anaconda3/envs/sasview/lib/python3.9/site-packages/sas/sascalc/pr/invertor.py", line 29, in
from .p_invertor import Pinvertor
File "/home/brian/anaconda3/envs/sasview/lib/python3.9/site-packages/sas/sascalc/pr/p_invertor.py", line 16, in
class Pinvertor(object):
File "/home/brian/anaconda3/envs/sasview/lib/python3.9/site-packages/sas/sascalc/pr/p_invertor.py", line 18, in Pinvertor
x = np.empty(0, dtype=np.float)
File "/home/brian/anaconda3/envs/sasview/lib/python3.9/site-packages/numpy/init.py", line 284, in getattr
raise AttributeError("module {!r} has no attribute "
AttributeError: module 'numpy' has no attribute 'float'

[llimeht]

Yes, that's the same thing I've patched as linked in #2416. (You could apply that patch to check that there are no further numpy 1.24 issues)

[pbeaucage]

@toqduj - is this sourcing sasview from the conda package? If so, can you try to pin numpy earlier and see if the environment still solves OK? conda install numpy<1.24 ought to do it.

If so, the fastest patch for this is for me to add such a version pin to our conda package. That should provide an immediate fix for 5.0.5 while we wait for patches to be applied in the next release.

[llimeht]

Let's not start pinning dependencies when trivial patches exist. Pinning dependencies needs to be the last resort for when it is impossible to work around compatibility problems otherwise we get very quickly entangled in incompatible pins.

[pbeaucage]

I think we're talking past each other. I'm NOT proposing to add such a pin to sasview main or 5.0.6. I'm proposing that we change the conda-forge package metadata (NOT main project, not pypy, etc), for sasview release 5.0.5 (which is over a year old at this point, I believe), to reflect the fact that it is incompatible with numpy>=1.24. Obviously no matter how trivial or not patching the future releases is the answer, not pinning, 100% agreed there. Given the release cadence of the project, we have a lot of users now who will install this and get a broken environment before 5.0.6 is released. Retroactively adding patches to already released and tagged versions can't be best practice either, raises a lot of uniqueness issues with version tagging. In principle someone could checkout release 5.0.5 from git and manually pull patches in but the median user I support is challenged by doing anything other than installing a .exe or .dmg package, conda install sasview is already a stretch. conda-forge has rich tools for incrementing the package build parameters and environment without changing the package version - in fact, many c-f packages are maintained by people other than the package authors and thus the specification of c-f dependencies is totally decoupled from the main package deps and release cycles to allow these changes. On a side note, there is much lively and constructive debate on this topic (how tightly to specify dependencies) with many valid viewpoints, but helping users avoid known incompatibilities in existing releases seems pretty clear-cut.

On a side note, I'm sure it isn't your intention but I've noticed that your comments in these discussions often read as fairly curt and at times stray into condescension. This project does not have a code of conduct but I might suggest taking a look at that of SciPy. We're both here volunteering our time because we care about this project and the broader Open Source community. I'm certain we both have things that we know well and things we don't know. I have spoken with potential sasview contributors who work in other Python spaces who have been put off by this sort of tone around sasview specifically. I hope we can agree that the project and community would be stronger if we all took a little extra effort to be kind and welcoming.

[llimeht]

You are right on all the above points. I normally wander away from sasview (for a period of months) when it gets too frustrating, precisely so that I don't inject grumpiness into the conversations.