2008-11-06 2 views
2

Мне часто приходится вставлять пути в свой код, чтобы найти данные или, в некоторых случаях, специальные инструменты. Из-за этого я всегда использовал autotools - так просто вызвать sed, чтобы заменить несколько строк во время сборки. Тем не менее, я бы хотел найти более Pythonic способ сделать это, то есть использовать distutils или какой-либо другой благословенный способ построения/установки. Мне никогда не удалось найти что-либо, связанное с этим, в документации distutils, хотя так, как другие люди решают эту проблему?Python distutils и замена строк в коде

ответ

1

Для пулов модулей общая практика заключается в том, чтобы положить их в .pth файлов, таких как documented here. Модуль предоставляет пространство для привязки к конкретным сайтам, вы можете использовать его для адаптации вашей среды.

+0

Я всегда задавался вопросом, для чего нужны эти .pth файлы. – 2008-11-06 09:54:13

1

Ну, с distutils (в стандартной библиотеке) у вас есть «данные пакета». Это данные, которые находятся внутри самого пакета. Explained here how to do it. Это явно не идеально, так как вам придется использовать какие-то хаки __file__ для поиска местоположения данных во время выполнения.

Итак, тогда появляется setuptools (не в стандартной библиотеке), который также имеет способы поиска местоположения этих данных во время выполнения. Explained here how to do it. Но, опять же, у этого есть своя проблема, например, может возникнуть проблема с поиском файлов данных в удаленном необработанном пакете.

Есть также дополнительные сторонние инструменты. Тот, который я использовал, - kiwi.environ. Он предлагает каталоги данных и просмотр времени выполнения, но я бы не рекомендовал его для общего использования, так как он ориентирован на разработку PyGTK и расположение файла Glade.

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

+0

Я не думаю, что __file__ - это плохо. Это достойный способ найти, где модули, безусловно, лучше, чем вышеприведенная идея исправления строк жесткого кодирования в сценариях. – bobince 2008-11-06 11:12:39

+0

Я согласен на 100%, но яйцо-бригада не согласится. __file__ не имеет смысла в яйце. – 2008-11-06 13:10:58

-1

«Я часто нахожу нужным вводить пути в свой код» - для начала это не очень Pythonic.

В идеале ваш код живет в каком-то месте, таком как сайт-пакеты, и это конец этого.

Часто у нас есть установленное приложение, которое использует довольно фиксированный набор каталогов для рабочих файлов. В linux мы получаем эту информацию из переменных среды и файлов конфигурации, принадлежащих определенному идентификатору пользователя, который запускает приложение.

Я не думаю, что вы должны вводить пути в свой код. Я думаю, что есть лучший способ.

[Я только что написал наш инструмент установки приложения, который создает все конфигурационные файлы для довольно сложного приложения. Я использовал инструмент шаблонов Мако, чтобы сгенерировать все четыре файла из шаблонов.]

0

Здесь я не смог войти в систему, используя мой OpenID.

@ С. Лотт

точка хорошо принята, но для некоторых дистрибутивов Linux, кажется, является стандартным для установки данных конкретного приложения и конкретных приложениями модулей в определенных местах. Я думаю, что создание этих мест, настраиваемых при сборке/установке, - это хорошая вещь для людей, которые упаковывают мое приложение. AFAICS «pythonic way» в этом случае заставит этих упаковщиков применять исправления к моему коду.

У меня также есть привычка писать приложения, где исполняемая часть является крошечной оболочкой вокруг основной функции в модуле приложения.Для меня не кажется правильным придерживаться этого конкретного приложения в /usr/lib/python2.5/site-packages.

1

В настоящее время, лучший способ связать данные с кодом будет в setuptools пути и использовать pkg_resources:

from pkg_resources import resource_filename, resource_stream 
stream = resource_stream("PACKAGE", "path/to/data_f.ile") 

Это имеет преимущество также работает с яйцами Python. У этого недостатка (IMHO), что вам нужно поместить ваши файлы данных в свою кодовую директорию, которая является принятой практикой (одна из очень немногих практик, с которыми я не согласен).

Что касается дистрибутивов Linux, я могу (разумно) убедить вас, что ваша программа будет работать без каких-либо проблем (и исправлений) в любой современной системе, использующей Debian, если вы используете pkg_resources. Я не знаю о Fedora/openSUSE, но я бы предположил, что он работает.

Он работает на Windows, но в настоящее время он не работает с py2exe. Однако для этого существуют простые обходные пути.

Смежные вопросы