Как систематически идентифицировать зависимости, которые Python имеет в своем доступном дереве пакетов / модулей?
Вопрос: Как я могу систематически исследовать файлы, которые вовлечены в любое время интерпретатором (например, в режиме отладки).
Когда все терпит неудачу, я получаю сообщение об ошибке. Я прошу об обратном: все работает, но я не знаю, сколько ненужного мусора у меня есть по сравнению с его использованием, хотя я могу представить, что что-то вроде pynotify, вероятно, может проследить его.
контекст:
Я провел все утро, упражняясь методом проб и ошибок, чтобы получите пакет для работы. Я уверен, что скопировал соответствующий пакет python по крайней мере в 3 каталога и сильно испортил мою windows setx -m path
с мусором. Теперь мне интересно, Как очистить все это, не нарушая никаких зависимостей, ина самом деле учиться у процесса .
Я не могу быть единственным, кто интересуется этим. Должно быть, какой-то талантливый тест-разработчик написал сценарий / пакет, который:
import everything from everywhere
check for all dependencies
E = list(errorMessages)
L = list_of_stuff_that_was_used
print L
print E
Таким образом, если у меня есть что-то, что хранится не в L
, я могу удалить его. Но, конечно, зондирование должно быть тщательным, чтобы исчерпать все доступные файлы (или, по крайней мере, активно используемые каталоги).
О чем вопрос не :
Меня не интересует, что находится на sys.path
. Это тривиально.
Еще Один Контекст:
Я знаю из руководства автостопщиков по упаковке, что будущее этой проблемы рассматривается, однако она не исследует прошлое. Так что с переходом на Python 3 * х 2хх для этого проблема должна становятся все более и более актуальными?
1 ответ:
Динамическая природа python делает эту задачу практически невыполнимой.
Функции тоже могут импортировать, например. Вы собираетесь запускать весь код во всех модулях?
И далее идут тесты обратной совместимости; импортируйте
Пакетыpysqlite2
, еслиsqlite3
нет, используйте модуль backport, еслиcollections.Counter
нет в текущей версии Python и т. д. Существуют платформенные модули (os.path
isposixpath
,ntpath
(тот же код, но переименованный) илиriscospath
в зависимости от текущей платформы), и импорт всей продажи в основной модуль (posix
,nt
,os2
,ce
иriscos
все может быть использовано модулемos
в зависимости от платформы для предоставления функций)., использующие
setuptools
, объявляют свои зависимости и обнаруживаются через библиотекуpkg_resources
. Это предел того, что выможете разумно обнаружить.