scikit-tda
define project build requirements
this will make sure that pip install the listed packages when building the project.
Because we are building a cython extension and we have to link against numpy headers the setup.py file included some checks to make sure Cython was available and deferred getting the numpy headers till building the extension.
This can be done by specifying the packages required in the build environment by relying on the PEP 517 and 518.
As of PEP 518 we have now made sure that when pip creates a virtual environment for the build it will add setuptools, wheel, cython and numpy before starting building.
We can then take the checks away and be sure that the building environment is reproducible.
Love this! I hadn't heard of PEP 518 yet, it looks like it'll greatly simplify our setup requirements. It looks like Python 3.5 isn't supported by scikit-learn anymore. Once #97 is merged, rebasing on master should fix have the failed tests.
Any idea why the travis tests are failing?
I'll look into the numpy exception from travis but the other is, as you pointed, that python 3.5.6 is not supported by the upstream project anymore so it fails building it.
Because of the build error I started poking around the cython interface (see #98)
and I have some questions. It seems like there are two ways to have cython interact
with numpy, one is using the C library definitions and one is using the python library
definitions. This is reflected in the usage of cimport vs import.
Right now I'm not sure why we are using the cimport as the only thing we care seems to be
a v.shape call which should be available in the python interface. I tried changing
from cimport to import and got some errors about types definitions for the arguments in our pyx
file. I'll take a better look later.
This brings me down to the issue at hand. During the work I also added a definition to use
a more recent numpy binary API version and this broken stuff. The issue is also documented here. I think this issue would go away if we switched to a import instead of a cimport as then the python object API would be used instead.
So right now the issue at hand seems to be: cimport is required for function signatures but
yields some binary API problems when accessing array dimensions.
The solution to this could be: we mix cimport and import and let cython figure out which is which (if it's possible) or we remove cimport and remove the issue with numpy binary API compatibility by using memory views and cython together.
I haven't investigated the second approach and it looks like there should be no performance penalties, memory views and numpy can play nicely together and the referenced memory is accessed without a copy.
Is there any blocking issue with these approaches?
Hi @edupot, sorry for dropping the ball and not getting back to your sooner!
I don't have a good answer to why for you. I think both approaches seem reasonable, so whichever one you think I would be okay with.
Thanks for this!
Also, @edoput, I just now migrated our CI/CD to gh-actions, so these issues with travis and appveyor might resolve themselves when using that system.