Развертывание приложения Python с общим пакетом

Question

Я думаю, как организовать развернутое приложение Python, которое будет иметь

1. Исполняемый скрипт, расположенный в /usr/bin/, который предоставит интерфейс командной строки для функций, реализованных в
2. Библиотека, установленная там, где находится текущий каталог site-packages.

Сейчас в моих источниках есть следующая структура каталогов:

foo.py
foo/
  __init__.py
  ...

что, я думаю, не лучший способ делать что-то.Во время разработки все работает так, как ожидалось, однако при развертывании код «from foo import FooObject» в foo.py, по-видимому, пытается импортировать сам foo.py, а это не то поведение, которое я ищу.

Итак, вопрос в том, какова стандартная практика организации подобных ситуаций?Одна из вещей, о которой я мог подумать, это переименовать foo.py при установке в просто foo, что не позволит ему импортировать себя, но это кажется довольно неуклюжим...

Я полагаю, что другая часть проблемы заключается в том, что это проблема именования.Возможно, вызвать исполняемый скрипт foo-bin.py?

Answer 1

Эта статья довольно хорошо и показывает вам хороший способ сделать это.Второй предмет из Делать список отвечает на ваш вопрос.

бессовестный копипаст:

Структура файловой системы проекта Python

к Дж. П. Кальдероне

Делать:

• назовите каталог как-нибудь, связанный с вашим проектом.Например, если ваш проект назван «Twisted», назовите каталог верхнего уровня для его исходных файлов Twisted.Когда вы делаете выпуск, вы должны включить суффикс номер версии: Twisted-2.5.
• создать каталог Twisted/bin и поместите там исполняемые файлы, если у вас есть.Не давайте им .pyРасширение, даже если они являются исходными файлами Python.Не ставьте в них код, кроме импорта и вызовите основную функцию, определенную где -то еще в ваших проектах.
• Если ваш проект выражается в виде единого исходного файла Python, поместите его в каталог и назовите его что -то связанное с вашим проектом.Например, Twisted/twisted.py.Если вам нужно несколько исходных файлов, вместо этого создайте пакет (Twisted/twisted/, с пустым Twisted/twisted/__init__.pyи поместите в него свои исходные файлы.Например, Twisted/twisted/internet.py.
• Поместите ваши модульные тесты в подпакете из вашего пакета (примечание - это означает, что вариант одного исходного файла Python был приведен в трюке - вам всегда нужен хотя бы один файл для ваших модульных тестов).Например, Twisted/twisted/test/.Конечно, сделайте это пакетом с Twisted/twisted/test/__init__.py.Поместите тесты в файлы типа Twisted/twisted/test/test_internet.py.
• добавлять Twisted/README и Twisted/setup.py Чтобы объяснить и установить свое программное обеспечение соответственно, если вы чувствуете себя хорошо.

Не:

• поместите исходный код в каталог с именем src или lib.Это затрудняет работу без установки.
• поместите свои тесты за пределы вашего пакета Python.Это затрудняет запуск тестов против установленной версии.
• создайте пакет, который имеет только __init__.py а затем поместите весь свой код в __init__.py.Просто сделайте модуль вместо пакета, это проще.
• Постарайтесь придумать магические взломы, чтобы Python мог импортировать ваш модуль или пакет, не заставляя пользователя добавить каталог, содержащий его в свой путь импорта (либо через PYTHONPATH или какой -то другой механизм).Вы не будете правильно обрабатывать все случаи, и пользователи будут злиться на вас, когда ваше программное обеспечение не будет работать в их среде.

Answer 2

Distutils поддерживает установку модулей, пакетов и сценариев , Если вы создаете distutils setup.py , который ссылается на foo как на пакет и foo.py как на скрипт, тогда foo. py должен быть установлен в / usr / local / bin или в любой другой путь установки сценария в целевой ОС, а пакет foo должен быть установлен в каталог site_packages .

Answer 3

Вы должны называть исполняемый файл просто foo , а не foo.py , тогда попытки импорта foo не будут его использовать.

Что касается правильного наименования: на этот вопрос трудно ответить абстрактно; нам нужно знать, что конкретно он делает. Например, если он конфигурирует и управляет, может быть уместно назвать его -config или ctl. Если это API оболочки для библиотеки, оно должно иметь то же имя, что и библиотека.

Answer 4

Ваш CLI-модуль - это одно, а пакет, который его поддерживает, - это другое. Не путайте имена с модулем foo (в файле foo.py ) и пакетом foo (в каталоге foo с файлом __ init __. py ).

У вас есть две вещи с именем foo : модуль и пакет. Что еще вы хотите назвать foo ? Класс? Функция? Переменная?

Выберите отличительное имя для модуля foo или пакета foo. foolib , например, является популярным именем пакета.