Julia: rename JULIA_HOME?

[StefanKarpinski]

JULIA_HOME is a bit confusingly named since it's home from the perspective of the julia program, not the home of julia-related files from the user's perspective. We should always talk about user-facing matters from the user's perspective, so I propose that we rename JULIA_HOME to JULIA_BIN_DIR. Ultimately, it would be nice for JULIA_HOME to be the user's Julia directory, (i.e. currently JULIA_PKGDIR but including rc files and such) but we may need a different name for backwards compatibility, like JULIA_USER_HOME.

[nalimilan]

+1. We could also use JULIA_PREFIX=$JULIA_HOME/.. instead, since IIRC JULIA_HOME isn't really used directly, but rather combined with relative paths which start with ../.

[stevengj]

Probably JULIA_BINDIR for consistency with PKGDIR, and because bindir is a traditional elision in Unixland.

[StefanKarpinski]

JULIA_PREFIX seems appealing if this is somewhat standard, @nalimilan, do you know if it is? Or maybe JULIA_BINDIR since it's fairly obscure so unlikely for someone to use accidentally.

[StefanKarpinski]

Accepted on the milestone, but the first task is to figure out what the name should be. Research on prior art in other languages is necessary.

[stevengj]

In Python it's called BINDIR on my system, essentially because get_config_var gets the Unix build variables:

>>> import distutils.sysconfig as sc
>>> sc.get_config_var('BINDIR')
'/usr/local/bin'

They also have sys.executable to get the executable path:

>>> import sys
>>> print sys.executable
/usr/bin/python

[stevengj]

There doesn't seem to be a good way to get this info in Ruby.

[StefanKarpinski]

Here's my argument for the prefix being the most basic thing we allow overriding:

1. This is how configure / autoconf / etc. work and this kind of thing is their bread and butter, so they're a good example to follow.

2. One generally wants to know the locations of a whole class of things, which can be derived from the prefix path with reasonable defaults: binaries live at joinpath(prefix, "usr", "bin"), shared libraries live at joinpath(prefix, "usr", "lib"), the standard library lives at joinpath(prefix, "stdlib"). We can additionally allow overriding individual locations, if necessary, but the prefix path should be the way to tell Julia the directory under which the standard stuff lives in a standard layout.

Putting these points together, I think we should use the GNU directory variables as a guide and have this arrangement for environment variables and corresponding Julia variables with defaults:

| environment variable | Julia variable | default |
|----------------------|----------------|--------------------------------------|
| JULIA_PREFIX | Sys.PREFIX | automatically set by julia |
| JULIA_BINDIR | Sys.BINDIR | joinpath(Sys.PREFIX, "usr", "bin") |
| JULIA_LIBDIR | Sys.LIBDIR | joinpath(Sys.PREFIX, "usr", "lib") |
| JULIA_SRCDIR | Sys.SRCDIR | joinpath(Sys.PREFIX, "src") |
| JULIA_BASEDIR | Sys.BASEDIR | joinpath(Sys.PREFIX, "base") |
| JULIA_STDLIB | Sys.STDLIB | joinpath(Sys.PREFIX, "stdlib") |

[yuyichao]

I think we should use the GNU directory variables as a guide

In that case the usr should be part of the prefix.

joinpath(Sys.PREFIX, "base")
joinpath(Sys.PREFIX, "stdlib")

These won't work. According to your current scheme it's /base and /stdlib on a system-wise install.

[JeffBezanson]

Right, PREFIX would be nice but I'm not sure it's possible to promise that a certain thing will be located at joinpath(Sys.PREFIX, "foo") on all platforms. The current locations of these things when installed are:

/usr/bin
/usr/lib
/usr/lib/julia  # system images
/usr/share/julia/base
/usr/share/julia/site/stdlib

src is not installed.

[yuyichao]

Other that the default value, the variable name is pretty standard for build system so it looks good to me. I don't think we necessarily have to bound to one default value on all systems either, they can all be set to a specific value relative to prefix at build time, on platform without a working package manager/for standalone binary build, they can certainly be changed (from what we currently use) to give a flatter directory structure if people like that..................

[stevengj]

I should also say that one of my biggest annoyances in PyCall was just figuring out where libpython was located, since Python doesn't provide a reliable/documented way to query python for this.

I think the main thing is to have Sys.BINDIR, Sys.LIBDIR, and Sys.INCLUDEDIR (for julia.h). I'm skeptical that we should have PREFIX, since this is not very useful by itself and may not be meaningful on Windows.

It would also be good to have Sys.JULIA and Sys.LIBJULIA for the full paths of the executable and the library, in case they are installed with nonstandard names (e.g. julia-0.6.exe).

[ararslan]

Seems like this could happen in 1.x, we'd just have to tell people that the new things are better and then remove JULIA_HOME in 2.0.

[StefanKarpinski]

Right, these don't need to all happen in 1.0; I think that all we need in 1.0 is to rename JULIA_HOME to JULIA_BINDIR and make it available internally as Sys.BINDIR instead of as Base.JULIA_HOME.