Fix and Update Conda Installation package for Interpret 0.2.7

[rxm7706]

Interpret ML conda installation is broken @interpret-ml

• https://github.com/interpretml/interpret/issues/341
• https://github.com/interpretml/interpret/issues/253
• https://github.com/interpretml/interpret/issues/219

Both the meta.yaml for interpret-core and interpret are outdated and pointing to incorrect versions scripts/conda/interpret-core/meta.yaml scripts/conda/interpret/meta.yaml

Would it be possible to add a backlog item to fix this and make interpret ml more usable with Conda Ecosystems It would also be useful to publish to conda-forge vs interpretML channel, to get more support and maintenance from the Open Source Ecosystem

[paulbkoch]

Thank you @rxm7706 - We finally published a conda-forge package (https://anaconda.org/conda-forge/interpret) which can be installed with:

conda install -c conda-forge interpret

[rxm7706]

@paulbkoch this is exciting, just making interpretml available on conda-forge will hopefully drive adoption and the ability to install in parallel to other conda packages will make Interpret more popular.

I do see a slight annoyance where Pip users will have ability to install and use interpret with Python 3.7 ; while conda users will need to be using python 3.8 or above. This is because conda-forge by default only builds for 4 python version, Python 3.8 to 3.11 is the default now.

There is a way around this - by managing conda_build_config.yaml to include a build / conda package for Python 3.7 too. Which would make sense since Interpret itself is compatible with Python 3.7 and above.

A sample would look like

# conda_build_config.yam patch to make conda-forge build python 3.7 package for Interpret
python:
  - 3.7.* *_cpython   # [not (osx and arm64)]
  - 3.8.* *_cpython
  - 3.9.* *_cpython
  - 3.10.* *_cpython
  - 3.11.* *_cpython
python_impl:
  - cpython           # [not (osx and arm64)]
  - cpython
  - cpython
  - cpython
  - cpython
numpy:
  - 1.20              # [not (osx and arm64)]
  - 1.20
  - 1.20
  - 1.21
  - 1.23

I can try and help with that , will open a separate issue to see if we can address that gap.

Thank You for this effort.

[paulbkoch]

Thanks @rxm7706 -- This makes sense, and yes, I was a bit sad to see that it didn't build 3.7 by default.

I'd first like to try and resolve this other issue ( https://github.com/conda-forge/admin-requests/issues/672 ), but then I'll try the modifications you indicated.

Do you know if this change will cause a rebuild of the other already released python versions, and would I need to increment the build number in the recipe?

Unfortunately, one of our dependencies (skope-rules) doesn't have a 3.10 release, so we can't either. I might remove that dependency though.

[rxm7706]

Do you know if this change will cause a rebuild of the other already released python versions, and would I need to increment the build number in the recipe?

@paulbkoch yes it will cause a rebuild, which is fine, and yes we would need to increment the build number - both are fine and normal practice, by default anytime someone tries to install the package - all things equal, the resolver will pick the newer build.

Unfortunately, one of our dependencies (skope-rules) doesn't have a 3.10 release, so we can't either. I might remove that dependency though.

So I checked - I'm the maintainer for skope-rules conda forge feedstock and package, I might have built the condo-package just for Interpret ; but the root cause of not having skope-rules not working with python 3.10 is "Due to the removal of Iterable from collections, skrules/skope_rules.py cannot be imported under Python 3.10." - a PR for which has been open for quite a while with no action https://github.com/scikit-learn-contrib/skope-rules/pull/61 Once the skope-rules PR is merged, I can make sure I update the skope-rules feedstock.

However, considering the lack of activity / maintenance of skope-rules (no commits, PR's / updates for over 2 years) ; interpret might be better off removing the dependency on skope rules - as you've proposed. Pity though about skope-rules- looks like quite a few people contributed, it is still quite popular and it was an actively maintained package for a couple of years, before the stalling off.

[paulbkoch]

Hi @rxm7706 -- So, something like this?

https://github.com/paulbkoch/interpret-core-feedstock/commit/0963c91994bc0dd9b88e8e3eee47373e50ed6276

[rxm7706]

Hi @paulbkoch conda_build_config.yaml needs to be in the recipe directory - recipe/conda_build_config.yaml - I believe that's the only change and it should work. Worth a shot.

[paulbkoch]

Hi @rxm7706 -- It's failing, due to some Shap incompatibility. Not sure exactly, but will look tomorrow.

https://github.com/conda-forge/interpret-core-feedstock/pull/2

[paulbkoch]

Hi @rxm7706 -- I was able to get conda-forge to build versions for python 3.7, 3,8, 3.9 and 3.10 using your suggestions. Shap isn't available for python 3.11, so I removed that one.

Let me know if you have an issues.

[rxm7706]

@paulbkoch just FYI - looks like shap has been built now with python 3.11 https://anaconda.org/conda-forge/shap/files?version=0.41.0 https://anaconda.org/conda-forge/shap/0.41.0/download/linux-64/shap-0.41.0-py311h320fe9a_2.conda

[paulbkoch]

Thanks @rxm7706 -- That's good news for interpretability. For InterpretML we should work with python 3.11 already. In a later release of interpret & interpret-core I changed both packages be noarch. There's a new libebm package that contains the compiled components, but it doesn't have any python dependencies.