Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out how to propagate ENV VARs in packaged apps #55

Closed
ellisonbg opened this issue Jul 10, 2017 · 4 comments
Closed

Figure out how to propagate ENV VARs in packaged apps #55

ellisonbg opened this issue Jul 10, 2017 · 4 comments
Milestone

Comments

@ellisonbg
Copy link
Contributor

The ENV VARs in a user's environment determine which python and notebook server will be used. We will need to figure out a way of propagating the those to the electron app when installed so it can start the notebook server.

@ellisonbg ellisonbg added this to the 0.1 Release milestone Jul 10, 2017
@ddavidebor
Copy link
Contributor

ddavidebor commented Jul 11, 2017

It appears that applications launched from a .desktop shortcut on Linux do not see the ENV vars from the user's .bashrc.

The user should still be able to select which notebook server to use and save the preference. #48

@lucbouchard1
Copy link
Contributor

I did some investigation on this, and the problem boils down to the user's PATH variable. Any extension to the path that is added by the .bashrc is not included when a program is executed from the desktop environment. Thus, if Jupyter is installed by Anaconda, the main process just can't find the executable and the app can't start.

I found a solution that works but could use some refinement. Instead of spawning the Jupyter notebook server directly from the main process, we can spawn a shell in interactive mode, which forces .bashrc to be executed. We then pipe a command to the shell that starts the notebook server.

@rgbkrk
Copy link
Member

rgbkrk commented Jul 12, 2017

We use shell-env for this in nteract, with the huge caveat that you have to expect to only use what's in their default $PATH (no custom launching), since when you package the app on OS X it launches via launchctl when run from the dock / searchlight.

@ddavidebor
Copy link
Contributor

This has been solved, hasn't it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants