tpapp / julia-repl

Run an inferior Julia REPL in a terminal inside Emacs
Other
169 stars 35 forks source link

Julia-REPL appears to perturb Project/Manifest files leading to continuous need to precompile. #147

Closed johannesnauta closed 8 months ago

johannesnauta commented 8 months ago

I am not sure if this is the right place, as I am not fully sure that the problem lies with julia-repl. I apologize if this turns out to not be the case. Nonetheless, I have a 'gut' feeling that julia-repl is messing with the Project.toml and/or Manifest.toml files somehow. The last few days I have noticed that I need to precompile packages much more often, even after having just called Pkg.precompile() in a previous session and changed nothing in the meantime. This appears to only occur when I use julia-repl, and it does not occur when just using the command line (or, e.g., vterm from within Emacs).

An example workflow is as follows:

[ Info: Emacs vterm detected julia> import Pkg; Pkg.activate("/home/exampleproject/") Activating project at ~/exampleproject/

(myProject) pkg> st Project ExampleProject v0.1.0 Status ~/exampleproject/Project.toml [91a5bcdd] Plots v1.39.0 Info Packages marked with ⌃ have new versions available and may be upgradable.

(myProject) pkg> instantiate ... (myProject) pkg> precompile ... julia> exit()

* invoke `C-c C-a` again
```julia
mport Pkg; Pkg.activate("/home/exampleproject/")
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.9.4 (2023-11-14)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

[ Info: Emacs vterm detected
julia> import Pkg; Pkg.activate("/home/exampleproject/")
  Activating project at `~/exampleproject/`

julia> using Plots
[ Info: Precompiling Plots [91a5bcdd-55d7-5caf-9e0b-520d859cae80]
...

While it is expected that there is no need to precompile as I just did it in the previous session and have not changed anything overall. Note that the expected behavior, i.e. Plots just loads without precompilation, occurs when using a command line (or even vterm from within Emacs), thus leading me to suspect that julia-repl is somehow messing with the .toml files? It is increasingly frustrating as my personal package is relatively huge and precompilation takes a significant amount of time.


  1. Emacs version GNU Emacs 28.1
  2. Julia version 1.9.4
  3. julia-repl version: Version: 1.3.1

Perhaps it is also useful to paste the relevant part of config.org

  (use-package julia-repl
    :ensure t
    :hook (julia-mode . julia-repl-mode)
    :config
    ;; Set the terminal backend
    (julia-repl-set-terminal-backend 'vterm)
    ;; Set the number of threads
    (setenv "JULIA_NUM_THREADS" "8")
    ;; Keybindings for quickly sending code to the REPL
    (define-key julia-repl-mode-map (kbd "<M-RET>") 'my/julia-repl-send-cell))
tpapp commented 8 months ago

Nope, julia-repl is just locating your toml files to activate the project. No write operations are supposed to happen. You can check that, eg read atime, mtime and ctime of the Project.toml (google for tutorials on how to do it). mtime and ctime of your toml files should be unaffected.

What OS are you on?

johannesnauta commented 8 months ago

Yeah that's what I expected, yet then it is still strange that this only happens within a julia-repl... I am on

Distributor ID: Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:        22.04
Codename:       jammy
hexaeder commented 8 months ago

Do you have something in your startup.jl? I had similar problems in the past, and the problem was the following: julia starts in default env. Now let's say your startup includes using Revise, thus loading some transitive dependency which version is based on your global/default manifest. If you now activate your project, there might be a conflict between the already loaded code and the versions from your project manifest which can lead to very anoying recompilation I every session.

My problem was solved by declaring

(setq julia-repl-switches "--project=@.")

and thus activating the project env before executing the startup.jl. Due to the stacked environments, its still possible to load global packages but know they need to conform with the local manifest.

Disclaimer: The solution worked for me, and I built this mental model around it, which kinda explains it. Not sure if it is actually correct though, I don't know about the intricate details of the interaction between various environments :D

johannesnauta commented 8 months ago

That was indeed the case. my startup.jl was as follows

`startup.jl` ```julia atreplinit() do repl @eval using EmacsVterm # Optionally set EmacsVterm.options as you like (see below) end # Set system environments ENV["JULIA_NUM_THREADS"] = 8 ENV["EDITOR"] = "emacs" # For plotting const PLOTS_DEFAULTS = Dict(:theme => :mute) try # Load libararies using Revise # using BenchmarkTools # Load OhMyREPL and define colorscheme using OhMyREPL # Avoid bracket insert "[]]" when typing "[]" # This is particularly annoyting when using `julia-repl-mode` and sending strings # to the Julia REPL OhMyREPL.enable_autocomplete_brackets(false) colorscheme!("GruvboxDark") catch err @warn "Could not load and configure startup packages" end ```

So it is indeed including using Revise. This resulted in the 'conflict' between by global/project manifest. Your suggestion indeed fixed the problem, so thanks a lot!