PyJulia not working with Julia 1.6 and Python 3.9
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Área
- developer-experience, tooling
Línea de trabajo
Comienza con el punto de entrada Julia(...) en julia/core.py y reprodúcelo en la imagen de Docker de Jupyter referenciada usando Python 3.9 y Julia 1.6. Compara la llamada fallida a Base.require a través de PyJulia con la misma llamada desde el ejecutable de Julia, usando como contexto la configuración de PyCall del Dockerfile. Se considera completado cuando PyJulia se inicializa correctamente en ese entorno y el fallo queda cubierto por una comprobación de regresión.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
This looks a lot like: https://github.com/JuliaPy/pyjulia/issues/425 . Apologies ahead of time if this is just adding noise.
I'm working on a Jupyter Docker Image, where we previously supported PyJulia. This was working with an older base image that used Julia 1.2 . We're now updating to a newer jupyter image, which is pulling Julia 1.6, and PyJulia, has now started failing.
Here's my code:
from julia.api import Julia
jl = Julia(compiled_modules=False, debug=True)
And here's the output:
DEBUG (428)
DEBUG (428) Debug-level logging is enabled for PyJulia.
DEBUG (428) PyJulia version: 0.5.6
DEBUG (428)
DEBUG (428) pyprogramname = /opt/conda/bin/python3
DEBUG (428) sys.executable = /opt/conda/bin/python
DEBUG (428) bindir = /opt/julia-1.6.0/bin
DEBUG (428) libjulia_path = /opt/julia-1.6.0/bin/../lib/libjulia.so.1
DEBUG (428) py_libpython = None
DEBUG (428) jl_libpython = /opt/conda/lib/libpython3.9.so.1.0
DEBUG (428) is_compatible_python = False
DEBUG (428) compiled_modules = 'no'
DEBUG (428) argv_list = [b'/opt/conda/bin/python', b'--compiled-modules', b'no']
DEBUG (428) argc = c_int(3)
DEBUG (428) jl_parse_opts called
DEBUG (428) argc = c_int(0)
DEBUG (428) calling jl_init_with_image(/opt/julia-1.6.0/bin, /opt/julia-1.6.0/lib/julia/sys.so)
DEBUG (428) seems to work...
DEBUG (428) exception occured? 140585542159504
---------------------------------------------------------------------------
JuliaError Traceback (most recent call last)
<ipython-input-1-85ca7f15393c> in <module>
5
6 from julia.api import Julia
----> 7 jl = Julia(compiled_modules=False, debug=True)
/opt/conda/lib/python3.9/site-packages/julia/core.py in __init__(self, init_julia, jl_init_path, runtime, jl_runtime_path, debug, **julia_options)
501 # Currently, PyJulia assumes that `Main.PyCall` exsits. Thus, we need
502 # to import `PyCall` again here in case `init_julia=False` is passed:
--> 503 self._call(IMPORT_PYCALL)
504 self._call(u"using .PyCall")
505
/opt/conda/lib/python3.9/site-packages/julia/core.py in _call(self, src)
536 # logger.debug("_call(%s)", src)
537 ans = self.api.jl_eval_string(src.encode('utf-8'))
--> 538 self.check_exception(src)
539
540 return ans
/opt/conda/lib/python3.9/site-packages/julia/core.py in check_exception(self, src)
585 else:
586 exception = sprint(showerror, self._as_pyobj(res))
--> 587 raise JuliaError(u'Exception \'{}\' occurred while calling julia code:\n{}'
588 .format(exception, src))
589
JuliaError: Exception 'LoadError' occurred while calling julia code:
const PyCall = Base.require(Base.PkgId(Base.UUID("438e738f-606a-5dbb-bf0a-cddfbfd45ab0"), "PyCall"))
I'm working with Jupyter, with an image based on: https://github.com/jupyter/docker-stacks/blob/master/datascience-notebook/Dockerfile (but with PyCall also installed and precompiled via our Dockerfile).
If I run PyCall = Base.require(Base.PkgId(Base.UUID("438e738f-606a-5dbb-bf0a-cddfbfd45ab0"), "PyCall")) from the /opt/julia-1.6.0/bin/julia executable, it does work... so it appears PyCall is installed for that executable. I'm unsure how to get PyJulia to see the package - and I'm not sure if I'm missing something obvious.
- Lenguaje dominante
- Python
- Estrellas
- 893
- Forks
- 101
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de JuliaPy/pyjulia
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 20/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
-
Kill existing Julia sessionAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Todos los issues de JuliaPy/pyjulia
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
NVIDIA/earth2studio#1241 ·
Los mantenedores suelen responder en 3 días
-
docs(types): update the collection binding note now that typed collections shipped in pycubrid 1.9.0Abiertodocumentation priority: low size: S
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
cubrid-lab/sqlalchemy-cubrid#768 ·
Los mantenedores suelen responder en 1 día
-
--csv-bom was never wired up: PR #850 added an unused helper parameter, so #846 is not fixedAbiertobug help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
Broken link in index.rstAbiertodocumentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
ansys/pydpf-core#3547 ·
Los mantenedores suelen responder en 1 día
-
good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
OktoLabsAI/okto-pulse#114 ·
Los mantenedores suelen responder en 1 día