Hi, my computer had to be swapped for a new one, and I need to re-install Julia from scratch, making sure that all of my old Julia programs will still run correctly.
The first time I installed Julia, I had a litany of problems until it was suggested that I install it using JuliaPro. But apparently JuliaPro doesn’t exist anymore! So what would be the most robust way to install Julia now?
My current system is again a PC (I believe running Windows 11), and my last version (with the code that was working correctly) was using JuliaPro 1.4.2-1 (and Atom 1.47.0 x64).
It allows you to install multiple versions of Julia and to switch easily between the versions.
Start with installing your old Julia version (1.4.2) on the new computer. Copy the the Project.toml and Manifest.toml files from your old computer to the new computer. Run using Pkg; Pkg.instantiate and you are done.
You find the global environment in the folder:
ufechner@tuxedi:~/.julia/environments/v1.4$ ls
Manifest.toml Project.toml
Did you work with a global environment or with an environment per project?
Hi, thanks for the quick reply.
Currently the old computer is gone and I have all of my working Julia files saved on an external hard drive. I don’t believe that I saved any of the environmental variables or Julia installation files.
Are you saying that I need to contact my work’s sysadmin staff (hopefully they didn’t re-format the old computer yet), and retrieve the Manifest.toml and Project.toml files from somewhere on it? Could I ask them to email those files to me?
For your other question, I was the only person on the computer and I think I used the same (global?) environment for everything I ran in Julia.
have your code in a git repository, then you can use it from any computer;
have a per-project environment (Project.toml file) and commit it to git. This avoids version conflicts for example between old and new projects. It also serves as documentation which packages in which version your project depends on.
create a backup of your Manifest.toml file when all works well.
Thanks for the suggestions on best practices, I will look into a git repository for the future.
For now, just to see if I understand you, is this the order of events you suggest:
Get my old “Manifest.toml” & “Project.toml” files back from the old computer & hold onto them.
Use your GitHub link to click that page’s link to the Windows store, to “Install Julia”, which will install both Julia and “Juliaup” at the same time on my new computer.
Somehow tell the installation NOT to install the latest version of Julia, but instead to install Julia 1.4.2.
Find the file directory (similar to the one you showed above) on the new computer which contains the new “Manifest.toml” & “Project.toml” files put there by the installation, and then OVER-WRITE them by copying over them with my old “Manifest.toml” & “Project.toml” files.
Run using Pkg; Pkg.instantiate
Pardon me if I’m being slow, but just trying to be sure.
I think I’d prefer to re-create my old set of packages as they were, because Julia had been extremely finicky about the order I installed things in, and I finally had something that was working. I guess I need to somehow run Pkg.status from the old computer, and then re-add everything as per that list, one at a time.
Just want to make sure that I will not cause trouble manually deleting the new “Manifest.toml” and “Project.toml” files and copying in my old ones.
FYI, I do not know what “per-project environment” really means.
A project is a folder with the files you need for a piece of work. Per project environment means:
you created empty Project.toml and Manifest.toml files in this folder for example by running the command julia --project="." and than add the packages you need
the next time you start Julia in that folder you use the command julia --project
visual studio code does that automatically for you when you open a folder that contains these two files
Well, adding the packages manually is not needed and error prone. If you have the Project.toml and Manifest.toml files in the location of the global environment, just launch Julia and run using Pkg; Pkg.instantiate().
I have been using Julia for several years on Linux and Windows. I hav been through the pains of installing and updating Julia on those platforms.
I can honestly say that Juliaup is the cats pyjamas. Thankyou @davidanthoff
For instance there was a recent thread abotu a memory leak in a code. I tested using version 1.10.1 (no leak) and would be quite happy to toggle to 1.9.1 using Juliaup for another test.
In the ‘old days’ an operation like that would have given me the fear.
As an aside, I would encourage you to move to a newer Julia version if possible - 1.4 is quite dated at this point and even older than the last LTS version 1.6.
Julia has improved in many ways since the 1.4 days and most code should run without changes on 1.9 or 1.10 (for which there currently is a release candidate). The main changes you might have to make will come from packages you are working with for which you currently don’t have the latest version because they don’t support 1.4 any longer.
Hi again, still waiting for my old files back, probably I will first try to re-create the old Julia environment and make sure that works, then move to the latest good Julia version.
For now, I clicked on the link to the Microsoft store and installed it… but all I got was the command-line version of Julia. Where the best source for the version with all the windows?! (I was using Atom on the old computer.)
No, I don’t really know what the various panes are called (other than the REPL).
But I see now that Atom-Juno is also dead now too (everything changes fast), so I’ll install the new IDE from that vscode site.
Hopefully it won’t be a problem that I installed Julia itself already on the computer, before the IDE.
Thanks.
Julia has reproducibility guarantee. Meaning if you have exact same versions you can run everything the same.
I.e. Julia 1.4.2, it needs not be JuliaPro, but it does need the same exact versions of your packages too. That’s what the Manifest.toml file is for.
[Julia is a system of its own in a way, and no upgrade of the OS has been known to break the guarantee that I know of. But in theory just upgrading the OS, and nothing else could do that, and that has happened with Python in the past. Also you WILL get a different stream of random numbers, which is usually not a problem, even better. Unless you only upgrade to, if I recall, Julia 1.7 or 1.6 LTS which is rather outdated. Bit-identical float results are hard to guarantee for any language upgrade, and you shouldn’t expect that, except for basic arithmetic operators.]
But in most cases it should be ok to upgrade (Julia has a forward compatibility syntax guarantee, and API stability guarantee, it’s just some package’s use undocumented, not-promised stable, (non) “API”.]. E.g. to latest supported Julia. People may tell you it’s not true, and it breaks the old packages. But if you also update the packages to latest then you’re usually fine.
If not, then a package depended on internals of old Julia, or internals of older package.
The Project file is often enough, it doesn’t state exact versions, then you would just upgrade to latest. To be sure you need the other (and would it alone be enough?).
And of course you need your own source code… And in some exceptional cases not all dependencies are handled by Julia, it’s package manager, and then you need to install something more.
You could still use the exact same Atom or newer, or VS Code. What I wrote about needing exact same versions for the guarantee would not apply to Atom, since it’s just an editor and to access Julia. It might still apply for familiarity. Note, the Atom people moved on to working on VS Code, so so should you, at least eventually. It should have feature parity, and lots of newer features. But it will be slightly different. I doubt anything you did relied on the exact IDE/editor(?).
I found some rather recent discussion related to Atom, but as I said at least the same version (and most probably the fastest should work):
FYI you can use the --heap-size-hint, I’m not sure it will limit memory enough for you, and note there also the line I had in mind, for actually 250 MB, and it’s suggested to be changed. And it’s not just for LLVM:
Hi again, thanks everyone for all the pointers. I got my old Manifest.toml & Project.toml files back, and currently I have Julia 1.9 installed pretty much fresh. Just another query…
I’m a little leery of just downright deleting the new Julia v1.9 versions of Manifest & Project and replacing them manually with the old Julia 1.4 versions. Also, I think it would be ultimately best if I did migrate to Julia 1.9 now (instead of sticking with Julia 1.4). But, I do need my old Package environment to be re-created (or close to it, with minimal fixing), and for the old code to work again. So, to slightly vary my original question:
What’s the best way to “merge” my old Package environment (v1.4 Manifest & Project.toml files) into the new v1.9 system, so that everything is as close to “working” as possible, the same as before, but now in Julia 1.9? Thanks again!