История изменений
Исправление byko3y, (текущая версия) :
Обычно ты пихаешь исходник в код и описываешь extensions в setup.py и оттуда setuptools питона их собирает, там по сути прямой интерфейс к компилятору.
Setup.py выходит из употребления. Изначальная идея его заключалась в том, что твое окружение идеально совпадает с окружением разраба, ты просто запускаешь python3 setup.py build и python3 setup.py install — и всё.
Собственно, для PSO я не заморачивался и сделал по старинке. Но для чуть более сложного проекта уже не прокатывает, потому что
а. нужно поставить программы-зависимости;
b. нужно поставить пакеты-зависимости;
c. нужно адаптироваться под полученные зависимости (этот этап можно навелосипедить на setup.py);
d. теперь проект можно собрать и развернуть.
Если тебе нужно собрать цепочку пакетов (например, на базе numpy), то это на целый день. Для описания этапов, выходящих за пределы сборки одного единственного пакета, в том числе навелосипедили setup.cfg, и может быть сделали бы еще кучу конфигов, но в итоге это дело унифицировали в pyproject.toml — не прошло и 20 лет, чтобы понять, что «система сборки собирает софт», а не «питон собирает что может, потом возможно дергает систему сборки, которая собирает то, что питон не смог собрать сам». Я могу понять изначальную задумку плана «все библиотеки питона будут писаться на самом питоне, потому пакетировать мы будем только платформонезависимые питоновые сорцы» — но уже в конце 90-х стало ясно, что эта схема не работает, что на любой чих и пук в питоне нужно писать сишное расширение.
Еще раз прошу мне напомнить про гениальность Гвидо, как диктатора-архитектора.
Исходная версия byko3y, :
Обычно ты пихаешь исходник в код и описываешь extensions в setup.py и оттуда setuptools питона их собирает, там по сути прямой интерфейс к компилятору.
Setup.py выходит из употребления. Изначальная идея его заключалась в том, что твое окружение идеально совпадает с окружением разраба, ты просто запускаешь python3 setup.py build и python3 setup.py install — и всё.
Собственно, для PSO я не заморачивался и сделал по старинке. Но для чуть более сложного проекта уже не прокатывает, потому что
а. нужно поставить программы-зависимости;
b. нужно поставить пакеты-зависимости;
c. нужно адаптироваться под полученные зависимости (этот этап можно навелосипедить на setup.py);
d. теперь проект можно собрать и развернуть.
Если тебе нужно собрать цепочку пакетов (например, на базе numpy), то это на целый день. Для описания этапов, выходящих за пределы сборки одного единственного пакета, в том числе навелосипедили setup.cfg, и может быть сделали бы еще кучу конфигов, но в итоге это дело унифицировали в pyproject.toml — не прошло и 20 лет, чтобы понять, что «система сборки собирает софт», а не питон собирает что может, потому возможно дергает систему сборки, которая собирает то, что питон не смог собрать сам". Я могу понять изначальную задумку плана «все библиотеки питона будут писаться на самом питоне, потому пакетировать мы будем только платформонезависимые питоновые сорцы» — но уже в конце 90-х стало ясно, что эта схема не работает, что на любой чих и пук в питоне нужно писать сишное расширение.
Еще раз прошу мне напомнить про гениальность Гвидо, как диктатора-архитектора.