Add Julia

[jakirkham]

It would be really neat if we could package Julia at conda-forge. This would be a bit of an undertaking if we package all of its dependencies. However many of them have already landed. Given some of the dependencies are forks of original libraries we may not package them ourselves, but rely on Julia to do the heavy lifting. Would be curious to hear thoughts from others on this.

[jakirkham]

cc-ing you on this, @tkelman, as I think you know the most about Julia's dependencies.

[tkelman]

Ref #1482 (comment), it's not very likely that release versions of Julia will happen to use the exact same version of LLVM as whatever else is in conda-forge and wants to use LLVM as well. (And Julia 0.5 links against LLVM as a shared library in our default configuration.) We carry a large number of patches to LLVM and a few for other dependencies - mostly backported bugfixes, but our particular combination of patches hasn't been tested for use with say numba or pyston. You'd also need PCRE2, libgit2, libssh2, #1561, and a bunch of smaller things.

We already build binaries for Julia so don't need conda so much from the Julia side, except for use with Python-interoperability packages. As an easy solution you could just repackage those into a conda format, depending what your policies are for repackaging binary builds. Or see if you can clone and make Julia from source inside the conda-forge build environment without using pre-packaged anything.

[jakirkham]

Yeah one of the main motivation would be interoperability between Julia and Python. Another would be providing users that are comfortable with conda an easy way to get Julia.

Repackaging a binary would be IMHO undesirable. However, it does occur for more challenging tasks. Ultimately a move to source is pushed in any event.

It would be good to understand which things have lots of custom patches and which are untouched. That way, we can package the latter category separately (probably things like OpenBLAS, ARPACK, etc.) and make dependencies. The former category we can just leave to Julia to build.

Kind of unrelated, but how do you handle the BLAS issue on Windows with Julia?

[tkelman]

We use gfortran, problem solved. We don't support MSVC at all. Or rather we haven't had enough of a reason to get it working beyond hacky experiments.

See deps/patches for what we patch, though there might also be one or two places in some of our makefiles under deps that we do sed or perl replacements. Some dependencies also need to be built with a specific configuration, set of options, or flags. In our default source build BLAS and LAPACK and everything that link to them are built with 64 bit integers as well, as a point of difference to numpy that's worth noting. You can link to a 32 bit int system blas but it's not done that way by default.

[tkelman]

Getting Julia on Linux is downloading and extracting a tarball, it doesn't get much easier. It's a few lines more to unpack our dmg or exe installers as if they were archives, but conda is still a bit overkill.

[goanpeca]

https://github.com/tkf/conda-julia ?

[SylvainCorlay]

Subscribing.
I am working on a package that embeds the julia interpreter and packaging it for conda would require julialang itself to be packaged.

[dfornika]

I've ported over julia-0.5.2 that @acaprez prepared for bioconda in #3503. It's a source build.

I incorporated an idea from the https://github.com/tkf/conda-julia that @tkf prepared, so that julia packages are installed inside the conda env instead of the user's $HOME/.julia directory.