search

anaconda / nb_conda

Conda environment and package access extension from within Jupyter
BSD 3-Clause "New" or "Revised" License
140 stars 32 forks source link

Support for path-based environments #34

Open aldanor opened 8 years ago

aldanor commented 8 years ago

It seems like the path-based environments (i.e. -p) are not supported, are there any plans to support them? (if any, any name-based environment can be used in conda as a path-based one, but not vice versa).

It would be nice to at least be able to use "Conda Packages" functionality for the current conda environment, regardless of whether it's name or path based.

damianavila commented 8 years ago

This is an interesting request... my first reaction would be how to "codify" the name of that path env... because the very same path thing is probably really long to be the name... @bollwyvl thoughts?

bollwyvl commented 8 years ago

Hm... putting cross-platform file paths into URLs is always peril-fraught... though conda env names can be just about anything you want (spaces, unicode... just no os path specials) so i guess there's nothing too different there.

BUT this little extension doesn't want to be in the business of discovering non-$CONDA_PREFIX/envs-homed envs... if you want them found, the overhead of symlinking them to where conda looks for them is probably more useful than nb_conda maintaining some extra system for locating and referring to them.

That aside, the whole URL scheme would have to change to allow for it:

Which is pretty gross. Further, since presumably the envs could be ANYWHERE, this sounds like we'd have to be careful about path traversal, etc. So I don't think we'd want to take that on right now.

The handling of this current env right here is possible, as I suppose one could exploit several of the above no-no characters, i.e. /environments/::current;;/, or use a convention like $CONDA_DEFAULT_ENV to ensure a semantic name no sane person would name a folder. We'd have to rethink how the things like listing worked, as it definitely uses conda env list under the hood, which wouldn't pick up /some/env even if it was active, I'm thinking. But perhaps worth exploring!

aldanor commented 8 years ago

@bollwyvl Yea, supporting arbitrary path-based environments sounds like an overkill, but the current kernel's environment could indeed be referred to by something like /environments/^__^::current::^__^/ as you suggested :+1:

The listing (in the tree extension) wouldn't change though because path-based envs won't be listed as available kernels? It then only becomes relevant when you're already running the kernel inside some conda env (regardless of how exactly you started it or whether it was name- or path-based).

bollwyvl commented 8 years ago

Just a minor correction:

but the current kernel's server's environment could indeed be

This is the one that is available as Python [default]...

damianavila commented 8 years ago

Thanks @bollwyvl for your feedback... in my first reaction I did not think about all the complexities with paths.

hzpc-joostk commented 6 years ago

Hi everyone, any progress on this? We'd like to keep the conda-env location packed within the project directory to keep everything nice and together, rather than using the default environment locations.

What about escaping the slashes of the prefix path in the URL? / > %2F. I could try it out and submit a merge request next month if desired.