Pluto.jl icon indicating copy to clipboard operation
Pluto.jl copied to clipboard

Pluto ignores the Julia package settings

Open donovaly opened this issue 1 year ago • 4 comments
trafficstars

I am a new user. As I don't have much disk space left at drive C:, I installed Julia to the drive J:, which is an external hard drive. To assure that Julia installs all its packages here, I setup the system variable JULIA_DEPOT_PATH to this: J:\Julia-1.11\Packages This works well for Julia as when I install a package using Julia's REPL, I get the packages installed indeed in J:\Julia-1.11\Packages.

But when I start Pluto, my package settings are ignored. It does not take into account that most packages are already installed and it installs them again, this time in C:\Users\>username>

Maybe I misunderstood the concept of Pluto. I thought it runs Julia but it seems it is doing its own thing, ignoring any setting of Julia (see also my issue about the threading).

donovaly avatar Sep 29 '24 19:09 donovaly

Thank you for the report, I don't think Pluto currently has support for JULIA_DEPOT_PATH.

Pangoraw avatar Sep 30 '24 11:09 Pangoraw

This seems to cause problems with non-ascii user folder names on windows, which came up here: https://stackoverflow.com/questions/79032378/big-problems-caused-by-chinese-usernames-in-julia

mcabbott avatar Sep 30 '24 18:09 mcabbott

Thank you for the report, I don't think Pluto currently has support for JULIA_DEPOT_PATH.

So Pluto installs packages a second time? But I want Pluto to use the packages that are already installed for Julia.

How can I specify the path in which Pluto installs packages?

donovaly avatar Oct 01 '24 18:10 donovaly

This seems to cause problems with non-ascii user folder names on windows, which came up here: https://stackoverflow.com/questions/79032378/big-problems-caused-by-chinese-usernames-in-julia

This is no problem, as I assure to use ASCII-only chars in the path. The bug here is that Pluto ignores the JULIA_DEPOT_PATH setting thus it does not use the packages already installed to Julia.

However, the idea of using JULIA_DEPOT_PATH is to set a custom package installation path (for cases like mine, where C:\ is almost full and I therefore use another partition or external harddisk. That Pluto ignores this settings, it fills up C:\ - and this is what I must avoid.

donovaly avatar Oct 01 '24 19:10 donovaly

Pluto supports JULIA_DEPOT_PATH

image

And package installs and precompiles indeed use the custom depot.

image

@donovaly Can you post an example (video, screenshot etc) where you show us what happened?

I suspect that issues like stackoverflow.com/questions/79032378/big-problems-caused-by-chinese-usernames-in-julia are caused by other packages that have ~/.julia hardcoded.

fonsp avatar Nov 13 '24 14:11 fonsp

Pluto supports JULIA_DEPOT_PATH

But my bug report is because this is not the case: You see here my DEPOT_PATH: rundll32_hAr00ytYZl

When I start Pluto, it ignores the package settings and despite packages are already in the DEPOT_PATH, it installs them again in C:\users firefox_NzYCZSfwjk

You see in the video that the packages Printf and Unicode are installed to C:\users

When I use Julia via VS code, it respects my DEPOT_PATH settings and uses the packages I already installed to that location. All I want is that Pluto takes the packages that are in the DEPOTH_PATH and not reinstalling them.

donovaly avatar Nov 14 '24 01:11 donovaly

ah i see! the log you see there is just showing where the project.toml is stored (based on the TMPDIR variable which is on C by default), but the depot is still used for installs and compilation.

Check out the Pkg.jl docs to learn more about the difference between the environment files (project.toml) and the depot files.

Try calling pkgdir(Example) in the notebook.

fonsp avatar Nov 14 '24 08:11 fonsp

When I use the REPL or VS Code and e.g. run using Printf

Nothing is added of installed or precompiled because printf is already installed and precompiled. But when I do the same in Pluto, I get

Adding packages...
===
   Resolving package versions...
    Updating `C:\Users\Uwe\AppData\Local\Temp\jl_BJkWpS\Project.toml`
  [de0858da] + Printf v1.11.0
    Updating `C:\Users\Uwe\AppData\Local\Temp\jl_BJkWpS\Manifest.toml`
  [de0858da] + Printf v1.11.0
  [4ec0a83e] + Unicode v1.11.0
Loading packages...

Instantiating...
===

Precompiling...
===
  Activating project at `C:\Users\Uwe\AppData\Local\Temp\jl_BJkWpS

Why are packages installed an precompiled?

And also, why does Pluto create a new folder in C:\Users<username>\AppData\Local\Temp
and this folder is not even deleted after pluto was closed. I realized now that I have dozens of folders in C:\Users<username>\AppData\Local\Temp
all containing a Manifest.toml and a Project.toml

donovaly avatar Nov 15 '24 02:11 donovaly