Deleting .julia has no effect whatsoever for me. Of course, YMMV. People employ all sorts of tricks, which occasionally backfire.
I have now developed a portable version of Julia, with a completely local depot and Julia installation tree. I have tested many times, each time deleting everything and rebuilding from scratch. Never had any problem.
Julia looks up files at C:\Users\â¨usernameâŠ\.julia.
Itâs easiest to set up a startup.jl file and put it in .julia\config. E.g., to check if your favorite packages are installed on REPL start and install if theyâre missing:
atreplinit() do repl
@eval using Pkg
let pkgs = ["BenchmarkTools", "Revise"] # put here all the packages you want to install
for pkg in pkgs
if Base.find_package(pkg) |> isnothing
@eval Pkg.add($pkg)
end
end
end
end
Thank you for your help! That worked like a charm on standalone and Atom/Juno!
I have one lingering issue from this upgrade to 1.5.1. And maybe this is the wrong thread, but how do tell Jupyter Notebooks that I removed version 1.4.2 and am now using 1.5.1. I am using the Notebooks environment from Anaconda3 (Navigator v 1.9.12), just fyi.
I did try typing using IJulia and then notebook() since this is what I had previously done.
Again, I am a relative newbie. And as always, thank you very much for your help!
Five minutes of efficiently doing exactly the right things translates to half an hour of googling and swearing, and reading the documentation of symlinks, and searching through the forum after half-remembered advice on package copying.
I sometimes postpone updating for weeks or months because of this. Doing something Julia update, is an incredible improvement.
I donât know why. I use Julia on Linux all the time, I simply unzip the tar file and thatâs it.
By the way, rebuilding the portable version amounts to double-clicking a script file.
Let me know if youâre interested. (That is, if your thing is Windows.)
You have to install to the correct folder, and figure out the symlinks, and fix the package stuff/toml-files. That doesnât happen by itself by unzipping. I donât understand.
Iâve heard asdf recommended, and I used it today and it seemed pretty nice and easy. Itâs a generic version manager with a Julia plugin (you just do asdf plugin add Julia once asdf is installed to add the Julia plugin). Then e.g. asdf install julia installs Julia 1.5.1, or asdf install julia 1.0 installs version 1.0. And asdf global julia 1.5.1 sets julia to point at Julia 1.5.1.
edit: I wrote a longer version of this answer at How to update Julia from command line? - Stack Overflow
I think some users might lose data unexpectedly by deleting ~/.julia. In particular
~/.julia/dev. This could be major work loss if they didnât commit/push in a while.~/.julia/config/startup.jl
There might be other losses Iâm unaware of. Just a note to suggest that maybe we exercise some caution before recommending new users blast ~/.julia.
True. However I think the best thing to do is to develop packages outside of the .julia folder.
Consider just the inconvenience of having to locate the source files.
I think a good practice would be to consider the entire .julia folder as read-only for the user. Remove any time. Storing stuff in this folder always seemed sketchy to me.
The loss of the configuration file could be painful, unless the users had the foresight to commit this file to a repo established for that purpose. That is how I do it, if a start up file is indicated.
By the way, I do use a startup file in the portable Julia installation. It is generated automatically, however.
The portable Windows Julia installation is available here http://hogwarts.ucsd.edu/~pkrysl/shared/Portable_Julia.zip
Instructions: https://github.com/PetrKryslUCSD/dynamics-course-2020
It installs some packages you may not be interested in, but otherwise it is a fairly general
artifact. Feel free to tweak the installation script to suit your needs.
On Mac:
brew install julia
Itâs true that if you use project files and manifests then your .julia should mostly be one big, complicated cache. Feels like blowing it away shouldnât be necessary thoughâI never do. But itâs pretty excellent that reinstalling everything, even binary dependencies, is so reliable and quick that this is fine to do. Worth taking a moment to appreciate.
Iâm sure this is all well and good. But it seems a lot more complicated and advanced than what you indicated at first.
Really? It is literally a single-line to make the installation happen (extract the tar file).
Then, for each package that I want to work on I clone it, activate it, instantiate it.
This discussion has happened many times before
Instead of deleting, itâs always been sufficient for me to transfer the environments folder to upgrade.
It might potentially be helpful for newcomers if the Windows installer could ask whether environments should be transferred from any existing Julia installs.
You lost me. I want to bring with me, say, 30 packages from the previous version. The process you describe here seems vastly more laborious than the manual procedure I already use. Not to mention the super simple update scripts in Jill.py.
And also, you have to fix the symlink stuff, which always takes me quite a bit of time.
I mean, why would I google each package individually to get their url and git clone them, instead of doing Pkg.add? Or just copy over the manifest/project files?
Iâm just mystified because your response seems to be: âWhy would you spend 2 seconds updating with Jill/chocolatey, when you could spend five minutes doing [complicated and confusing process]?â
I think you missed that (1) I cloned the package I wanted to develop (edit its files etc), and (2) I used project files to get all the packages that the developed package depends on.
I donât know if by â30 packages from the previous versionâ you mean that they were used in your work, but if so, I âbrought with meâ all of that stuff with âactivate .; instantiateâ.
And what symlinks are you talking about?