Очень типичная настройка для Docker контейнеров - использовать собственные инструменты упаковки языковой среды выполнения, а затем выполнить минимум, необходимый в Dockerfile
для установки приложения с его использованием. Вот что здесь происходит.
Ядро среды упаковки Python - это сценарий setup.py
, который описывает, как установить пакет. В этом репозитории setup.py
использует пакет с именем pbr , который перемещает большую часть настройки в файл конфигурации без кода, setup.cfg
. Он содержит блок:
[entry_points]
console_scripts =
promenade=promenade.cli:promenade
console_scripts
является стандартной частью библиотеки Python setuptools
. Когда вы запускаете pip install
(или ./setup.py install
), он создает сценарий оболочки с именем promenade
в каталоге bin
текущей установки. Этот сценарий просто запускает Python, импортирует модуль promenade.cli
и вызывает в нем функцию promenade()
.
Если у вас есть локальная проверка этого, вы можете увидеть это, используя виртуальный Python environment:
# Create a new virtual environment
python3 -m venv venv
# Install this package in that virtual environment
./venv/bin/pip install .
# See the new wrapper script
ls -l ./venv/bin/promenade
В контексте Docker вы обычно не используете виртуальную среду: образ Docker изолирован от хост-системы, и обычно только одно приложение устанавливается в образ, поэтому конфликтов не будет, если вы используете "системный" python. Dockerfile
в этом репозитории на самом деле просто запускает pip
:
COPY . /opt/promenade
RUN pip install -e /opt/promenade
В отсутствие виртуальной среды pip install
для системы python обычно устанавливает эти консольные скрипты в /usr/local/bin
, поэтому последняя строка создаст оболочку /usr/local/bin/promenade
.