JULIA_PKGDIR and Julia-0.7

General Usage
1

How do I assign my own directory for packages in Julia - 0.7.0 (analogue of the definition of JULIA_PKGDIR in file juliars.jl for Julia-0.6)?
Windows 8, 10.

2

I think this is JULIA_DEPOT_PATH in v0.7.

1 Like
3

What are you using it for? It is highly likely that what you used it for in Julia v0.6 is not needed anymore with the new package manager.

4

Itā€™s very useful for me to avoid putting lots under my home directory (which sits on a network drive) and have it on local storage instead (though the OP could well have a different use case).

Though I notice that packages checked out with ]develop still end up in my home directory - Iā€™ve not worked out how to change that yet.

5

You can set ENV["JULIA_PKG_DEVDIR"] to change the default location of where Pkg puts packages that are deved.

Note that there is nothing special with this directory. You can put packages anywhere and dev localpath them (where localpath is the path to the local package).

2 Likes
6

Thanks, thatā€™s good to know.

7

So, if you have a package on GitHub in an org, the directory in ENV[ā€œJULIA_PKG_DEVDIRā€] will have a local git clone of the package if you do dev <packagename>?

8

Yes, in joinpath(ENV[ā€œJULIA_PKG_DEVDIRā€], PackageName). Not sure using an env variable for this is the best but that is how it is right now.

1 Like
9

That seems indeed to be the package development/update configuration. I still run into a chicken and egg situation for new packages where ā€˜developā€™ canā€™t resolve the package. In those cases I add the package to the v0.7 project, clone the package to the designated ā€˜devā€™ location and then execute ā€˜develop PkgNameā€™. I wonder if in the future ā€˜generateā€™ is supposed to simplify this step. Currently ā€˜generateā€™ creates a bare minimum project (I think, e.g. no License file, appveyor.yml, etc.).

10

Yes, it is barebone right now because when it was written it wasnā€™t clear exactly how things would look.

Some stuff related to this was recently fixed but please open issues with workflow problems.

1 Like
11

Thanks Kristoffer, yes, I understand (and agree with) the reasoning for keeping it barebone.

On the chicken and egg remark, Iā€™ll get back on that in an issue on Pkg (although I donā€™t think it is an issue, more a question about a suggested workflow, weā€™ve always had that intermediate step of uploading to Github). Once that has been done, Pkg.add() updates the uncurated registry.

12

We used JULIA_PKGDIR and JULIA_LOAD_PATH to share a set of common packages among users in a managed desktop environment for Linux, Windows and Mac hosts. What would be the preferred method to establish such behaviour with 0.7?

13

There are a few different ways and which one is best depends on your use case.

One way is to have your own registry. Pkg3 supports multiple simultaneous registries so by putting your own registry in .julia/registries (in addition to the default one) you can have your own set of packages, add and upgrade them exactly like the ones in the default registry. The tooling for setting up a registry is however lacking at the moment.

Another is to track git repositories using pkg> add localpath#branch where localpath is a path to a git repository. This works exactly like adding a repo at some branch from the internet. When commits are added to the branch, update will pull them in.

The third way is to track a directory, i.e. saying that julia should load the package from a certain path. This is done by doing dev localpath where localpath is a path to a package (doesnā€™t have to be a git repository). This simply tells julia that when loading the package, load it from that path. Any changes made to the files in that path is reflected when the package is reloaded.

4 Likes
14

@kristoffer.carlsson thanks for the explanations. The ideal solution would be something like a JULIAPATH environment (analog to Pythonā€™s PYTHONPATH) where one could specify a list of directories where to look for packages. This would be very useful for managed multi-user desktop environments.

15

That exists, itā€™s called LOAD_PATH and itā€™s controlled by the JULIA_LOAD_PATH environment variable.

16

When updating packages from Julia v0.6.3 to v0.7.0, I changed the directory to a non-system disk. Now they are in new path: JULIA_DEPOT_PATH.

Would it be safe now to delete the old packages in system disk?
(Win10+VScode)

17

I didnā€™t find JULIA_DEPOT_PATH in the documentation. Could this be added?

1 Like
18

Absolutely, see List JULIA_DEPOT_PATH under Environment variables in the docs Ā· Issue #29714 Ā· JuliaLang/julia Ā· GitHub. Feel like contributing?

1 Like