And py-tifffile 2024.6.18 My list is getting longer!
> On Jun 18, 2024, at 3:08 PM, Marius Schamschula <[email protected]> wrote: > > Yet another one: > > I pushed a PR for py-cartopy 0.23.0 only to be reminded by CI that it needs > py-numpy 2.0.0. > >> On Jun 18, 2024, at 5:40 AM, Marius Schamschula <[email protected]> >> wrote: >> >> On Jun 18, 2024, at 2:39 AM, Joshua Root <[email protected]> wrote: >>> >>>>> /Would introducing a py-numpy2 port be a possible solution? />//>/Nils. / >>>> >>>> Unfortunately, that’s not how python packages work. >>>> >>>> They need to install into the same directory spaces as to be available for >>>> other packages, e.g. >>>> >>>> /opt/local/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/numpy >>>> >>>> Marius >>> >>> I really don't understand why python projects don't change the module name >>> when there's a major API break, given that there's no way to have multiple >>> versions of a module installed and pick which one to import (at least not >>> without custom code messing with importlib). Even if you install all your >>> deps in a venv, you have to somehow make sure nothing wants numpy 1 if >>> anything wants numpy 2. >>> >>> Even installing one of the versions somewhere else and adding that location >>> to sys.path isn't a good solution. If it's always there then dependents >>> will still get whichever version is found first in sys.path, so all >>> dependents that need it would have to be patched to add the sys.path entry. >>> And even then, it would be a constant struggle to ensure that nothing those >>> modules import needs the other numpy version. >>> >>> - Josh >>> >> >> >> They think they have a mechanism: virtual environments: what a mess! >> >> Marius >> >
