[ANN] Conda.jl: using conda package manager for Julia

[Luthaf]

Hi Julians!

I am happy to present you the Conda.jl package, a binary dependencies manager for Julia based on the open-source conda package manager.

Some interesting features of the Conda package manager:
 - You can easily add your own software and use your own channel for software distribution;
 - You can install packages as non root on Linux;
 - Conda is cross-plateforme, and you can use it for all your binary dependencies, provided the binaries have been uploaded.

I'll love to have your input on the code or the functionalities.

Cheers
Guillaume

[Jeffrey Sarnoff]

It would help to have explicit examples for adding a package from Julia package central (I assume this the default) and adding one from some other github location.

[Luthaf]

I don't get what you mean. By package, you mean binary package ? In this case, there is no Julia central channel (a channel is a package source in conda), and you can use your very own by pushing the URL to `Conda.CHANNELS` before anything else.

Or if you mean Julia package, Conda is not a Julia package manager. It is a binary package provider, for use with BinDeps. It allow to distribute C/C++/Fortran libraries with the Julia package.
This is only useful when building a Julia Package which one is calling an external C library.

Jeffrey Sarnoff a écrit :

[Jeffrey Sarnoff]

That is clearer to me; maybe include "Conda is not ... external C library" in the README.

[Uwe Fechner]

Julia does have a very good internal package manager, that can also install binary dependencies cross-platform.
Why would you want to add another package manager?

[Luthaf]

I do not want to replace the Base.Pkg package manager. Pkg does install binary dependencies in a cross-platform way, but only by the mean of BinDeps. And BinDeps uses for that the concept of provider. Some example of providers are Hombrew.jl on OSX, Pacman on arch-linux, Yum on centos/fedora distro, AptGet on debian distro, WinRPM.jl for windows. But all these providers are not cross-platform, and you even need root access for using some of the Linux providers (Pacman, Yum, AptGet).

Conda.jl is an other BinDeps provider, which can be used for all platforms, effectively replacing any other provider. It can also be used without administrator rights on Linux.
So it is not a Base.Pkg replacement, but an other way to get binary dependencies installed with it.

I now realize that this was not clear on my initial message, sorry about that. I will also improve the README.

Uwe Fechner a écrit :

[Tony Kelman]

There was quite a bit of discussion on this at https://github.com/JuliaLang/METADATA.jl/pull/3238, and https://github.com/JuliaLang/BinDeps.jl/issues/151 before that. Conda.jl should be pretty useful as a BinDeps provider of binaries, especially if binaries of a library you're interested in are already available in Conda for Linux or OS X. On Windows the binaries are not as likely to be compatible with Julia, but it's worth trying.

What hasn't been done yet, but potentially could be, would be adding Julia and Julia packages to Conda so you could do "conda install julia" or "conda install DataFrames.jl" or similar. I'm not sure whether that would really solve all that many problems since you're adding an extra installation and packaging (and future updating) step beyond what we already do with base Julia, Pkg, and METADATA, but if anyone out there really wants to see that happen you're welcome to go for it.

[Cedric St-Jean]

On Thursday, September 3, 2015 at 1:29:03 AM UTC-4, Tony Kelman wrote:

What hasn't been done yet, but potentially could be, would be adding Julia and Julia packages to Conda so you could do "conda install julia" or "conda install DataFrames.jl" or similar. I'm not sure whether that would really solve all that many problems since you're adding an extra installation and packaging (and future updating) step beyond what we already do with base Julia, Pkg, and METADATA, but if anyone out there really wants to see that happen you're welcome to go for it.

If `conda install julia` is a thing, then a Python user could `conda install py_juMP`. That strikes me as a big deal for convincing Python library writers to ditch C and write their code in Julia instead.
 

[Tony Kelman]

That's fair. Not being a Python library writer, I don't know what issues are preventing the likes of https://github.com/JuliaLang/pyjulia from being more widely used. I suspect that ease of installation is probably not the biggest factor keeping this from being a more common use case right now, and development time would likely be better spent addressing functional and usability issues rather than conda-izing what we have today.

[Tero Frondelius]

I think you answered yourself. As an Anaconda user I will type: conda install X and after this the X starts working even with the open Jupyter notebook by just importing the X. Now when you just look the https://github.com/JuliaLang/pyjulia/blob/master/README.md you lost major part of the Anaconda users. The "requirement" is to have something as convenient as conda install pyjulia. (I would have written pip install pyjulia, but it's not supporting binary dependencies.) 

[Tony Kelman]

If you want to see it happen, make it happen. The problem here is most of the people who do development work on Julia itself don't want to write in Python any more (or never did). If you spend a lot of time going back and forth between Python and Julia, then sure conda works much better than the alternatives for the Python parts. Would it be enough better than what we currently have for the Julia parts to be worth the maintenance effort of setting everything up as conda packages (and keeping them all updated)?

[Tero Frondelius]

Sorry you got me wrong. I found Julia thus I don't want to use Python anymore for the new stuff. I think this is the case for most of the Julia users, like you said. I was just trying to answer your question why pyjulia is not used intensively. Anyway I will promise to ask my colleague, if he will see it an easy transition from Python to Julia he will probably do the conda package in couple of hours.

[Jake Bolewski]

pyjulia was mostly created to show off interop and for demos.  I don't think anyone uses it seriously.  It might make more sense now with precompilation as it used to take 10+ seconds to load PyCall and initialize Julia.