Можно ли встроить Jedi в приложение в системе, где Python не установлен?

Я работаю над приложением (для Windows и Mac), которое использует Python в качестве встроенного языка сценариев. .

Приложение включает внутренний текстовый редактор, реализованный с помощью Scintilla, а я использую Jedi для автозаполнения, которое обычно отлично работает.

Однако при попытке автодополнения на компьютере, на котором не установлена ​​отдельная установка Python, Jedi выдает ошибку:

jedi.api.environment.InvalidPythonEnvironment:

Не удалось получить информацию о версии для «python»:

FileNotFoundError(2, 'The system cannot find the file specified', None, 2, None)

Копаясь в коде, я вижу, что основной код, который генерирует FileNotFoundError, возникает, когда джедай пытается запустить python с помощью subprocess.Popen. Python не установлен на компьютере, поэтому это не удается.

Я также могу воспроизвести ту же проблему на компьютере, на котором действительно установлен Python, отредактировав переменную среды Path так, чтобы она не включала местоположение python.exe.

В идеале мы не хотим, чтобы пользователям нашего приложения приходилось устанавливать Python только для того, чтобы автодополнение работало.

Мои вопросы:

  1. Можно ли заставить Jedi не порождать подпроцессы, а вместо этого запускать свой код внутри того же экземпляра Python, в котором он сам работает? Я не смог найти ничего об этом в документации или исходном коде, относящемся к средам, и экстраполяции из обсуждение здесь Я подозреваю, что ответ может быть отрицательным.

  2. Можно ли каким-то образом заставить Jedi использовать тот же файл python37.dll, который использует наше приложение для своей функциональности, вместо того, чтобы искать несуществующий файл .exe?

  3. Можем ли мы каким-то образом сделать минимальную установку Python в нашей существующей установке приложения, которая использует те же библиотеки DLL/Python Lib и т. д.? Как я мог это сделать?

  4. Есть ли другой способ заставить автодополнение Jedi работать в нашем приложении, не требуя от пользователя установки Python или включая полный установщик Python как часть нашего процесса сборки?


python autocomplete subprocess scintilla python-jedi
person Rich    schedule 18.01.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

  1. Можно ли заставить Jedi не порождать подпроцессы, а вместо этого запускать свой код внутри того же экземпляра Python, в котором он сам работает? Я не смог найти ничего об этом в документации или исходном коде, который имеет дело с средами, и, экстраполируя обсуждение здесь, я подозреваю, что ответ может быть отрицательным.

Это определенно возможно. Все инструменты есть. Здесь ведутся обсуждения: https://github.com/davidhalter/jedi-vim/issues/870.

IMO требуется патч для Jedi, который использует jedi.api.environment.InterpreterEnvironment в некоторых случаях, таких как ваш. Это определенно возможно, просто на данный момент это глючит.

person Dave Halter    schedule 18.01.2019
comment
Спасибо за быстрый ответ! Я думаю, что, должно быть, неправильно истолковал часть связанного обсуждения, когда читал его раньше: я думал, что речь идет просто о поиске правильного пути к исполняемому файлу, а не о том, что исполняемый файл вообще не требуется. Сейчас прочитаю внимательнее. Спасибо! - person Rich; 18.01.2019
comment
Не совсем понятно, в чем проблема, мы просто знаем, что sys.executable неправильно. Это случай, который нам нужно правильно обработать в Jedi (а не в jedi-vim). - person Dave Halter; 18.01.2019
comment
Ради потомства, я думаю, что вариант 3 также, скорее всего, возможен и, вероятно, предпочтительнее, если бы я мог заставить его работать? Я попытался просто скопировать python.exe, созданный build.bat, в установку моего приложения и передать его путь в jedi.create_environment(). Это продвинулось немного дальше, но затем вызвало еще более непостижимую ошибку в вызове pickle_load. После того, как мне не удалось это диагностировать, я сдался и попытался просто передать jedi.api.environment.InterpreterEnvironment() в конструктор Script, и пока это работает нормально. - person Rich; 21.01.2019