ну так копипасти джангу из тарболла. нахуй нужен пип вообще

еще один мат и я тебя выпилю

да ну нафиг... я сам лучше выпилюсь. какую-то ерунду вечно городите 8\

а pip нужен чтобы удобно брать тарбол

точно так же, как yum нужен чтобы удобно брать системные пакеты

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

ну вот зачем, объясни мне.

чтобы вынести питоновый код из билда вообще напрочь

при том, что еще придется следить на ревью, чтобы туда никто какого-нибудь кода своего не вписал

чтобы вынести питоновый код из билда вообще напрочь

что такое "питоновый код в билде"?

у меня вся автоматизация на ansible

а это вообще ортогонально...

и сборка и provisioning целевой системы и деплой

ничего не запускается, если ansible не попросил это запустить

весь код воспринимается как статичная субстнация

это правильно, да

ну вот и в этом контексте setup.py не впился вообще

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

более того, ansible запускается только из контейнера, а файлики .in, которые я показал, это чтобы сделать .txt для этого контейнера

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

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

ват

на .in смотрят девелоперы, на .txt — автоматика

более того, ansible запускается только из контейнера, а файлики .in, которые я показал, это чтобы сделать .txt для этого контейнера

и в этот контейнер еще ставится npm и bower закрепленных версий и всякие хедеры в систему. и вся автоматизация работает только из него:)

всё. не хочу больше вникать. 8\

:) А — абстракции

а что делает ansible, если все в контейнерах уже настроено в Dockerfile?

и я всё еще не понял зачем мне setup.py :)

я всё еще не понял структуру твоего кода

и причем тут вообще ансибл

а что делает ansible, если все в контейнерах уже настроено в Dockerfile?

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

я всё еще не понял структуру твоего кода

она не важна для деплоя

да нет, я именно эту часть твоей инфраструктуры понять не могу

всё делается по одному шаблону, не важно какого рода проект: build. ship. run.

докеры/ансиблы - это всё хорошо, но уровень выше

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

если бы использовался EB, то работы для ansible было бы меньше, да?

1. сборка проекта, в резултате артефакт 2. доставка артефакта на систему. 3. подготовка системы для запуска артефакта. 4. запуск/рестарт всего говна

шаг 4 бывает в виде rolling update

если бы использовался EB, то работы для ansible было бы меньше, да?

если бы была, ну да

но у меня не только aws

я все время забываю )

У меня сложилось впечатление что Zart часто говорит про важность setup.py, но я не понимаю зачем мне это в работе

вот я всё ещё не услышал зачем оно мне

или мы чего то не слышим или zart))

чтобы скопировать в него requirements.txt в другом формате и огрести еще одно место, куда джуниор может запихнуть какой-нибудь код?

а sudo pip install делать любители есть?

R

чтобы скопировать в него requirements.txt в другом формате и огрести еще одно место, куда джуниор может запихнуть какой-нибудь код?

т.е. ты не понимаешь что пререки в setup.py и requirements.txt имеют разные роли?

был им пока не разъебал пип.

т.е. ты не понимаешь что пререки в setup.py и requirements.txt имеют разные роли?

разверни мысль.

а sudo pip install делать любители есть?

ну, в Dockerfile так можно;) даже иногда нужно:)

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

ну, в Dockerfile так можно;) даже иногда нужно:)

понятно, что на системе, которую ты не пересобираешь каждый раз, так делать нельзя

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

и если оно у меян написано в requirements .txt и ставится в личный venv процесса, зачем мне тогда писать это setup.py?

но к примеру то же джангоприложение можно гонять сотней способов - например через гуникорн, черрипай, ювсги какой из них выбрать - решает сисадмин, а не разработчик, поэтому в сетапе зависимость на такие пакаджи не ставят а для конкретного деплоя скажем нужен, и тогда это идёт в рек.тхт

но к примеру то же джангоприложение можно гонять сотней способов - например через гуникорн, черрипай, ювсги какой из них выбрать - решает сисадмин, а не разработчик, поэтому в сетапе зависимость на такие пакаджи не ставят а для конкретного деплоя скажем нужен, и тогда это идёт в рек.тхт

а вот это херня

и если оно у меян написано в requirements .txt и ставится в личный venv процесса, зачем мне тогда писать это setup.py?

вот это вот херня

ты можешь сделать requirements-prod.txt , например

а если я деплою не пипом? 8)

но использовать паралелльно setup.py и requirements.txt - плохая практика, ведущая к путанице

нет, непонимание роли requirements.txt - это плохая практика

а если я деплою не пипом? 8)

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

вот положим ты выложил свои репо со своими исходниками я хочу себе их задеплоить ну и я ставлю например себе твой код: pip install git+... ImportError? втф?

по умолчанию requirements.txt и setup.py несут копии зависимостей. даже часто в setup.py читают из requirements.txt

это устоявшаяся практика

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

по умолчанию requirements.txt и setup.py несут копии зависимостей. даже часто в setup.py читают из requirements.txt

это полная херня

расширять с помощью дефолтного requirements.txt инфу из setup.py - плохая практика, повторюсь, ведущая к путанице

те кто такое делают - тупо как обезьяны фигачили pip freeze, не вникая в то, что творят

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

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

ERROR: S client not available

давай ты не будешь сейчас рассказывать за весь мир?

https://packaging.python.org/requirements/#requirements-files

https://caremad.io/posts/2013/07/setup-vs-requirement/ тот же дональд пытается ту же мысль донести

он правда под другим углом это подаёт

https://packaging.python.org/requirements/#requirements-files

я не вижу тут твоей мысли. я вижу только то, что в setup.py идет мой .in это понятно

https://caremad.io/posts/2013/07/setup-vs-requirement/ тот же дональд пытается ту же мысль донести

Python Libraries - setup.py Python Applications - requirements.txt это вот ровно моя мысль

угу. правда с терминологией всё ужасно

тебе не нужен setup.py, когда у тебя есть полный requirements.txt

вот именно то, о чем я говорю

у меня есть мечта - чтобы ИДЕ наконец-то начали делить проекты на проекты с кодом (либы, приложения) и на проекты под конкретный деплой (набор либ/приложений)

нет, тебе надо -e в рек со ссылкой на пакадж 8)

при этом, если тебе так удобно, ты можешь добавить requirements-prod.txt для твего деплоя и делать pip install -r requirements.txt -r requiremets-prod.txt

это уже хозяин - баррин

в моем понимании репа с питоновым кодом не должна иметь requirements.txt вообще

в моем понимании репа с питоновым кодом не должна иметь requirements.txt вообще

ага, а репа с js кодом не должна иметь manifest-а

в моем понимании репа с питоновым кодом не должна иметь requirements.txt вообще

если это репа распространяемая на github и имеющая широкий лист совместимости - да

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

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

ты там выше про артефакты упоминал - в случае с питоном это вполне относится к колёсам и прочим бдистам

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

вот если у тебя есть свой pypi, и ты собираешь приложение из нескольких пакетов, сделанных другими командами и все такое тогда, у тебя появляется интеграционный репозиторий с requirements.txt

именно

"свой pypi" = тупо каталог с колёсами

но в реальной жизни, на этот слой абстракции часто удобно забить

потому что оно лишнее

"свой pypi" = тупо каталог с колёсами

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

а как ты туда релизить будешь?

можно конечно scp поиспользовать

ну ок

но все равно у тебя должен быть артефакторий

причем желательно совместимый не только с питоном

и тут мы приходим к докеру, микросервисам и requirements.txt

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

дома мне хватает либо локального каталога, либо сетевой шары. а если под вебсервером лежит, то и глобально не вопрос