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.
On Thursday, September 3, 2015 at 3:17:38 PM UTC-4, Tero Frondelius wrote: > > 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. > > > On Thursday, September 3, 2015 at 10:00:36 PM UTC+3, Tony Kelman wrote: >> >> 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)? >> >> >> On Thursday, September 3, 2015 at 11:32:00 AM UTC-7, Tero Frondelius >> wrote: >>> >>> 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 >>> <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.) >>> >>> On Thursday, September 3, 2015 at 9:19:24 PM UTC+3, Tony Kelman wrote: >>>> >>>> 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. >>>> >>>> >>>> On Thursday, September 3, 2015 at 8:17:37 AM UTC-7, Cedric St-Jean >>>> wrote: >>>>> >>>>> 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. >>>>> >>>>> >>>>>> >>>>>> On Wednesday, September 2, 2015 at 11:17:38 AM UTC-7, Luthaf wrote: >>>>>>> >>>>>>> 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 : >>>>>>> >>>>>>> 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? >>>>>>> >>>>>>> Am Dienstag, 1. September 2015 14:42:31 UTC+2 schrieb Luthaf: >>>>>>> >>>>>>> Hi Julians! >>>>>>> >>>>>>> I am happy to present you the Conda.jl >>>>>>> <https://github.com/Luthaf/Conda.jl> package, a binary dependencies >>>>>>> manager for Julia based on the open-source conda >>>>>>> <http://conda.pydata.org/> 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 >>>>>>> >>>>>>>
