Closed kalekundert closed 1 year ago
Thank you, @kalekundert ! I did not realize this issue.
This sould be a must-have update, but now I think it is a good time to reactivate the CI Previously the CI for py3nj was running on travis but because of the change in github I have needed to update it for a long time.
I am sorry but I pushed some files to trigger github actions.
Currently, the installation was not successful on the github-actions' server. Would you mind to update this PR so that the installation on that server becomes successful?
~I observed that with python=3.6, the installation succeeded, but not sure the reason of unsuccessful build for the newer versions.~ It seems wrong, and I should stop working on your branch.
The installation error in the CI comes from this part https://github.com/kalekundert/py3nj/blob/b968c277e9df1c9507426c8064234b1cf9e6c8aa/.github/workflows/ci.yaml#L51
It looks like that a library requires fortran compilation does not support -e
option, so we may need to remove this option.
pip install --no-deps .;
python -m pip install --no-deps .
Then, I still see an error in import py3nj
line, which complains a circular import.
It looks like that import py3nj
tries to import the directory py3nj
, not the installed package.
A possible solution would be
py3nj
directory to another name, e.g., src
package_dir
option in setup
.You can find an example for this modification in my fujiisoup:fix-install branch, but if you know better solution, feel free to ignore this.
Thanks for such a quick response. And feel free to make as many commits as you'd like to my branch.
I didn't test editable installs, so I'll have to look and see if there's a way to get that to work.
Regarding the error with the import py3nj
line, I had the same error when I was testing my PR, and I found that I could avoid it simply by changing to any other directory. That's why I didn't worry about it (although in retrospect I should've mentioned it), but I see that you found a way to avoid the error altogether by changing the source directory name. That's probably better.
Reading this F2PY build guide and #22, I realize now that the install process might break again in a few months when python 3.12 comes out. In fact, it looks like it's already possible to test with python 3.12.0-rc.1 via github actions (supported python versions), so it might be worth doing that just to see what happens.
If it doesn't work, my impression was that the meson
approach described in the above guide seemed best. Making this switch now would avoid the need to solve the setuptools-related editable install/source directory name problems. I'm gonna take a look now and see if I can get that working without too much trouble.
Thank you for the info. I think we can merge this PR for now and start working #22 based on this PR.
I will work on a ci that can run python 3.12, which may be useful for avoiding distutils
.
Trying to install
py3nj
withpip>=23.1
results in the following error:The problem is related to the fact that
setup.py
needs to be able to importnumpy
in order to create the fortran modules. This is actually an issue for all versions of pip; if you try to installpy3nj
into an environment withoutnumpy
installed, you'll get the same error message. In fact, the discussion in #17 diagnoses this exact problem, and also proposes the exact solution implemented by this PR. But it's more urgent now, because it used to be that everything would work so long asnumpy
was installed.What changed in
pip>=23.1
is that packages are now built in their own virtual environments, isolated from any user-installed packages. See the CHANGELOG, and two relevant pull requests: pypa/pip#8368 and pypa/pip#8559. This means that there's no longer any way for users to provide thenumpy
dependency (note that installingnumpy
beforepy3nj
in the above snippet didn't avoid the error), sopy3nj
needs to tell pip to include it in the build environment. This is done using the[build-system]
section of thepyproject.toml
file.While I was at it, I moved most of the metadata from
setup.py
topyproject.toml
, and got rid of the now-redundantsetup.cfg
. I think this is considered best-practice, because it's easier for third-party tools to extra project metadata from TOML files than python scripts. I also noticed thatsetup.py
specified a BSD 3-clause license, while the actualLICENSE
file in the repository contains the Apache license. I assumed that thesetup.py
file was wrong, and changed it to just reference theLICENSE
file.