RFC: add .../share/julia/site/v0.1 to default LOAD_PATH

[stevengj]

Yet another attempt at a patch to fix the first two bullet points in #2295 (replacing the patch in #2296, which had rebase problems).

Update: use site instead of lib, and include minor version number in path.

[StefanKarpinski]

Looks reasonable to me. @ViralBShah, @JeffBezanson?

[ViralBShah]

Looks good to me.

[stevengj]

(The Travis failure looks unrelated, some Travis breakage causing a problem building LAPACK?)

[nolta]

• Ruby and Python also include the version minor number, and we probably should too.
• The distinction between julia/VERS and julia/lib/VERS isn't very clear. I'd prefer julia/VERS and julia/site/VERS.

[StefanKarpinski]

Those both seem like sane suggestions to me.

[stevengj]

@nolta, these suggestions seem reasonable to me. (I had initially proposed including the minor version as well.) Note that Python sometimes breaks backwards compatibility between minor versions (I haven't checked with Ruby).

[StefanKarpinski]

Here's what I did on Pkg.dir – it looks in both the minor.major and in just major:

function dir()
    b = abspath(get(ENV,"JULIA_PKGDIR",joinpath(ENV["HOME"],DIR_NAME)))
    x, y = VERSION.major, VERSION.minor
    d = joinpath(b,"v$x.$y")
    isdir(d) && return d
    d = joinpath(b,"v$x")
    isdir(d) && return d
    return b
end

The presumption is that one would only use one or the other, but that would leave it up to the OS package system.

[stevengj]

I can certainly add both to the path. In the longer term, however, there is the question of whether Julia itself should install the files that come with it into /usr/share/julia/v$major or /usr/share/julia/v$major.minor .

My inclination is to pick one or the other rather than to have both. I can't imagine a reasonable circumstance in which having both in the path would be of much use, and it has the drawback of causing confusion about where things should be installed.

@StefanKarpinski's original argument was that, if you stick with semantic versioning religiously, you won't have backward-compatibility issues between minor versions (except for 0.x), unlike Python. In this case, having only the major version in the path name makes it easier to share packages between minor versions of Julia installed on the same machine. On the other hand, minor versions still won't be forward-compatible, so you still might want multiple versions of software installed to work with different minor versions of Julia. My inclination is towards the latter argument --- only bugfix releases leave the API unchanged (modulo bugs), so only bugfix releases will share packages forwards and backwards, hence MAJOR.MINOR should be in the path. At worst, it means that users with multiple versions of Julia installed on the same machine might need to install some external packages multiple times (or change the LOAD_PATH) in order to use them in the different versions simultaneously, which isn't so bad.

[ViralBShah]

I have been thinking about this and feel that MAJOR.MINOR is safer to go with.

[stevengj]

Note that the patch has been updated to use /usr/share/julia/site/v$major.$minor, per the discussion.

[ViralBShah]

Should make install create these paths as part of julia's directory structure? Pull request seems ok to merge.

[stevengj]

It's not strictly necessary for make install to create the site paths, and in particular you would typically not create any /usr/local directory, but it seemed like a good idea to create at least /usr/share/julia/site/v0.1 as a hint to people looking for a place to install files.

These should be documented in the manual somewhere too.

[nolta]

More nitpicks:

• JULIA_HOME/../local doesn't really make any sense unless JULIA_HOME == /usr/bin. I think we should just hard-code /usr/local instead.
• The site in /usr/local/share/julia/site/vX.Y seems redundant.

(sorry, the smallest commits often draw the most complaints ;)

[stevengj]

@nolta, regarding your second comment, I think it is clearer and more conventional (and simplifies life for makefiles that want to install into these directories) to look in the same relative paths under /usr/share and /usr/local/share. Furthermore, if we take your first suggestion and hardcode /usr/local/share/julia/whatever, this parallelism becomes essential if Julia itself is installed into /usr/local (which should be the default, BTW, for installation from source)

Regarding your first comment, if a user installs Julia into, say, /opt/, it is not completely clear to me that they would want Julia to be looking in the /usr hierarchy at all for load paths. It seemed safer to add a possibly nonexistent local directory to the load path than to hard-code it without regard for the installation directory.

(The stuff that Julia currently installs into /usr/share/julia, e.g. base, helpdb.jl, etcetera, should eventually be moved to /usr/share/julia/vX.Y so that different versions of Julia can co-exist on the same machine. But it is important to keep stuff that ships with Julia cleanly separated from stuff that is externally installed, hence site/vX.Y and not vX.Y/site.)

[stevengj]

Any further thoughts on this?

[ViralBShah]

Let's merge this. Quite satisfactory for now.