Open ekalosak opened 12 months ago
https://github.com/SheffieldML/GPy/pull/720 Looks like tests depend on the C files, currently.
Which to me means https://github.com/SheffieldML/GPy/issues/1030 blocks this initiative.
As I have not yet digged sufficiently deep into the entire cython & generated c code stuff, I have a rather practical proposal that might give us a little bit more insight: Lets check out how the pip install GPy
times are actually looking like when we remove the generated C code? Maybe its not as bad as expected?
However, its your last point thats more tricky and might be difficult to test before releasing it to the public.
We can start with a branch in PR marked [DRAFT], that will make it available early to beta testers ASAP.
Then we probably will have to update the CI. Come to think of it... nose upgrade doesn't block this. I think we instead only need to update the pre-test build to include generating the C on the CI host. But who knows, that will become clear upon investigating the CI.
I'm not planning too jump on this right now, but I am happy to chat.
From the initial discussion in PR https://github.com/SheffieldML/GPy/pull/1020 (merged), this thread is intended to be a home for discussion and implementation planning around the effort to respect newer guidance for generated C (https://github.com/cython/cython/issues/5089).
IMHO the forward compatibility concerns are valid, and are not theoretical for GPy (see PR 1020). So now we need to make sure removing the generated C doesn't dramatically impact user installation. That is, if we take out the C code, do we hit any of the following issues?
pip install GPy
becomes unbearably slow on a standard workstationpip install GPy
has new unseen build dependenciesWhat am I missing? Do we need to update tests to account for this? What's the shortest path to "done"?