Poetry packaging

[bwheelz36]

In this PR, I have recast the packaging mechanism to user poetry. This brings us line with latest python recommendations around packaging using a pyproject.toml file. Note that setup.py which we were using is considered deprecated. I have also made a few other changes:

• removed some other CI config files which aren't being used anymore
• bumped our minimum supported python version to 3.8, both in our packaging and in our CI. Note that 3.7 is now deprecated.
• bumped the minimum support scikit-learn version from >0.18 to >1.0

This PR paves the way for another change I would like to make: add a CI job for 'release' as described in #426. This would mean that when we release a package through GH releases, a version will also be automatically uploaded to PyPi.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 94.91%. Comparing base (383cb29) to head (ee7642b).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #458      +/-   ##
==========================================
- Coverage   98.70%   94.91%   -3.79%     
==========================================
  Files           8        9       +1     
  Lines         540      669     +129     
  Branches       90        0      -90     
==========================================
+ Hits          533      635     +102     
- Misses          3       34      +31     
+ Partials        4        0       -4     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[bwheelz36]

Update: also had to remove python3.8 from supported packages. Poetry is quite strict about compatibility, and there is no version of numpy which supports both 3.8 and 3.12. 3.8 is end of life in October this year, so I think this is ok.... (noting that previous PyPi packages will still be available and support older python versions).

[till-m]

At the risk of asking a potentially stupid question -- is it possible to host docs for multiple releases in parallel such that one can view the docs of a specific version instead of always viewing the most current one?

[bwheelz36]

Hey @till-m

• numpy depedency good catch, it was an accident to comment it out . Since numpy is a dependency of scipy we can get away with this, but it's bad practice to rely on another package to handle a dependency we use explicitly - I will fix.
• multiple doc versions - this must be possible because readthedocs supports it. however, tbh I don't have the bandwidth to look at implementing it. For now, previous versions of the docs would always be available via the commit history on the gh-pages branch - which is clunky but functional I guess.
• notebook changes - these are trivial, I was just re-running to make sure they still ran, no actual changes were made. I probably shouldn't have committed those changes sorry.
• Yes, I won't merge until you give the ok :-)