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

Use VS-Code integrated terminal insted of VS-Code system terminal #2000

Closed
bela127 opened this issue Mar 6, 2021 · 9 comments
Closed

Use VS-Code integrated terminal insted of VS-Code system terminal #2000

bela127 opened this issue Mar 6, 2021 · 9 comments

Comments

@bela127
Copy link

bela127 commented Mar 6, 2021

Current behaviour:
The extension searches for the julia.executablePath in the PATH variable of the VS-Code system terminal (the terminal VS-Code was started in / the system terminal)

Expected behaviour:
search for the julia.executablePath in the PATH variable of the VS-Code integrated terminal, because this can have different PATH entries through the VS-Code workspace settings

All code execution should always start from the integrated terminal, see other plugins like the Python plugin, else the user has no possibility to manipulate the environment variables

@pfitzseb
Copy link
Member

pfitzseb commented Mar 6, 2021

You can manipulate all env variables yourself as per usual, but we resolve the binary path before starting a terminal. Imho there's absolutely zero reason to go through a shell instead of starting the Julia process directly.
That said, our path resolution could certainly take a PATH modified in the VSCode settings into account.

@bela127
Copy link
Author

bela127 commented Mar 6, 2021

As of 2019 you can have conda environments with Julia, if you use the terminal for path resolution then you will use automatically the julia environment of the active conda environment.

Because you do an independent path resolution this is not working correctly

@pfitzseb
Copy link
Member

pfitzseb commented Mar 6, 2021

But how is the path to the Julia executable related to Conda at all?

Also, mostly unrelated, but the python extension pasting a conda activate ... or whatever string into terminals it doesn't own is awful...

@bela127
Copy link
Author

bela127 commented Mar 6, 2021

Well, conda environments are not python specific

Conda can be used for any programming language and framework for Version (environment) management

Julia is now supported in conda, so one can make different environments with different packages and julia Versions

But if one switches environments, or activates environments the vs-code julia extension is not able to find the julia binary of the active conda environment

@bela127
Copy link
Author

bela127 commented Mar 6, 2021

a hack is activating the environment in an external terminal and then starting vs code from this terminal

@bela127
Copy link
Author

bela127 commented Mar 6, 2021

Also, mostly unrelated, but the python extension pasting a conda activate ... or whatever string into terminals it doesn't own is awful...

An extension is abel to create it's one terminal in vs-code. i still think it should use the environment-variables from the integrated vs-code terminal because else one can not auto change them via conda or else before the julia binary is searched.

Another approach would be to directly add a conda environment setting or selection, but this is more work and less flexible as it only would support conda

The console approach would support any kind of path change

@pfitzseb
Copy link
Member

pfitzseb commented Mar 8, 2021

Since I doubt we'll converge on a design here quickly, I'd suggest creating a small wrapper script that does the VSCode-PATH based resolution for now.

@davidanthoff
Copy link
Member

Agreed, I don't see us changing the current behavior to accommodate a non-standard Julia deployment story like conda, so I'm going to close this issue.

Three more points:

First, if you want to configure a per project Julia version story, you can configure a workspace Julia binary path in VS Code, that will allow you to use different Julia versions per project.

Second, I've had so much trouble with the various Python deployment stories over the years, including conda, that quite frankly I want to stay as far away from that space as I can :) My suggestion would be to deploy Julia with one of the official Julia approaches, and not via conda.

Third, I do think it would be valuable to have a more "official" story for environments that include the ability to select a specific Julia version, but I think ideally that would happen in Julia base, and then we would pick that up in the extension. JuliaLang/julia#36672 could eventually lead to something like that, who knows.

@bela127
Copy link
Author

bela127 commented Mar 9, 2021

Okay, thx for the explanations and suggestions, i will look in to 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

3 participants