py-numpy 2.0.0

[Marius Schamschula]

And py-tifffile 2024.6.18

My list is getting longer!

> On Jun 18, 2024, at 3:08 PM, Marius Schamschula <lists at schamschula.com> 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 <lists at schamschula.com> wrote:
>> 
>> On Jun 18, 2024, at 2:39 AM, Joshua Root <jmr at macports.org> 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
>> 
>