New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use setuptools_scm, fix packaging bugs, and update docs #278
Conversation
Setuptools needs to use the proper version of numpy (which now must be >1.20) while building the project, or we'll get C errors on import. For more details, see: - scikit-learn-contrib/hdbscan#457 (comment) - https://stackoverflow.com/questions/66060487/valueerror-numpy-ndarray-size-changed-may-indicate-binary-incompatibility-exp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Andrew thanks so much for working on this. I read through this issue:
pretty carefully and concluded that what we want--optional build dependencies--is not supported by pyproject.toml.
TBH this seems like a huge rabbit hole of complexity.
So for now, I am fine with simply requiring pyfftw as a hard dependency. Going forward, maybe we can find a way to make it optional again.
After merging this, I just tried pip installing from git
I am puzzled by the fact that pyfftw was not installed. And then it turns out that pyqg is not actually importable.
|
Definitely puzzling. From this issue, here's one hypothesis: maybe I can make a PR / branch which implements that change, and maybe |
Ah ok so you're saying it got the dependencies from here: Lines 60 to 64 in 3b6b15c
It feels a little redundant to have to specify both. I guess this is why people hate python packaging? 🙃 |
A plausible hypothesis 🙃 |
|
(We might run into one more issue with numpy where setup requires a slightly older version numpy (1.20) even if the actual library is run with a later one -- if so we can update setuptools even further. So if that command doesn't work immediately I'll work on a more complete debugging later today or tomorrow.) |
This should resolve #277, #216, and #276, and hopefully make it so downloading/uploading pyqg to/from pypi just works (though there's a potential issue with pyfftw vs. np.fft which I'll detail below). I've tested it using testpypi but I'm holding off deploying to the main pypi repository until we've gotten this merged and updated whats-new.rst (PR to follow).
I alsoI think I've resolved this issue by just upgrading all of the doc dependencies.suspect I mightdefinitely have an issue building the docs, butwe'll see what happens when this PR triggers a new buildI'll fix that soon.One other potential issue is that we lose the flexibility we previously had around
pyfftw
vs.np.fftw
. In order for plain oldpip install pyqg
to supportpyfftw
(which I think we should want as the default), we need to specify it inpyproject.toml
. But, this means users have to download it to install or run pyqg (unless they want to install pyqg by cloning the repository and doing a local install), which makes it effectively a requirement (that also required updating CI to only run tests using it).Another option is to omit
pyfftw
frompyproject.toml
but tellpyfftw
users to runpip install pyqg --no-build-isolation
. That feels a bit wonky though.