Надежная изоляция без копирования бинарника Python или отмена эффектов site.py
1,00
р.
Читаю PEP 0405 и вижу вот такую фразу:
Tools such as rvirtualenv, which do not copy the Python binary into the virtual environment, cannot provide reliable isolation from system site directories.
Весь гугль измучал, рассылки почитал, но но не могу найти почему cannot provide.
Казалось бы, для надежной изоляции, должно быть достаточно:
вернуть в ванильное состояние переменных в sys в частности, в sys.path восстановить из Py_GetPath и вычистить sys.modules от всего, что теперь не в нем проверить целостность __import__, в случае чего, восстановив через builtin___import__ (или PyImport_ImportModuleLevel) пробежать по sys.modules, проверив их нетронутость, а если что-то нарушено — нещадно перегрузить. Или даже просто перегрузить, не заморачиваясь каким-то анализом — простое друг надежного.
Да, действия не самые тривиальные, но как-то не верится, что нельзя привести интерпретатор к ванильному состоянию, нейтрализовав эффекты siteitecustomize/usercustomize. Все же есть под капотом, libpython все что нужно экспортирует, бери да переинициализируй интерпретатор. (Да, это повышает время запуска, я знаю, спасибо, временно проигнорируем этот аспект.)
Что я упускаю из вида?
Ответ
Одна из проблем решений типа RVirtualEnv заключается в не всегда корректной работе с директорией site packages.
Пример кода:
import sys import os import site
if __name__ == '__main__': site_packages_dir = site.getsitepackages()[0] site_pth_file = os.path.join( site_packages_dir, 'something_new.pth' ) project_root = os.path.dirname(os.path.abspath(__file__)) with open(site_pth_file, 'w') as f: f.write(project_root) f.close()
Tools such as rvirtualenv, which do not copy the Python binary into the virtual environment, cannot provide reliable isolation from system site directories.
Весь гугль измучал, рассылки почитал, но но не могу найти почему cannot provide.
Казалось бы, для надежной изоляции, должно быть достаточно:
вернуть в ванильное состояние переменных в sys в частности, в sys.path восстановить из Py_GetPath и вычистить sys.modules от всего, что теперь не в нем проверить целостность __import__, в случае чего, восстановив через builtin___import__ (или PyImport_ImportModuleLevel) пробежать по sys.modules, проверив их нетронутость, а если что-то нарушено — нещадно перегрузить. Или даже просто перегрузить, не заморачиваясь каким-то анализом — простое друг надежного.
Да, действия не самые тривиальные, но как-то не верится, что нельзя привести интерпретатор к ванильному состоянию, нейтрализовав эффекты siteitecustomize/usercustomize. Все же есть под капотом, libpython все что нужно экспортирует, бери да переинициализируй интерпретатор. (Да, это повышает время запуска, я знаю, спасибо, временно проигнорируем этот аспект.)
Что я упускаю из вида?
Ответ
Одна из проблем решений типа RVirtualEnv заключается в не всегда корректной работе с директорией site packages.
Пример кода:
import sys import os import site
if __name__ == '__main__': site_packages_dir = site.getsitepackages()[0] site_pth_file = os.path.join( site_packages_dir, 'something_new.pth' ) project_root = os.path.dirname(os.path.abspath(__file__)) with open(site_pth_file, 'w') as f: f.write(project_root) f.close()
