I got a new Ubuntu Xenial (16.04) workstation at my new job.
I absolutely know it is recommended to download Julia from julialang.org , however out of curiosity I used apt-get to install the distro supplied Julia. Version 0.4.5
Again I realise Xenial dates from 2016 so this reflects the version.
I guess what I am saying is this might cause a lot of confusion when 0.7 and 1.0 comes along.
Even in Artful )17) the Julia version is 0.4.7
I can see this causing a lot of confusion when Julia 1.0 is released. Julia 0.4.7 is very deprecated.
Lik eit or not, many people will try to use the distro supplied versions. I can imagine that also in companies the distro supplied versions will be the onyl ones supported. Thsi is of course where JuliaPro comes in!
Thankyou both for the reply.
I queried the Julia package, the maintainer is just reported as the Ubuntu-devel-discuss mailing list.
I wonder if this is one of these 'orphaned"packages with no maintainer. Do I hear āwell colunteer thenā¦ā?
This is pretty much the same with all software, except for those Ubuntu packages which were updated with security patches. Software in 16.04 is by construction from before April 2016.
Maintainers of rapidly developing software now seem to prefer other ways of distribution, commonly snap. Having a Julia snap package would be great.
@Tamas_papp@tkoolen I agree. I am on the HPC side of things, and one of my frequent rants is about people who use the distro supplied versions of (say) openMPI (the parallel transport libraries) and then find they are woefully out of date. The technique in HPC is to deploy the vanilla OS, then to deploy highly up to date libraries like that on a shared filesystem, or the OS image, and the user puts them into the PATH using Modules.
Of course that is why containerisation is becoming more and more popular. I am a fan of Singularity https://singularity.lbl.gov/ (note to self - a Singularity container with the latest Julia is a good thing)
Looking at snaps, this sounds an excellent idea.
I guess we are getting away from the concept of a monolithic āOperating Systemā which has set versions of libraries, software packages, compilers etc. which ar einstalled via the all-powerful Administrative user.
OSes will be seen as a base platform which provides the metal (ie CPU, storage, netwwork) upon which the user decides to deploy applications. And this is good.
For those curious, this approach is using the environment modules. Usually I just dump the Julia binary distribution into /opt/julia/$VERSION and use a simple modulefile like this:
#%Module -*- tcl -*-
proc ModulesHelp { } {
puts stderr "Julia, a high-performance language for technical computing (0.6.2)."
}
module-whatis "Julia, a high-performance language for technical computing (0.6.2)."
set root /opt/julia/0.6.2
prepend-path PATH $root/bin
prepend-path MANPATH $root/share/man
With one modulefile per version, it then is quite easy to switch between versions with the module switch command.
Once Pkg3 matures, it will also make sense to define environment modules for adding to the JULIA_DEPOT_PATH environment variable.
We should probably contact Debian and tell them that if they arenāt able to package 0.7/1.0, theyād better drop the julia package altogether. Itās expected that distribution packages lag behind upstream, but at least they should reflect the latest version available at the time when the distribution was released. It hasnāt made any sense to ship Julia 0.4.7 for a long time already.
I agree with @traktofun Pkg3 and Modules are going to be fantastic together. I would buy a new hat now if I were you. (British reference to preparing for an upcoming wedding)
@nalimilan thnakyou. but look at this from the Debian ticket:
The situation regarding the lack of TLS support in Debianās libgit2
package remains unchanged. The OpenSSL license is incompatible with
commonly used GPL versions. Although libgit2 has an OpenSSL license
exception, julia uses at least one other GPL-licensed library (FFTW)
without such an exception.
I already had a thread regarding package uploads failing from behind a corporate firewall. I think this is the same issue.
Given that there is no release date for v1.0 on the Julia side, I donāt see how Debian could commit to anything on this issue. The reasonable solution is to drop Julia.
I plan to make a stab at snap packaging v0.7 in a few weeks.
Actually the problem isnāt Julia, itās libgit2 and OpenSSL. If Debian are not willing to apply the libgit2 patch we use to support MbedTLS before itās merged and released upstream, they wonāt be able to package 0.7 nor 1.0 anytime soon, whatever its release date.
That would be nice. Iāve recently prepared a Flatpak package, and by supporting these two formats we would provide a simple solution for users of most recent distributions.
Did you make it public yet? I would be interested in trying it.
I know little about these formats, but perhaps if we have Flatpak, snap would be redundant. Also, I have heard that Flatpak is easier to deploy, snap seems very Ubuntu-centric (and mostly pushed by Canonical).
The third format I would consider is AppImage, here is a comparison.
Given that some distributions prefer Snap (mostly Ubuntu) and others Flatpak (Fedora), thereās probably room for both, though it would be nice to be able to support only one format. Iām not familiar with AppImage, but their comparison is clearly oriented even if itās not unininteresting. The fragmentation of formats is really too badā¦