Transition to pyproject.toml; pin numpy > 2

[austin2118ace]

I ran into an issue integrating oasis into our processing pipeline as we use numpy > 2. This caused issues when importing oasis as the PyPa oasis wheels were built against numpy < 2

To approach automatic wheel building for our use case, and to make the package compliant with PEP 518 and PEP 621, I moved most of the information out of setup.py into pyproject.yaml. I also pinned numpy > 2 so the wheels will be built against the newest headers and make oasis compatible with newer code. setup.py is still required for building the extension, as the pyproject.toml spec only has experimental support for building extensions, and I didn't want to stray too far from the known working build environment.

An additional note is that cvxpy==1.6 typically gets pulled during the install. This generates some warning messages about depreciated syntax as of version <1.1, but the code still appears to work as intended.

All Github CI builds succeed, and my local runs of the provided test code succeed without issue. I am able to build the package using PyPa build and Astral's uv build both of which invoke setuptools. The resultant wheel then is installable with no errors and oasis can be imported successfully.

Using pip install -e . (which automatically builds extensions) succeeds. Further, manually building with python setup.py build_ext -i and then running pip install . also works.

I figured I would share these changes with you in case you were interested in applying them to the main repository.

Cheers!
Austin
Dewan Lab
Florida State University

[j-friedrich]

Thanks @austin2118ace. I figured at one point I should modernize my setup.py based project, looks like you did that work for me :).

Since the previous version on conda-forge only supported Python ≤3.10, I finally released v0.2.1 on PyPI and conda-forge a few days ago. For conda-forge, it built successfully on Linux, macOS, and Windows using Python 3.9–3.13. I’m curious if pinning NumPy to >=2 would interfere with this build.

What OS and installation process did you use that caused issues? Did you clone the repo and compile from source?

With your changes, would the "Compile from source" section in the README now simply look like this?

git clone [email protected]:j-friedrich/OASIS.git
cd OASIS
pip install -e .

[austin2118ace]

@j-friedrich

I was building using 3.10 I believe, but using numpy > 2 passed all the Github CI build tests using my files.

TBH, it was a while ago and this upgrade was a adhd-fueled on-a-whim project, so I don't remember exactly what our issue was. All I am certain of is that importing oasis when numpy>2 was causing an import error (wasn't just a warning) due to some mismatches in expected variable size I think. I fairly certain we were using the version on conda to avoid the hassle of compiling the extension. Wish I had better info for you unfortunately.

However, Yes! pip install -e . will automatically build the extension and the install the directory as a package. You can also use the following:

1. Build the extension separately and the install the local package python -m build followed by pip install . (no -e)
2. Old method: python setup.py build_ext -i followed by pip install .
3. I really like using uv as a tool for most of my python stuff, if you haven't seen it yet I highly recommend checking it out. It is build-backend agnostic as far as I know, so it dynamically detects your build settings and makes it happen. uv build followed by pip install .
4. uv pip install . also works as it installs local packages with the -e flag as default, so the behavior is the same as 1)

I'm sure there are plenty of other ways, but your recommendation is likely the simplest.
If you want to run the comparison methods, you simply have to use pip install -e ".[comparison]" to install cvxpy and the other needed packages.

[austin2118ace]

@j-friedrich Hi! Just checking in to make sure you saw my last comment. Cheers :)