Closed RoyiAvital closed 3 years ago
The main reason we try not to overwrite user variables, is that the bridge back to user-space is then completely burned: all programs runing through Juliawin and all julia files run with Juliawin will then not be able to see the "correct" userprofile and user locations. We try to isolate on a per-case basis.
On the other hand, this might actually be what some users want...
I have also found that vscode and atom doesn't isolate as much as I initially thought (although I haven't detected this from a usability level): https://github.com/microsoft/vscode/issues/84808 https://github.com/microsoft/vscode/issues/37442 https://github.com/atom/atom/issues/6349
Edit: The vscode first issue can be addressed by adding VSCODE_PORTABLE environmental variable: https://github.com/microsoft/vscode/blob/37e9cceddc5f8e8fe504378b04ebd7388beb6601/src/main.js#L357
I have also found that overwriting system variables will cause all kinds of useless information being dump to that location. One example would be running Pluto, and then finding lots of redirected Firefox junk in your custom folder.
Atom is quite a slob:
There is definitely no silver bullet. So it might be best to clean up Atom and VSCode as much as possible and implement a full portable flavor as an additional option with a toggle switch.
I totally agree there is no perfect solution. I also agree that it is better to utilize portable mode at the application level.
The issue is when some components (Julia Packages, Extension of the Applications, etc...) make assumption between the link of the location of files and system variables.
For instance, I think I had such issue with PyCall
in the past.
PyCall is notorious for not playing along with portable-movable environments ( https://github.com/heetbeet/juliawin/issues/29 ), but that seems more related to hardcoding environment paths after it is build the first time (like when Pkg.build("PyCall")
is called).
For more portability the following might have to be added to activate-juliawin-environment.bat
:
set "juliawin_profile=%juliawin_home%\profile"
:: https://stackoverflow.com/a/44605074/1490584
SET "HOMEDRIVE=%juliawin_profile:~0,2%"
set "HOMEPATH=%juliawin_profile%xxx"
set "HOMEPATH=%HOMEPATH:~2,-3%"
set "USERPROFILE=%juliawin_profile%"
set "ALLUSERSPROFILE=%juliawin_profile%\ProgramData"
set "APPDATA=%juliawin_profile%\AppData\Roaming"
set "LOCALAPPDATA=%juliawin_profile%\AppData\Local"
set "ProgramData=%juliawin_profile%\ProgramData"
set "Public=%juliawin_profile%\Public"
:: Make sure the directories exists
mkdir "%USERPROFILE%" 2> nul
mkdir "%ALLUSERSPROFILE%" 2> nul
mkdir "%APPDATA%" 2> nul
mkdir "%LOCALAPPDATA%" 2> nul
mkdir "%ProgramData%" 2> nul
mkdir "%Public%" 2> nul
Or is should be added to a seperate file like activate-juliawin-portability.bat
with an option to activate/ deactivate that file.
I would give the user the option to chose. I'd even give him the option to chose the User Profile folder path.
Is a private depot being used (speaking of total portability).
Yes the depot path is fully portable. Here is the code that sets the environment: https://github.com/heetbeet/juliawin/blob/main/bin/activate-juliawin-environment.bat
Every exe from the head directory is a thin wrapper to the corresponsing batch files in the "bin" directory.
@PetrKryslUCSD try out the minimum version: https://github.com/heetbeet/juliawin/releases
I think it has a lot of the features that you have put into your own portable project. I would love to work together and get this tailored to something that would fit to the typical workflow that you are after. I really dig your portable enthusiasm with VSCode
Basically, everything is fully portable. This specific issues is on some junk files getting leaked behind on the user's OS. It aims to be flash drive ready, including PyCall, which is the most difficult beast to tame portably
This is very nice!
On Sat, Apr 3, 2021, 8:55 AM heetbeet @.***> wrote:
Basically, everything is fully portable. This specific issues is on some junk files getting leaked behind on the user's OS. It aims to be flash drive ready, including PyCall, which is the most difficult beast to tame portably
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/heetbeet/juliawin/issues/28*issuecomment-812884195__;Iw!!Mih3wA!VEQ6rTkM9fg7rp4DaVmA2JOD04mP-M-wYYi8-pE1tgz2w8umqvSz7fY2_2xx_As$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ACLGGWDQV3FWYJQ6TBU4MH3TG426JANCNFSM4UOUHNZA__;!!Mih3wA!VEQ6rTkM9fg7rp4DaVmA2JOD04mP-M-wYYi8-pE1tgz2w8umqvSz7fY2phJnyXo$ .
I don't think I want to currently focus on making Juliawin use different user environmental variables. I'm gonna close this issue for now
It will be even more portable if the launchers will define the set of System Variables:
ALLUSERSPROFILE
,APPDATA
,HOMEPATH
,ProgramData
,USERPROFILE
andJULIADOC
.Also, it will be nice to be able to set manually the name of the User Profile folder (Or maybe set its path).