The order can matter. For example if you install A,B,C and then try to install D it can say there is no way to satisfy all the versions so you’ll get just A,B,C but if you first install A,B,D then try C it will give the same error but you’ll have A,B,D at the end.
There are complicated versions of this too, if you try to do 10 projects each of which needs 10 packages, all installed in the top level environment, you are likely to get a situation where it’s not possible to satisfy all those projects. Which ones you succeed with has to do with what order you try.
Practically speaking You can not effectively use Julia without local environments end of story. They have to be taught first thing, day one.
I agree with you in principle, but I have to gauge what my students are capable of conceptualising, and I think that for the lower tail of the largest classes I teach, Environments would be a step too far (possibly leading to a revolt). [So far, they seem to be OK with deleting the .toml files and reinstalling everything.]
I had hoped there might be another way, but it appears not. I don’t suppose it will ever be possible to have multiple versions of the same package installed, so that as dependencies the appropriate one would be loaded, but as a standalone, the most recent would be used. In this case, packages wouldn’t ever break each other. (“wish list”)
Perhaps supply the students with a Project.toml and Manifest.toml with versions that you have already verified are working well? And, perhaps, also a script that activates and instantiates the directory:
using Pkg
Pkg.activate(@__DIR__)
Pkg.instantiate()
If you tell them to put the three files somewhere, start Julia and go to that location, and then run the script, then they should get the same environment that you have. I use a strategy like this, and have had no trouble. I have CSV and Plots in the environment I give to the students. Pluto and Jump are not in the set of things I use, though.
Hi. I thought of doing this, but I worried about the various indecipherable numerical codes in those files possibly being hardware- or OS- specific [Manifest.toml seems to have to do with compilation so surely it must depend on OS?].
On the other hand, if I am wrong about the above, couldn’t the .toml files just be inserted into everyone’s ~/.julia/environments/v1.x/ directory?
For that kind of low level commitment with the language, I think just using Pluto is the best solution. It looks nice, creates its own environments, looks like an IDE, etc.
No, that information just identifies the specific versions of each package. One of the great features of Julia is that specific environments are easy to replicate exactly. Just get the students to use a specific version of Julia, and this procedure, and they will all have exactly the same set of packages that you have previously checked to work well.
About the second question, I’m not sure about that, I don’t use that option.
There are two kinds of non-obvious numerical (hexadecimal) codes in the Manifests:
UUID (e.g. uuid = "7876af07-990d-54b4-ab0e-23690620f79a") is a unique identifier of the package. The reason why the identity is not just the package name is that Pkg is designed to be able to handle multiple packages with the same name (with some restrictions).
Tree hash (e.g. git-tree-sha1 = "46e44e869b4d90b96bd8ed1fdcf32244fddfb6cc") is a hash of the contents of the package as it’s distributed. I.e. source code, tests, documentation etc. but nothing that is created locally on the computer such as the result of precompilation.
Both of these are independent of OS or hardware. In fact Manifests have nothing to do with compilation but everything to do with source content.
Maybe you could bring your students to use shared environments which can be activated from the REPL like this:
(@v1.8) pkg> activate @example1
Activating new project at `~/.julia/environments/example1`
The advantage compared to local environments would be, that your students do not need to know where their environments are, just that they need to activate them before starting working on a certain problem set. These would be proper environments and you should run into less version problems between packages.
If you have Windows Terminal installed, then Windows Explorer provides a right-click context menu to start a terminal in the selected directory:
If Julia was installed via juliaup then there will be a menu entry for starting Julia on the Terminal pull-down menu:
If this isn’t convenient enough, you can go into the Settings tab for Terminal and make Julia the default profile so that it starts immediately from the Windows Explorer context menu.
I had a look and this looks really cool. I use VSCode for my own work and consider it to be the best IDE for Julia.
However, setting VSCode up is not as easy as downloading Anaconda, so I went with JupyterLab for the class. A script that just does it would be great.
Has anyone written the equivalent shell script for Mac?
[I wouldn’t know enough to translate (maybe I’ll try), but would consider using this if it runs as easy as it seems and I could get a Mac version going as well]
Thanks
Wow… Vscode was literally the thing I switched to because setting up anaconda literally took me most of a week and I was done at that point. Setting up vscode took less than 5 mins
As far as I understand a shared environment is an environment that is located in the environment folder of your depot. In my case this is ~/.julia/environments. This would depend on the value of the DEPOT_PATH environment variable, but the path that is activated is also shown by the These environments can either be activated by using the --shared option or by starting the name with an @.
The shared environments are available no matter in what directory they started their julia session. The global environment @v1.8 that is activated by default when you start julia is also in the same environment folder. You can also see the shared environments that are available on your computer by tab completion after typing
(@example2) pkg> activate --shared
in the package mode.
You can have your students either copy the two .toml files into a subdirectory of the ~/.julia/environments/ directory or they can install the packages themselves, by activating the environment by starting the environment name with an @.
If you are providing the .toml files I would not have them put in the environments folder in the DEPOT_PATH because then they would need to find where this folder is located and it would be easier to simply activate the local environment.
Once you update Pluto.jl (Totally agree that reactivity must be an option and not forced, also the auto run on load), just use JuliaWin and you’ll have the easiest and smoothest out of the box experience with Julia.
The only issue is (For some), this combination can work only for Windows.
