и интеграционное тестирование

это только пока у тебя одна деплойная сущность. если у тебя в один контейнер ставятся два разных пакета, то у них могут быть разные requirements, которые могут конфликтовать

вспомним про requirements.in. это и правда прямая альтернатива setup.py на мой взгляд

это только пока у тебя одна деплойная сущность. если у тебя в один контейнер ставятся два разных пакета, то у них могут быть разные requirements, которые могут конфликтовать

нет же

интеграция после установки двух пакетов

значит у тебя есть репа для этого Dockerfile и там есть requirements.txt

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

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

ты не специально не читаешь что я пишу?:)

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

также мы согласислись, что надо закреплять версии при конечной интеграции

я утверждаю, что автоматически закреплять версии всего в setup.py неудобно, для этого лучше подходит requirements.txt

при этом такое решение никак не зависит от наличия у тебя какой-либо специальной инфраструктуры и воспроизводимо хоть на локальной машине, хоть в докере, хоть прямо в проде

вспомним про requirements.in. это и правда прямая альтернатива setup.py на мой взгляд

пакеты устанавливаемые по зависимостям должны иметь setup.py

сколько у тебя будет requirements.txt, если ты устанавливаешь на одну машину десять твоих пакетов?

сколько у тебя будет requirements.txt, если ты устанавливаешь на одну машину десять твоих пакетов?

один, только не на машину

а в venv или в докер

один venv - одна сборка - один процесс

я правильно понимаю, что у девяти из этих десяти пакетов дожен быть setup.py?

или у всех 10 тогда уж

зависит от того в какой репе у тебя интеграция происходит: в отдельной или в некой репе приложения

репы вообще не важны. это просто хранилища кода

репы вообще не важны. это просто хранилища кода

это единица интеграции

нет

можно в папочки пихать, но это не верно

потому что каждая репа имеет схему версионирования и ветки по версиям и т.п.

и каждая точка интеграции должна отдельно версионироваться

ты в курсе, что для версионирования не только git tag существует? можно версионироваться без привязки к vcs

ты в курсе, что для версионирования не только git tag существует? можно версионироваться без привязки к vcs

это неудобно

это пока у тебя нет десятков пакетов

это пока у тебя нет десятков пакетов

тем более, когда у тебя 10 пакетов

дебианщики вон специально инфраструктуру сборки пакетов из гитовых реп завели

каждая репа - src пакет

странно не пользовать Version Control System, когда она есть

дебианщики вон специально инфраструктуру сборки пакетов из гитовых реп завели

причем у них там нет самого кода, совсем

а дальше у тебя вся инфра умеет git и его ветки/теги и делать пайплайны по ним

http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html

http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html

ну и что там? 8000 репов, потому что не было политики управления ими?

давайте лучше посмотрим вот сюда https://plus.google.com/u/0/110308154931599002929/posts/4WLcSaQZHiW?sfc=true

какая же красота:)

Можно в setup.py парсить requirements.txt. И все будут довольны :)

Можно в setup.py парсить requirements.txt. И все будут довольны :)

так делают только мудаки, как говорил Тёма

так делают только мудаки, как говорил Тёма

Да не, это путь, но только это не нужно, потому что как раз путает причину со следствием

"requirements.txt - это костыль со времен, когда не было setuptools, а был коробочный distutil, который как раз не умеет в зависимости. В прочем, он так до сих пор в них и не научился. Setuptools эту проблему порешали и requirements с ним не нужен, кроме разве что специфичных ситуаций." какой-то бред полный в плане истории

ну и что там? 8000 репов, потому что не было политики управления ими?

там много про то, что куча микросервисов в куче реп у кучи команд это боль

там много про то, что куча микросервисов в куче реп у кучи команд это боль

Ну, так это недостаток слоя абстракции. И да, когда у тебя много кода, у тебя много кода:)

какой абстракции? отзумимся подальше, у нас крутая компания на миллиард?

какой абстракции? отзумимся подальше, у нас крутая компания на миллиард?

Да какая разница. В рамках одного сервиса всё ок. Отзумься до всего опенсорс. Вот тебе модель организации

а кстати, как ты деплоишься, когда у тебя есть два микросервиса, и ты хочешь поменять протокол общения между ними?

а кстати, как ты деплоишься, когда у тебя есть два микросервиса, и ты хочешь поменять протокол общения между ними?

Аккуратно:)

с даунтаймом?

У меня есть красивые rolling updates 7 шаговые миграции базки и поддержка совместимости разных версий протокола разными способами

Как раз вчера закончили тестирование полного Zero Downtime Deployment

а совместимость со старыми версиями, которых больше нет потом отпиливаешь?

а совместимость со старыми версиями, которых больше нет потом отпиливаешь?

Ну там по-разному. От способа совместимости зависит

Чаще всего да, есть просто previous version support, который вываливается, когда появляется next

Хуже, когда больше двух-трех версий приложения в поддержке/разработке одновременно

Всё всегда по обстоятельствам и необходимости же. Универсального способа нет.

Overengineering - это зло, которое надо пресекать в зародыше

celery из файлов читает в setup https://github.com/celery/celery/blob/master/setup.py

видно что автор не умеет в сетаптулз еще и в маркеры не умеет, судя по jython.txt

open( os.path.join(os.getcwd(), 'requirements', *f) зачем там os.getcwd? зачем там вообще самопальный и кривой парсер req.txt файлов?

sys.exit(_pytest.main(self.pytest_args)) - а такое я вообще люто ненавижу, потому что это ломает пайплайн напрочь

Где взять нормальный пример setup.py. В sentry, например, тесты вынесены в extras_require https://github.com/getsentry/sentry/blob/master/setup.py Нормальная это практика или нет?

увы, насколько я помню, tests_require запилили достаточно поздно и приличное количество пакетов начало использовать экстры для задания зависимостей для тестов, но при этом единого стандарта нет - test, tests, testing

"нормальный пример", гм. львиная доля zope использовала единый подход с довольно хорошим паттерном

open( os.path.join(os.getcwd(), 'requirements', *f) зачем там os.getcwd? зачем там вообще самопальный и кривой парсер req.txt файлов?

Потому что так исторически сложилось

ERROR: S client not available

Где взять нормальный пример setup.py. В sentry, например, тесты вынесены в extras_require https://github.com/getsentry/sentry/blob/master/setup.py Нормальная это практика или нет?

Где взять нормальную доку для начала

дока к сетаптулзам давным-давно на изи пике была, а теперь и на всяких ридзедоксах

"нормальный пример", гм. львиная доля zope использовала единый подход с довольно хорошим паттерном

Они же вроде забили и с plone вместе пошли мимо pypi, кажется

дока к сетаптулзам давным-давно на изи пике была, а теперь и на всяких ридзедоксах

Ты читал её

Там по коду легче в 1000 раз понять что для чего и как работает

Они же вроде забили и с plone вместе пошли мимо pypi, кажется

щито? они наоборот выложили тонны своего кода, от чего быстро перегрузили его 8)

Ну и они выпили генератор setup.py. А генератор req есть:)

я читал её. и читал исходники и дистутилсов и сетаптулзов и пкг_ресурсов. вот нифига, докой там как раз проще

щито? они наоборот выложили тонны своего кода, от чего быстро перегрузили его 8)

Ну ок, они просто странные во всем. Значит plone только

что плон?

Мимо pypi несет куски, плагины

у плон свои зеркала индексов вроде

я её слишком недолго колупал, чтобы точнее сказать

Вот эти, которые на PiterPy были

генератор сетапа... ммм. тот же пастер содержал готовые шаблоны

минимальный сетап в целом состоит на 90% из метадаты которую девелопер вручную заполнять должен - название, версия, автор, описание, кейворды, классификатор

оставшееся - packages=find_packages(), да еще чуток инфы сверху

Ну, вот в distribute было генератор на readline

По вопросам. Это вообще нормальная практика

Документация setuptools на самом деле говно

Собственно distutils тоже

доку по дистутилс в стандартной доке уже почти выпилили 8\

поставили заглушку, которая ссылается на убогий пакаджинг гайд

Вообще смотреть на всю эту боль с distutils, distutils2, distribute, setuptools, distribute + setuptools, wheels.... они когда-нибцдь родят?

д2 был мертворождённым. дистрибут уже анфоркнули

колёса - новые яйца, только сделанные через задницу

д2 был мертворождённым. дистрибут уже анфоркнули

В этом и суть. Все видят и понимают, что всё плохо, но хорошо сделать пока не очень получается

О, прикольно, что можно в сишном расширении плодить треды и скидывать cpu bound туда

а где хорошо?

нодовый нпм то еще говно

цпан?

В java? :)) вообще нигде не хорошо. Все эти devops не от хорошей жизни появляются