Hello everyone! I’ve been struggling with the Pyjulia installation process. It’s installed, but I still can’t seem to call python from julia. I can call python from julia, but so far it’s proving much more difficult to go in the other direction. I tried following the steps listed here: GitHub - JuliaPy/pyjulia: python interface to julia
When I’m in the command prompt, it seems that I am able to import julia with no issue after enabling python (version 3.6.5). However, when i try to create a julia object with the command j = julia.Julia(), I am getting the following error:
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\WINDOWS\system32>python
Python 3.6.5 |Anaconda, Inc.| (default, Mar 29 2018, 13:32:41) [MSC v.1900 64 bi
t (AMD64)] on win32
Type “help”, “copyright”, “credits” or “license” for more information.
import julia
j = julia.Julia()
Traceback (most recent call last):
File “”, line 1, in
File “c:\windows\system32\pyjulia\julia\core.py”, line 370, in init
self._call(u"using PyCall")
File “c:\windows\system32\pyjulia\julia\core.py”, line 412, in _call
self.check_exception(src)
File “c:\windows\system32\pyjulia\julia\core.py”, line 441, in check_exception
.format(exception, src))
julia.core.JuliaError: Exception ‘ArgumentError’ occurred while calling julia co
de:
using PyCall
I’m using Windows 8.1, in case that’s important. Any ideas why I’m getting this error? I have a version of julia from JuliaPro. I also used the instructions and ended up with a julia executable file in my Anaconda folder, where my python is stored. Thank you!
I uninstalled JuliaPro, installed the latest Julia v.0.6.3, redid the steps in the aforementioned link, and everything worked! I couldn’t update any of the files in JuliaPro due to the REQUIRE file among other things. It seems that installing just Julia by itself works much better!
This has always been a troubled package. The problem is that most of us using Julia desperately want to not use Python so we don’t do any work on this package. I kept having an intention to work on the package, but kept finding ways not to use Python, so I haven’t done any actual work on it.
I understand completely (and wish I had the skills to help). The benefit of a solid pyjulia is that it makes it possible to have… a 2 language solution
Sounds ridiculous, but if you are working in a team and not everyone is capable of using Julia, then having a python interface to julia is the next best thing to all julia.
As much as I rail against Python, you’re absolutely right, this package really should be well-maintained, it’s important to the health of Julia as a whole even if that’s not immediately apparent. There was that huge thread about Julia in data science; I think that one of the ways Julia could make it into data science is if people just blissfully keep using Python, but more and more back-end stuff is written in Julia, and then one day years from now those people will ask themselves why they were ever using Python in the first place (that’s my dream at least).
As I’ve said before, I’m definitely willing to contribute a significant effort to the maintenance of pyjulia, but only once I absolutely need it in order to keep using Julia for my day job. That never seems to happen, however, and with tools like Kubernetes and microservices, there’s at least some possibility that it never will, at least at my current position.
Last I looked into this, I do not think that Python 2.7 is in any way more stable, you should be just fine using Python 3.6, but again, it’s been a while since I really looked into it.
Just how unstable do you suspect the current version of PyJulia is? My ultimate goal on a project I’m working on is to call a program already written in Julia and let it run using data from Python. Is this likely to fail? I’m using the latest Python version, and now that I’m using the standalone version of Julia, all of the packages are up to date. I believe the older packages in JuliaPro are what were causing my issues earlier.
I asked @ChrisRackauckas about instabilities, and the impression he gave was that “it worked for him”. That is, I think it is installation fragility/etc. more than actual instability that is the problem. If you have control over the setup, then it might not be an issue. But that is 2nd hand, and he said he only tried on linux.
I’m probably not alone in suspecting that the biggest increase in adoption rate will come from Julia offering a stable API. We may well see a dam-breaking phenomenon once people believe that using Julia is safe. I recall the hackers in a physics department recommending that people replace SG and Sun machines with (gnu-) linux. It fell on deaf ears. Very few years (<5) later, no one who used unix had anything but linux is their office. But, python will be around in technical computing for a long time. As soon as Julia has taken a significant fraction of that market (maybe even 5 or 10 percent) then PyCall and pyjulia will both receive a lot of attention.
I would say if you get it working, and you are just doing a few basic function calls, you will probably be fine. If you have some ongoing development that crucially depends on a 2-way interaction between Python in Julia, my guess is that you’ll probably encounter bugs. I don’t mean to completely scare anybody off of using it, and I should emphasize that I am not actually involved in its development, this is just my take as an interested observer who’s dug through it’s source code a bit (many months ago). The actual developers may have more insight.
I should also emphasize that PyCall and pyjulia each simply wrap robust and reliable C API’s, so there’s a solid foundation here. (And PyCall has been very reliable, so I wouldn’t worry about that end.)
At the risk of seeming to contradict my earlier statement, I don’t think using Julia being safe depends on it having a stable Python API, particularly today with the increasing usage of “cloud” and modular architectures. I’m in the process of getting my Julia component to a moderate sized project get set up with all sorts of data IO between different processes, and, perhaps surprisingly, the ability to call Julia from Python so far doesn’t seem particularly useful. The data getting output from Julia is getting sent to a database and some binary files, and the (pure Julia, or direct Julia wrapping of C) tools available from within Julia seem perfectly adequate.
I agree that having a really good Python API would drastically increase the adoption of Julia in certain circles in the medium term. There are undoubtedly a significant number of people out there who won’t go anywhere near the thing without this, as much as that bothers me.
This is all open source software, so the only solution is for someone to come along and work on it. Like I said, I’m a potential volunteer, but only if I need it. So far I’ve been surprised by how little use I would have for this. I’m sure if someone else were to come along and start working on it right now, we’d all be hugely appreciative, but whether or not that happens is probably not something anyone here has much control over.
I don’t think using Julia being safe depends on it having a stable Python API, particularly today with the increasing usage of “cloud” and modular architectures…
I didn’t mean to imply that an interface to Python is necessary for Julia to be accepted. I meant something more like: Python and Julia are both open projects that put a great emphasis on developing their ecosystems. Python has a large part of the technical computing market (in some sense). When Julia obtains a significant part of this market, there will be big demand for interoperability. As you mentioned, its not rocket science, rather just interfacing with C libraries. So investment in the the APIs will be a response to, or grow with, the increased use of Julia, simply as a result of the demand.
