Why is the package creating a file in my homefolder?

[davidanthoff]

Why is this package putting a file .jlassetregistry.json into my home folder? That is really opaque, as a user it is entirely unclear where that comes from, what it is needed for, whether I can delete it etc. Really a package shouldn't just create files in the home folder.

[twavv]

Transferred to AssetRegistry.jl

There's no reason other than that's where it's gone historically. It could be changed but it needs to be in a known location since it is accessed by things outside of Julia (e.g. the WebIO Jupyter server extension).

I'm hesitant to change it, however, because it could lead to weird issues if using two versions of AssetRegistry.jl at the same time (e.g., the Jupyter server extension was configured with one location for the JSON file but the current Interact/WebIO/AssetRegistry versions loaded are using the old location).

[shashi]

Actually the reason was, our jupyter plugins need to be able to find this file (from Python). It would be awfully complicated to try to locate the right Julia package on disk without access to a running Julia process.

[twavv]

Actually the reason was, our jupyter plugins need to be able to find this file (from Python). It would be awfully complicated to try to locate the right Julia package on disk without access to a running Julia process.

Yeah. There are probably better places for it than in the root $HOME directory (e.g. ~/.config or ~/.local on Linux maybe?) but changing it is likely to produce weird errors and this package isn't super active to begin with.

[davidanthoff]

Shouldn't this just be somewhere inside .julia? Other packages also put stuff there that they want to preserve across different package versions (e.g. Conda.jl).

I do think this should be updated. Software that just randomly puts files onto user systems really give a bad impression.

[twavv]

Shouldn't this just be somewhere inside .julia? Other packages also put stuff there that they want to preserve across different package versions (e.g. Conda.jl).

I think that's a little bit different since Conda.jl has to store many things and this is a one-off file.

I do think this should be updated. Software that just randomly puts files onto user systems really give a bad impression.

This is a subjective, mostly hypothetical concern with no easy migration path. Lots of software does this kind of thing, and while I agree that it's non-ideal, I think that the benefits are entirely aesthetic and it really does introduce the possibility for new bugs where there previously were none (and, again, this package really has no one to field those bugs if and when they arise).

---

I'm not trying to be argumentative, just realistic. I see the value in the change (if this were an as-of-yet unreleased package, I would have no qualms with putting the file in a different place), however, @shashi and I will be the ones who have to deal with the effects of any changes here, and neither of us is wont for more things to do.

[christopher-dG]

Here to add my support for keeping my home directory clean. This file should certainly be somewhere in a Julia depot! Otherwise, I will continue to delete it every time I see it. 😅

[twavv]

If you want to make a PR that addresses the concerns I enumerated above I’m more than happy to entertain it. 🤓

[christopher-dG]

I'll look into it 🙂

[twavv]

This will also need to be paired with a commit to WebIO to fix the jupyter extension I think.

[jwintersinger]

For what it's worth, jlassetregistry.lock is problematic in my environment. My university's compute cluster makes $HOME read-only on compute nodes, so anything that uses AssetRegistry.jl (namely PlotlyJS.jl) crashes. To accommodate Julia's precompile cache, I've set the JULIA_DEPOT_PATH environment variable to a writable location. Maybe AssetRegistry.jl could write to this location instead?