-
Notifications
You must be signed in to change notification settings - Fork 194
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
Comments
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. |
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 |
But how is the path to the Julia executable related to Conda at all? Also, mostly unrelated, but the python extension pasting a |
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 |
a hack is activating the environment in an external terminal and then starting vs code from this terminal |
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 |
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. |
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. |
Okay, thx for the explanations and suggestions, i will look in to it |
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
The text was updated successfully, but these errors were encountered: