Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pluto ignores the Julia package settings #3035

Closed
donovaly opened this issue Sep 29, 2024 · 8 comments
Closed

Pluto ignores the Julia package settings #3035

donovaly opened this issue Sep 29, 2024 · 8 comments
Labels
bug Something isn't working package manager Pluto's built-in package manager

Comments

@donovaly
Copy link

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).

@Pangoraw Pangoraw added bug Something isn't working package manager Pluto's built-in package manager labels Sep 30, 2024
@Pangoraw
Copy link
Collaborator

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

@mcabbott
Copy link
Contributor

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

@donovaly
Copy link
Author

donovaly commented Oct 1, 2024

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
Copy link
Author

donovaly commented Oct 1, 2024

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.

@fonsp
Copy link
Owner

fonsp commented Nov 13, 2024

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.

@donovaly
Copy link
Author

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.

@fonsp
Copy link
Owner

fonsp commented Nov 14, 2024

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 fonsp closed this as not planned Won't fix, can't repro, duplicate, stale Nov 14, 2024
@donovaly
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working package manager Pluto's built-in package manager
Projects
None yet
Development

No branches or pull requests

4 participants