nebari icon indicating copy to clipboard operation
nebari copied to clipboard

[BUG] - Simple env with ipympl not working

Open Adam-D-Lewis opened this issue 2 years ago • 3 comments

Describe the bug

I created an environment with only the few packages specified below

image

trying to run the code from the ipympl docs yields "model not found"

%matplotlib ipympl
import matplotlib.pyplot as plt
import numpy as np

fig, ax = plt.subplots()


x = np.linspace(0, 2*np.pi, 100)
y = np.sin(3*x)
ax.plot(x, y)

Expected behavior

I'd expect it to plot successfully.

OS and architecture in which you are running Nebari

Azure

How to Reproduce the problem?

create a conda env and run the code listed above

Command output

No response

Versions and dependencies used.

No response

Compute environment

None

Integrations

No response

Anything else?

No response

Adam-D-Lewis avatar Dec 18 '23 21:12 Adam-D-Lewis

I'm not sure if this is due to an unspecified dependency version constraint somewhere upstream. Or if it has something to do with a conflict or missing dependency for something that is in the default conda channel.

At any rate, specifying some additional dependencies (listed below) does cause ipympl to work as expected.

channels:
  - conda-forge
dependencies:
  - python==3.11.7
  - ipympl==0.9.3
  - matplotlib==3.8.2
  - jupyterlab==3.6.6
  - jupyterlab_widgets==1.1.7
  - jupyterlab_server==2.25.0
  - jupyter_client==8.6.0
  - ipykernel==6.26.0

Adam-D-Lewis avatar Dec 18 '23 22:12 Adam-D-Lewis

@Adam-D-Lewis should we close this? Seems to me it's more related to dependencies rather than Nebari itself but please correct me if I'm wrong.

marcelovilla avatar May 09 '24 14:05 marcelovilla

I suspect that this occurs when the jupyterlab version in the environment (installed automatically to whatever version conda solves for in this case) doesn't match the jupyterlab version the user is running in. This has several consequences which should at a minimum be documented.

First, the user must pin the jupyterlab pkg versions manually in the environment (as listed above) in order for the environment to work correctly. Additionally, if we ever change the jupyterlab version in the docker image (e.g. https://github.com/nebari-dev/nebari-docker-images), then a previously working environment will no longer work correctly since there will be a new mismatch between the docker image jupyterlab and the environment jupyterlab.

I'm not sure if this is something we are not doing correctly, ipympl is not doing correctly, or if it's simply not an intended use case intended to be supported. Maybe we want conda-store to do a conda solve, check if any of these problematic packages are in the solve step and if so then pin the versions to what we need them to be and re-solve. I'd be interested in seeing if @krassowski has any additional perspective here.

Adam-D-Lewis avatar May 09 '24 15:05 Adam-D-Lewis