-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Support shared named environments during startup #40025
Conversation
40d5c38
to
d6d27aa
Compare
Ah, not quite that simple it seems (see failed tests), fixing that now. |
d6d27aa
to
bef1733
Compare
bef1733
to
9b160f4
Compare
Got tests to pass - @vtjnash , are the additional tests sufficient (sorry if I got the wrong guy, GitHub suggested you as reviewer)? |
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't work on Windows? I see no reason it shouldn't, and in that case the new tests should be moved out from the if
.
Good point - why are the previous test cases in |
Because they test expansion of |
Ahh, silly me. Ok, I'll move it out. |
05a85a3
to
f0fbcc6
Compare
f0fbcc6
to
5358d10
Compare
Ok, tests are much nicer now. |
Question: |
@vtjnash , is this good to merge as is, for you? |
LGTM, but might be news-worthy? |
Good point - under "Command-line option changes", I guess? |
I added a news item - text Ok like that? |
515d4c4
to
984a49d
Compare
@oschulz Was the force-push just a documentation change? I want to confirm I can merge this if any code-changes were made after the approvals. |
Oh, sorry - just wanted to present a cleaner history. No, the force push included improvements to the tests that I added after @fredrikekre 's initial approval (since he suggested to also test on Windows). |
Thanks! |
I should have done this a few weeks earlier, in time for v1.6. :-) |
That gives you a reason to look forward to 1.7 😉 |
;-) |
* Support shared named envs during startup * Improved handling of named envs during startup Co-authored-by: Jameson Nash <vtjnash@gmail.com> * Improve tests for --project and JULIA_PROJECT * Add news item about shared env support at startup Co-authored-by: Jameson Nash <vtjnash@gmail.com>
* Support shared named envs during startup * Improved handling of named envs during startup Co-authored-by: Jameson Nash <vtjnash@gmail.com> * Improve tests for --project and JULIA_PROJECT * Add news item about shared env support at startup Co-authored-by: Jameson Nash <vtjnash@gmail.com>
* Support shared named envs during startup * Improved handling of named envs during startup Co-authored-by: Jameson Nash <vtjnash@gmail.com> * Improve tests for --project and JULIA_PROJECT * Add news item about shared env support at startup Co-authored-by: Jameson Nash <vtjnash@gmail.com>
Implements #35354 .
I hope I did this right - from what I saw, most things @fredrikekre had in his proposed patch in #35354,
load_path_expand()
does already now. So just usingload_path_expand()
instead ofexpanduser()
ininit_active_project()
seems to do the trick. I'm not an expert on Julia's init process, though.WIth this, both
--project=@myenv
andJULIA_PROJECT=@myenv
seem to behave the same way asactivate @myenv
on the Pkg console.