clj-python
requiring libpython-clj2.require initializes libpython-clj
Calling
(require 'libpython-clj2.require)
calls (via metadata) py/initialize! without parameters.
This is unexpected and defeats the existence of certain parameters to initialize!.
Maybe initialize!! could read a certain edn file on disk, and take parameters from there. (and not taking any parameters)
Then we could cleanly initialize lib-python very early.
We’ve talked about this extensively but I still don’t really see a great way around this. In libpython-clj3 we could make it so that the functions in require throw an exception if uninitialized. We can't do it in libpython-clj2 though because it would break all the existing code. The .edn file would work, I've implemented it before locally, but there hasn't been much of a demand for it. Perhaps a more subtle problem is that we ask Python for Python information, so require-python needs Python to be initialized. The only way around this I see is if we can somehow statically link the Python and the JVM instead of using a shared library -- maybe there's a GraalVM pathway in there somewhere.
Another fun option is a forked version of clojure that starts Python at the same time and you could do :require-python right in the namespace declaration.
I don't think statically linking will ever work - you still have python-path issues and then you would potentially be out of sync with numpy and any other c-based extension of python of which nearly all the really valuable ones are exactly that. You would not work in most cases with conda or virtualenv.
We could refactor the metadata namespace to make the things it relies on delay-initialized and then remove the call to initialize!.
More generally this issue and the issue with AOT projects is why the static code generation system exists, however. So you can sort of trial things with require-python but then move to static code generation and locking python to a specific thread and such for production - both of which solve a host of issues but make repl-driven development less effective.
@behrica would a python.edn solve this? @cnuernber do we want to make that an option?
@behrica let me know if this would resolve the issue: https://github.com/clj-python/libpython-clj/pull/226
I think so.
My use case is a s well "libraries" which use libpython clj. When and how to initialize lib-python clj is not obvoius.
Reading a local file could fix it, so every call to (py/initilize!) will reda the same file.