0

I need port some python code in my rust project (calling python from rust).

I am writing an app in rust that in a small part needs to import a module written in python.

This is my project structure.

|...
|extern/python/
|-main.py
|-__init__.py
|src/
|Cargo.toml
|...

I have no problem with executing python code from rust, pyo3's docs cover this.

But I need specify to pyo3 what virtualenv use to link to my rust crate, almost all of the pyo3's docs is focused on how to use rust from python and there is very little information about how to use python from rust.

In my python code y use pyenv to isolate the virtualenv, e.g. to run the python code

cd /python/code
pyenv shell my_py_env
python3 main.py

So the thing is, how can I tell to pyo3 to use "my_py_env" when linking the python module?

al3x
  • 589
  • 1
  • 4
  • 16
  • Why can't you have the v-env activated when you build and run the Rust code? – 9769953 Dec 04 '22 at 09:09
  • I'm sorry, I don't understand how to do it. Of course I understand the rust compilation cycle, and I understand that you mean that I should specify the v-env activation in the build.rs file. The problem is that I wasn't clear how pyo3 links the virtual environments, anyway @rmax59 answer seems to work for me. – al3x Dec 04 '22 at 09:20
  • 1
    "I should specify the v-env activation in the build.rs file": not particularly: I mean, have the v-env active when you build and/or run the Rust application. Activated from the shell; not from build.rs or something. – 9769953 Dec 04 '22 at 09:35
  • 1
    The disadvantage of the current answer is that if you ever move the v-env (or simply rename it), it won't work, because you don't have control from the "outside" (user environment) on the Python path settings. That's why, to me, envvar settings should always be done *outside* of the program, which in this case is equivalent to having the v-env active. – 9769953 Dec 04 '22 at 09:37
  • I get this when I run it with v-env enabled ``` error: The `auto-initialize` feature is enabled, but your python installation only supports embedding the Python interpreter statically. If you are attempting to run tests, or a binary which is okay to link dynamically, install a Python distribution which ships with the Python shared library. ``` actually setting it through environment variables also gives me problems. – al3x Dec 04 '22 at 10:08
  • ok it seems that I should deactivate the `auto-initialize` option – al3x Dec 04 '22 at 10:10
  • ok I think I understand it, dynamic linking takes the global python interpreter from the operating system, while static linking takes the binary from the interpreter and attaches it to build, and it seems that the `auto-initialize` option is incompatible with static linking. – al3x Dec 04 '22 at 10:15
  • 1
    Ok, I don't know about auto-initialize. But if you find a solution that works for you (and that is not the current answer) and that you feel is better (or about equally good), it may be useful to self-answer your question. Because the problem-and-solution does sound useful, and together with rmax59's answer, it would show multiple ways of dealing with this. – 9769953 Dec 04 '22 at 10:17

0 Answers0