We already do exactly that. We test all registered Julia packages (registered in the General registry) prior to making a Julia release. We also do this every day on the latest Julia master. See:
The problem you were experiencing was due to some issue with your local environment, as evidenced by the fact that it was fixed by
rm -rf ~/.julia.
In general, when people experience an issue with packages, my first advice is always to
rm -rf ~/.julia. I know that it seems extreme, but it really does fix the vast majority of problems.
Note that this could lead to work lost in packages checked out for development. May not be an issue for new users though.
I think that the manual should contain advice about this, cf
That’s a good point. I suppose my advice should actually be:
- Commit all changes in any packages that you have checked out for development
- Push all changes to a remote (GitHub, GitLab, etc.)
rm -rf ~/.julia
And of course, if you don’t have any packages checked out for development, then you simply do:
rm -rf ~/.julia
It seems overly drastic to start by removing lots of files and REPL history and what not. My advice if you suspect problem with your depot would be to create an empty directory somewhere and point
JULIA_DEPOT_PATH to it. If that works you can start to think about removing stuff in
~/.julia. If it doesn’t the problem is likely elsewhere and no amount of destruction in your normal depot will help you.
Rather than removing
~/.julia, I would suggest looking at the
[compat] section of
Project.toml of the two MJL versions
If I interpret correctly, if you had installed Distributions v0.23 a few days ago, then you would not fulfill
Distributions = "^0.21,^0.22", and the installer would fall back to MLJ v0.2.3.
MLJ v0.2.4 would not install since it depends on
MLJBase = "0.2.3", which maybe was hold back by
CSV = "0.5" in https://github.com/alan-turing-institute/MLJBase.jl/blob/v0.2.3/Project.toml
This might be a case for the developers applying monotonic bounds in RetroCap. Going from 0.10 back to 0.2 is quite a difference, it would probably be more helpful to receive a Pkg incompatibility error.
Sorry to report a glitch on Linux 64 bits with (old) AMD processor (Turion II M640)
Invalid instruction at 0x7ff8b4a3f1d0: 0x66, 0x0f, 0x3a, 0x0f, 0xc0, 0x08, 0x0f, 0x83, 0xae, 0x04, 0x00, 0x00, 0x48, 0xc1, 0xe0 signal (4): Illegal instruction in expression starting at none:0 _ZN4llvm13LexicalScopes23assignInstructionRangesERNS_15SmallVectorImplISt4pairIPKNS_12MachineInstrES5_EEERNS_8DenseMapIS ... jl_module_run_initializer at /buildworker/worker/package_linux64/build/src/toplevel.c:74 _julia_init at /buildworker/worker/package_linux64/build/src/init.c:788 unknown function (ip: 0x401527) __libc_start_main at /lib64/libc.so.6 (unknown line) unknown function (ip: 0x4015d4) Allocations: 2502 (Pool: 2493; Big: 9); GC: 0 Illegal instruction (core dumped)
More info on https://github.com/JuliaLang/julia/issues/35215, where alea54 was the first to report issue on AMD Phenom
Just want to confirm, what LLVM binaries were being used when building those released Julia binaries? It looks like there’re compatibility issues on Windows and Linux:
I noticed the Julia version on Travis CI is still Julia-1.4rc2, this might cause the above issue. (fixed now)
What can I do to fix issues while keeping most of the useful stuff, like my repl history?
- For example, should I just back up my
repl_history.jlfile, and copy it back over after
rm -rf ~/.julia?
- What else should I try to keep? Any suggestions?
- How do I automatically reinstall all packages after deleting them?
To build on what people here are saying:
Julia 1.4.0, then
rm -rf ~/.julia.
MLJ.jl, followed by
Here is the message I got:
(@v1.4) pkg> add Distributions Resolving package versions... Updating `~/.julia/environments/v1.4/Project.toml` [31c24e10] + Distributions v0.22.6 Updating `~/.julia/environments/v1.4/Manifest.toml` [no changes]
Next when I check status:
(@v1.4) pkg> status Status `~/.julia/environments/v1.4/Project.toml` [31c24e10] Distributions v0.22.6 [add582a8] MLJ v0.10.1
It would be great if
- Julia warns me when it adds a package which is not the latest or some kind of Pkg incompatability error as @tim.holy mentions:
`Note you have installed Distributions v0.22.6, not the latest Distributions v0.23.0 because it conflicts with MLJ v0.10.1.`
Pkg.status()display two columns, the package I have & the latest version:
Package Installed version Latest version Distributions v0.22.6 v0.23.0 MLJ v0.10.1 v0.10.1
I’d submit a PR to (https://github.com/JuliaLang/Pkg.jl), but not sure where to begin, or if others even want this.
Yes, I usually keep
~/.julia/logs/repl_history.jl and the folder
~/.julia/config, which I have some initialization file such as
startup.jl before wiping out
~/.julia. In fact, it’s safer to copy
~/.julia to something like
~/.julia.bak before wiping out
As for reinstalling the packages, you might want to copy e.g.,
~/.julia.bak/environments/v1.3 folder to
~/.julia/environments/v1.4 if you have a large number of packages. But usually, when the new version of Julia is released, I install various packages from scratch and try to install/add only really important packages for my projects. That way, I can cleanup and remove some unnecessary packages that I happened to try previously.
@tim.holy I am not familiar with RetroCap and am confused about its use. Is the idea that a developer applies it to a local version of General.jl (somehow restricting its application to the repos owned by the developer) and then makes a PR to General?
Exactly. The PR will be manually reviewed, and shouldn’t be merged if it touches repos that the submitter doesn’t have significant developer stake in.
rm -rf ~/.jullia it’s better to recommend
mv ~/.julia ~/.julia.bak, which is safer. I’m just pointing this out because I don’t want people to accidentally delete their work.
After upgrade to v1.4 from v1.3, I have this warning message: Warning: Pkg.installed() is deprecated. What should I use instead under Pkg v1.4?
This is a great suggestion. I’m usually of the
rm -rf ~/.julia type but now I’m much wiser after reading your comment. While I don’t mind re-installing packages again, I do miss my repl_history when I start from scratch.
Not to come off as rude or anything but I think macOS is broken, at least for Catalina. I am opening a full thread on it, but I’m leaving this comment here as future reference.
For the record it works just fine for me on Catalina.