Open rkingsbury opened 2 months ago
@kbuma would you (or others very familiar with this Store) be able to investigate this and, if appropriate, open a bug report in pandas
?
This appears to only affect the OpenDataStore
, so I'm interested in opinions from @kbuma , @jmmshn , @munrojm , and @yang-ruoxi as to whether it would be less disruptive to 1) continue to allow maggma
to install with numpy 2.0 (with a broken opendatastore) or 2) revert #986 and wait on numpy 2.0 support until this is fixed.
Tagging #848 and #991 as related
i'll look into it
Thank you @kbuma !
@rkingsbury per comments in https://github.com/pandas-dev/pandas/issues/59668 "pandas does not have a released version that officially supports numpy 2.1." as of yet.
One possible path forward is to remove the open data stores (and thus the Pandas dependency) from the maggma project - we ended up using a different approach for the new builders so are not actively using these stores in MP infra. Let me know if that is an option.
Thanks @kbuma ! FWIW, I believe I saw the bug with numpy>2 < 2.1 as well. Regardless, it's helpful to know that no one (at least no one in MP) is using OpenDataStore
.
I like the idea of having some way of interfacing maggma
with pandas
eventually, so I'm hesitant to remove the class wholesale. What I suggest instead is
OpenDataStore.__init__
to use with caution, because the store is in a a deprecated / unfinished / untested state, and in particular may be incompatible with numpy 2.0+.That way we can have tests passing but allow future users to build on the nice work that went into OpenDataStore
. What do you think? If you agree, would you be able to open a PR with those changes?
Thanks @rkingsbury ! I agree with your suggestion and will look to find some time this week to put together a PR.
Since updating dependencies to allow
numpy 2.0
(#986 ), we have a test failure in the OpenData store that is being triggered bypandas
. See, for example, this failed test run.The exception raised is
The test triggering the failure is
test_update
:I did some debugging on the
resolve
function in pandas (see source code here) and determined that the number in{"level_two": 4},
is getting turned into anp.int64
and that thekey
andis_local
args to theresolve
function arenp
andFalse
, respectively.Somewhere,
pandas
is getting confused and usingnp
as a variable name. I'm not sure how or why this is happening but I have a feeling it is apandas
bug. The following may be relevant:https://github.com/pandas-dev/pandas/issues/54252
https://numpy.org/devdocs/numpy_2_0_migration_guide.html#windows-default-integer
Version
latest
Which OS?