Discuss options for extension install on a per-user basis or per-conda-environment

[ijstokes]

My sense is that we want all extensions to be installed "globally" which will, in fact, mean "in the current conda environment". Ideally we'd like to be able to pass settings through so a user had an option of installing it on a "per user" basis, but then it will be installed outside of conda and will be in all Jupyter instances, which might be problematic.

[damianavila]

I will copy my answer in the chat and expand later:

Sorry, at phone now but the nbextensions api have a --prefix that we could use to make a conda env specific installation... but we also should allow the posibility to install them "globally" either per-user or system-wide...

additionally, the "globally" per user or system installation will be available in all the jupyter instances whose their jupyter-config-dir points to the default ones (if you install them there). All jupyter instances pointing to other config locations will be not affected

[damianavila]

BTW, this is a general discussion so pinging @mmarchetti, @bollwyvl and @malev as well...

[bollwyvl]

Right. To get a handle on this, try running jupyter --paths. There a
number of places from which the nbextension would be served, and where the
configuration files would be created.

From that, I'm not seeing a good "share" location in my conda environment,
just Jupiter's source... Which it might be bad to mess with.

This suggests, without wrapping the notebook app (not worth it for this,
but maybe for something bigger), we either need to the accept
userland/global choice, or start the notebook app with an extra command
line switch... If such a switch exists.

On 07:41, Wed, Nov 11, 2015 Damián Avila notifications@github.com wrote:

BTW, this is a general discussion so pinging @mmarchetti
https://github.com/mmarchetti, @bollwyvl https://github.com/bollwyvl
and @malev https://github.com/malev as well...

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[damianavila]

From that, I'm not seeing a good "share" location in my conda environment,
just Jupiter's source... Which it might be bad to mess with.

I think we have enough good places...

damian-S400CA :: ~ :: 
$ jupyter --paths
config:
    /home/damian/.jupyter
    /home/damian/miniconda3/etc/jupyter
    /usr/local/etc/jupyter
    /etc/jupyter
data:
    /home/damian/.local/share/jupyter
    /home/damian/miniconda3/share/jupyter
    /usr/local/share/jupyter
    /usr/share/jupyter
runtime:
    /run/user/1000/jupyter
damian-S400CA :: ~ :: 
$ source activate jup
discarding /home/damian/miniconda3/bin from PATH
prepending /home/damian/miniconda3/envs/jup/bin to PATH
(jup)damian-S400CA :: ~ :: 
$ jupyter --paths
config:
    /home/damian/.jupyter
    /home/damian/miniconda3/envs/jup/etc/jupyter
    /usr/local/etc/jupyter
    /etc/jupyter
data:
    /home/damian/.local/share/jupyter
    /home/damian/miniconda3/envs/jup/share/jupyter
    /usr/local/share/jupyter
    /usr/share/jupyter
runtime:
    /run/user/1000/jupyter

You have /home/damian/miniconda3/envs/jup/etc/jupyter for config and /home/damian/miniconda3/envs/jup/share/jupyter for data...

Btw, wrapping the notebook makes sense in the future for better handling of several things... and in fact is the methodology already present in wakari that I am migrating to the anaconda-notebook... anyway, I have to experiment a little bit more before coming up with a conclusion, but we have several ways to achieve this 😉

[bollwyvl]

You're right, of course. Was working from memory on phone. The env location
is solid. I guess then switches should be --user/--global as pass through,
with --conda_env as one we do ourselves.

I need to look into the config call for enabling but hopefully it's already
wired up to accept a destination.

Really is shaping up that conda is the best way to manage Jupyter
installs... At least in the single user mode. Not sure about multiple user
installs, as conda is less good at that, from what I've seen.

The high road would be to actually package the js as npm packages, also
installed by conda, and be able to pull them in more discretely, but for
now the monolith will have to do.

On 16:22, Wed, Nov 11, 2015 Damián Avila notifications@github.com wrote:

From that, I'm not seeing a good "share" location in my conda environment,
just Jupiter's source... Which it might be bad to mess with.

I think we have enough good places...

damian-S400CA :: ~ ::
$ jupyter --paths
config:
/home/damian/.jupyter
/home/damian/miniconda3/etc/jupyter
/usr/local/etc/jupyter
/etc/jupyter
data:
/home/damian/.local/share/jupyter
/home/damian/miniconda3/share/jupyter
/usr/local/share/jupyter
/usr/share/jupyter
runtime:
/run/user/1000/jupyter
damian-S400CA :: ~ ::
$ source activate jup
discarding /home/damian/miniconda3/bin from PATH
prepending /home/damian/miniconda3/envs/jup/bin to PATH
(jup)damian-S400CA :: ~ ::
$ jupyter --paths
config:
/home/damian/.jupyter
/home/damian/miniconda3/envs/jup/etc/jupyter
/usr/local/etc/jupyter
/etc/jupyter
data:
/home/damian/.local/share/jupyter
/home/damian/miniconda3/envs/jup/share/jupyter
/usr/local/share/jupyter
/usr/share/jupyter
runtime:
/run/user/1000/jupyter

You have /home/damian/miniconda3/envs/jup/etc/jupyter for config and
/home/damian/miniconda3/envs/jup/share/jupyter for data...

Btw, wrapping the notebook makes sense in the future for better handling
of several things... and in fact is the methodology already present in
wakari that I am migrating to the anaconda-notebook... anyway, I have to
experiment a little bit more before coming up with a conclusion, but we
have several ways to achieve this [image: 😉]

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[damianavila]

I guess then switches should be --user/--global as pass through,
with --conda_env as one we do ourselves.

Yep...

I need to look into the config call for enabling but hopefully it's already
wired up to accept a destination.

I think so, we need to check because I don;t remember...

Really is shaping up that conda is the best way to manage Jupyter
installs... At least in the single user mode. Not sure about multiple user
installs, as conda is less good at that, from what I've seen.

Yep, there is some issues with multiple users usability of conda... let's see how that evolves in the future...

The high road would be to actually package the js as npm packages, also
installed by conda, and be able to pull them in more discretely, but for
now the monolith will have to do.

In fact, I think there is a third agnostic path using build and post script commands... but I agree that eventually a npm based installation based on conda should be one of the path to follow (there is an interesting discussion about how lo load things in the "future" notebookish thing here: https://github.com/phosphorjs/phosphide/issues/1)

[damianavila]

This discussion (and exploration of further options) will continue in a bigger picture here: https://github.com/Anaconda-Server/anaconda-notebook/issues/55.

@bollwyvl I can not close this one, can you give me access to this repo? Or close the issue 😉 Thanks!

[bollwyvl]

On phone, but will add you, too!