Are we sure that imports and other uses have been protected so that this package will build/test properly in a non-RSP Jenkins-only environment? If so, I have no objections.

This proposal also requires that the two third party dependencies ginga and astrowidgets would also be distributed with science pipelines.

Note that display_astrowidgets is already in use by science pipelines team members on the summit science platform, and we'd like it to be more generally available to pipelines users and science users (including the DP0.2 delegates) and with zero effort from the science platform devs.

Kian-Tat Lim I think the additional info I was typing while you were typing your question covers it. Yes, the objective is for it to build in jenkins-only environment

I'm reading a couple different things here. Is part of this RFC would to add ginga and astrowidgets to rubin-env to make this possible? These are both noarch: python packages on conda-forge so I do not have any objections.

Alternatively, maybe the proposal is to have this in lsst_distrib but only usable in an env with ginga and astrowidgets.

Either way, this should be made clear in the RFC text.

My vote would be to add them to rubin-env.

I’m using it (display_astrowidgets ) right now at the summit RSP, mainly because Chris’s verification notebooks use it (https://github.com/lsst/cp_verify/tree/main/examples)

Adding them to rubin-env means that they will be part of production DRP batch containers running non-interactively. If that's useful or at least acceptable, then we can do this.

If it's only useful in RSP environments, that's already ensured by https://github.com/lsst-sqre/sciplat-lab/blob/prod/stage3-py.sh#L60

I think we need the dependencies in RSP containers and shared stack; I suspect Science Pipelines devs don't care about environments that aren't one of those.

rubin-env would be fine with me.  Being able to use it by default on the RSP is my main goal for this RFC.

Yes, everyone is fine with rubin-env. The question is whether it is needed (and might cause problems down the road). It is not needed to make it "default on the RSP and shared stack."

Our two other notebook-embedded diplsay_* backends firefly_client and matplotlib are in rubin-env.

drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:51 astrowidgets-0.2.0.dist-info
drwxr-xr-x 4 yusra grp_202 4.0K Feb 14 13:51 astrowidgets
drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:51 aggdraw-1.3.14.dist-info
drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:51 aggdraw.libs
-rwxr-xr-x 1 yusra grp_202 1.6M Feb 14 13:51 aggdraw.cpython-38-x86_64-linux-gnu.so
drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:51 ipyevents-2.0.1.dist-info
drwxr-xr-x 5 yusra grp_202 4.0K Feb 14 13:51 ipyevents
drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:51 jupyterlab-3.2.9.dist-info
drwxr-xr-x 9 yusra grp_202 4.0K Feb 14 13:51 jupyterlab
drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:51 jupyterlab_server-2.10.3.dist-info
drwxr-xr-x 5 yusra grp_202 4.0K Feb 14 13:51 jupyterlab_server
drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:51 nbclassic-0.3.5.dist-info
drwxr-xr-x 8 yusra grp_202 4.0K Feb 14 13:51 nbclassic
drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:51 json5-0.9.6.dist-info
drwxr-xr-x 3 yusra grp_202 4.0K Feb 14 13:51 json5
drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:51 jupyter_server-1.13.5.dist-info
drwxr-xr-x 18 yusra grp_202 4.0K Feb 14 13:51 jupyter_server
drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:51 anyio-3.5.0.dist-info
drwxr-xr-x 7 yusra grp_202 4.0K Feb 14 13:51 anyio
drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:51 sniffio-1.2.0.dist-info
drwxr-xr-x 4 yusra grp_202 4.0K Feb 14 13:51 sniffio
drwxr-xr-x 2 yusra grp_202 4.0K Feb 14 13:50 ginga-3.2.0.dist-info
drwxr-xr-x 28 yusra grp_202 4.0K Feb 14 13:50 ginga
 
Collapse
 
 
 
 
 
 Julyter_lab is in the dependencies so rubin_env doe snot seem correct. Can investigate this dependancie .. open an issue on this and add to shared stack

For the record, matplotlib is used for many other purposes, including producing non-interactive static plots, so it will always be included in rubin-env. firefly_client has only requests and websocket-client as dependencies, both of which are usable non-interactively and used by other packages.

ginga looks reasonable, with only (small) qtpy as an additional dependency that is not already present (although ginga itself is several MB). astrowidgets is the problematic one, pulling in all of jupyterlab and more.

Christopher Waters is there a specific reason that you have not yet adopted this RFC? I see that you have a triggering ticket.

Christopher Waters do you intend to adopt this RFC?

Kian-Tat Lim did we actually resolve the rubin-env problem in the discussion? It seems like we left it with "astrowidgets" being problematic in that it pulls in jupyterlab but we need that to be there before we can add display_astrowidgets to lsst_distrib.

For reference we have two other open RFCs that talk about installing ginga:

• RFC-519 wants to add ginga and ipyevents as eups packages to support display_ginga (presumably now as conda-forge packages).
• RFC-420 wants to add display_ginga to the shared stacks (which sounds like it has been done)

I don't see why it is necessary to have astrowidgets be added to rubin-env in order to add display_astrowidgets to lsst_distrib.  I would prefer that the latter be done with sufficient protections around all usages that no breakage occurs in Jenkins where astrowidgets is not available, but that everything is usable in the shared stack and RSP where it is.

But I'm also fine with display_astrowidgets not being added to lsst_distrib and only added via eups distrib install to RSP containers and the shared stack.