Danger of deleting .julia?

General Usage
1

From thread

What is the danger of deleting .julia?

1 Like
2

If I don’t store my packages under development there, the danger is zero. And I don’t. I delete the .julia folder all the time.

Edit: As @giordano pointed out it also possible to lose history and the startup file. My startup file is machine generated and I don’t care about the history. But YMMV. Beware.

7 Likes
3

If you delete .julia, save the config and environments directories. That will save you some trouble. It’s rare that things get so bad (at least for me) that I need to delete the whole thing.

1 Like
4

I have no config directory there. What could be in this directory?

5

The main risk is carelessly deleting the dev/ subdirectory which contains local development not yet pushed to a remote repository. Most of the other stuff is either downloaded or automatically generated, but teaching people to just nuke the entire depot whenever they have problems is just bad.

Deleting the entire depot is basically never a solution for a problem. If the compiled cache is corrupted, just clear that one. If the registry is corrupted, remove and reinstall that one. Piecewisely deleting individual subdirectories which may be involved with the problem you’re facing can help identify the culprit, deleting the entire depot is a nuclear option which serves little purpose besides potentially making people lose their work.

19 Likes
6

Your startup.jl lives there. If you don’t have one, config is not a problem for yo.

2 Likes
7

You might not have, but people in general may have. Suggesting to users to delete .julia without a disclaimer is really bad advice. It is like I would suggest something like “did you format your harddrive” because I do nightly remote backups.

Even if you don’t have development packages in the .julia folder there are things that you will lose. The people saying there is no danger might not care about those things, but some people will.

Some things you will lose that can not be recovered automatically:

  • Global package environment
  • Development repositorires (default under .julia/dev)
  • REPL history
  • Any startup.jl configuration
  • Package preferences/configuration
  • Packages scratch folders
  • Manifest history usage (Pkg won’t be able to garbage collect unused packages, although doesn’t really matter if you go nuclear and delete everything I guess)
  • Package snapshots: If you installed a package on a branch, and that branch have been deleted on the remote repository you can not instantiate that manifest again

Exactly. Post Julia 1.0 it is never a good solution.

27 Likes
8

There are some good reasons to consider starting from a fresh Julia depot, mostly for testing or debugging purposes. Before deleting a depot, I would consider the follow alternatives.

  1. Setting the environment variable JULIA_DEPOT_PATH.
  2. Moving the depot to a backup location.
5 Likes
9

I personally see a lot of value in testing software with a clean slate. Hence I take the step of deleting the depot quite often.

It is true that this may be also accomplished by using the variable pointing to the depot. Renaming the depot (potentially temporarily) is also possible, but personally I would rather not store many gigabytes of data unnecessarily.

10

I occasionally do that as well for testing purposes, but I start Julia with

JULIA_DEPOT_PATH=$(mktemp -d) julia

I still don’t have any good use case for deleting my entire depot.

What I don’t like is people actively suggesting other users to nuke their depot, especially if without explaining all the consequences. Please just don’t do it.

11 Likes
11

This is clever.

12

I believe there is nothing wrong with suggesting to delete .julia, IF the consequences are explained.
(Which I do.) Fact is: if I kept the .julia for the past two years unchanged, I would be out of disk space at this point.

13
3 Likes
14

That is great, that does address my need to clean up house from time to time.

15

Similar trick to start up with a temporary project activated:

julia --project=$(mktemp -d)
3 Likes
16

I wish this worked on Windows. Could we consider a dedicated command line option for this without depending on mktemp?

17

I run the git bash on Windows. Saves me a lot of headaches with the lame cmd.
The mktemp is of course available in the bash.

18

Given that both global environments and paths have their equivalents between julia --project=<@glob | some/path> and pkg> activate <@glob | some/path> it would be nice if the pkg> activate --temp option also had an equivalent that mapped in the same (similar?) way.

Mapping it the same I guess we would get julia --project=--temp, which feels a little strange, and maybe would become annoying with parsing since equals can be omitted, e.g. julia --project --temp? Don’t have any good alternative suggestion as of now.

I didn’t know about the mktemp command in unix, so that works okay, but for windows, for people who don’t know about mktemp, or just to have it consistent, I think it would be nice with having something more equivalent here.

1 Like
19

Sometimes, if you delete your ~/.julia and start with a clean slate, the precompilation times etc. would improve quite a bit. This happened recently on my old MacBook Pro. When I want to delete ~/.julia folder, I usually rename it to ~/.julia.bak or something just in case. Then, I often copy the history log ~/.julia.bak/logs/repl_history.jl and ~/.julia.bak/config/ folder (if you setup startup.jl there). Maybe I may check some other files and folders, but then I can safely delete ~/.julia.bak.

20

If you just want to improve precompilation times in the manner you described, just start a new environment and keep your base environment sparse.

using Pkg
pkg"activate @mynewproject"

The @ creates a shared project stored in .julia/environments/

1 Like