Deployment#

The package interpret is handy for data scientists in the prototyping and model building phase. However the number of dependencies required is exhaustive, and for production environments it’s often better to select only the components you need for installation. Sometimes you’ll also have a better understanding of what dependency versions can work with interpret and your environment, even if we don’t officially support it. As such we offer options interpret and interpret-core for both scenarios.

Install with every dependency (default)#

The package interpret installs every dependency needed to run any part of the package.

pip install interpret

conda install -c conda-forge interpret

git clone interpretml/interpret.git && cd interpret/scripts && make install

Install with no dependencies#

When you don’t want any dependencies to automatically install and you only need the code, install the package interpret-core instead. The package interpret-core is a zero-dependency install.

pip install interpret-core

conda install -c conda-forge interpret-core

git clone interpretml/interpret.git && cd interpret/scripts && make install-core

Install with some official dependencies (pip)#

This scenario is not covered in all package managers we support. If you are installing with pip, you can take advantage of extra tags that are exposed for interpret-core. It’s best to look at the source code to see how this works.

  • interpret utilizing interpret-core tags found here.

  • interpret-core extra tags found here.

Exposing Visualizations#

The visualizations that power interpret use different renderers depending on the environment they are in. In most cases, the package will detect what kind of environment it is in and use the appropriat renderer. There are times though when you want to forcefully select which one.

Dash Renderer#

The Dash renderer is used for local environments such as running a Jupyter notebook on your laptop. It runs a Dash server, backed by Apache Flask in a separate process the first time its called by interpret.

This provides access to both embedded visualizations within notebooks as well as the full dashboard. However, due to requiring a live Flask server, it cannot render in an offline notebook.

See the source code for underestandings its configuration here.

from interpret import set_visualize_provider
from interpret.provider import DashProvider
set_visualize_provider(DashProvider.from_address(('127.0.0.1', 7001)))
class interpret.provider.DashProvider(app_runner)#

Provides rendering via Plotly’s Dash.

This works in the event of an environment that can expose HTTP(s) ports.

Initializes class.

This requires an instantiated AppRunner, call .from_address instead to initialize both.

Parameters:

app_runner – An AppRunner instance.

classmethod from_address(addr=None, base_url=None, use_relative_links=False)#

Initialize a new AppRunner along with the provider.

Parameters:

  • addr – A tuple that is (ip_addr, port).

  • base_url – Base URL, this useful when behind a proxy.

  • use_relative_links – Relative links for rendered pages instead of full URI.

Inline Renderer#

The inline renderer is used for cloud environments access to flask servers are not always available. In most configurations, it injects JavaScript in each notebook cell, including the bundle.

This does not allow for full dashboards, but it does allow offline support.

See the source code for underestandings its configuration here.

from interpret import set_visualize_provider
from interpret.provider import InlineProvider
set_visualize_provider(InlineProvider())
class interpret.provider.InlineProvider(detected_envs=None, js_url=None)#

Provides rendering via JavaScript that are invoked within Jupyter cells.

Initializes class.

Parameters:

  • detected_envs – Environments targetted as defined in interpret.utils.environment.

  • js_url – If defined, will load the JavaScript bundle for interpret-inline from the given URL.