https://youtu.be/YErAfIWC0wk

хм. как я понял, его можно почти с любым virtualenv'ом сцепить. удобная штука, надо попробовать.

В принципе, да. Но я использую все дефолтное. Просто кладу файл .envrc типа layout python python3.7. Ну и переменные окружения туда засовываю если надо

Здесь вот рассказывают чем они отличаются

хм. а оно с oh-my-zsh как дружит, не в курсе?

А мне вот интересно есть ли env дружащий с fish

Ну легко и просто: через pip апгрэйдим и дальше фиксируем Тут возникает проблема с dev-пакетами. Чтобы сделать pip freeze тебе надо развернуть чистый venv, установить все из requirements.txt, руками установить новые зависимости и потом сделать pip freeze > requirements.txt

Тут возникает проблема с dev-пакетами. Чтобы сделать pip freeze тебе надо развернуть чистый venv, установить все из requirements.txt, руками установить новые зависимости и потом сделать Это надуманная проблема, если такое и происходит(лично я вообще редко тяну еще какие-то ненужные для логики сервиса пакеты). И это разовая операция. РАЗОВАЯ!

дальше все за нас делает CI/CD. Если не делает, то стоит занться его настройкой , а не тратить время на хайп

у меня есть requirements-dev.txt, в котором первая строчка -r requirements.txt

Тут возникает проблема с dev-пакетами. Чтобы сделать pip freeze тебе надо развернуть чистый venv, установить все из requirements.txt, руками установить новые зависимости и потом сделать Это надуманная проблема, если такое и происходит(лично я вообще редко тяну еще какие-то ненужные для логики сервиса пакеты). И это разовая операция. РАЗОВАЯ!

Проблема с отсутствием тулов для нормального менеджмента всем этим барахлом.

Тут возникает проблема с dev-пакетами. Чтобы сделать pip freeze тебе надо развернуть чистый venv, установить все из requirements.txt, руками установить новые зависимости и потом сделать Это надуманная проблема, если такое и происходит(лично я вообще редко тяну еще какие-то ненужные для логики сервиса пакеты). И это разовая операция. РАЗОВАЯ!

что значит разовая? Зависимости в проекте имеют свойство меняться, добавляться, удаляться

а еще у меня есть requirements-travis.txt

Проблема с отсутствием тулов для нормального менеджмента всем этим барахлом.

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

что значит разовая? Зависимости в проекте имеют свойство меняться, добавляться, удаляться

ну так и меняется это ровно столько же раз в CI/CD, сколько меняется, добавляется, удаляется. Если это часто происходит, то вопрос к разработчику, чем он думал раньше и о чем

ну так и меняется это ровно столько же раз в CI/CD, сколько меняется, добавляется, удаляется. Если это часто происходит, то вопрос к разработчику, чем он думал раньше и о чем

А как CI/CD решает эту проблему? Ты имеешь в виду, что разработчик добавляет зависимости в requirements.in, CI/CD потом генерирует lock-файл (requirements.txt) и коммит его в репозиторий?

А как CI/CD решает эту проблему? Ты имеешь в виду, что разработчик добавляет зависимости в requirements.in, CI/CD потом генерирует lock-файл (requirements.txt) и коммит его в репозиторий?

я подразумеваю, что всю рутину по сборке и доставке надо описывать в CI/CD. То что мы обсуждаем о pipenv и есть эта рутина для CI/CD. Еси понадобится описать какую-то кастомизацию одного сервиса через разные зависимости и их версии(что является редким случаем несущим больше проблем, т.к. поддержка такого кода требует много усилий, а соответственно должна быть твердо обоснованной), то эта кастомизация заносится в CI/CD , т.к. он является основным интерфейсом программным и графичексим для сборки и доставки. пользуйтесь pip, venv, отдавайте предпочтение минималистичности и простоте, если отсутствует прямая потребность в усложнении

чет я не уловил

чет я не уловил

да пох, пользуй pipenv

да пох, пользуй pipenv

чет мне он не нравится

я подразумеваю, что всю рутину по сборке и доставке надо описывать в CI/CD. То что мы обсуждаем о pipenv и есть эта рутина для CI/CD. Еси понадобится описать какую-то кастомизацию одного сервиса через разные зависимости и их версии(что является редким случаем несущим больше проблем, т.к. поддержка такого кода требует много усилий, а соответственно должна быть твердо обоснованной), то эта кастомизация заносится в CI/CD , т.к. он является основным интерфейсом программным и графичексим для сборки и доставки. пользуйтесь pip, venv, отдавайте предпочтение минималистичности и простоте, если отсутствует прямая потребность в усложнении

рутина по сборке и доставке и управление зависимостями это немного разные вещи

чет мне он не нравится

он мало кому нравится, кто плотно сталкивался с управлением зависимостями

я подразумеваю, что всю рутину по сборке и доставке надо описывать в CI/CD. То что мы обсуждаем о pipenv и есть эта рутина для CI/CD. Еси понадобится описать какую-то кастомизацию одного сервиса через разные зависимости и их версии(что является редким случаем несущим больше проблем, т.к. поддержка такого кода требует много усилий, а соответственно должна быть твердо обоснованной), то эта кастомизация заносится в CI/CD , т.к. он является основным интерфейсом программным и графичексим для сборки и доставки. пользуйтесь pip, venv, отдавайте предпочтение минималистичности и простоте, если отсутствует прямая потребность в усложнении

Ну ок, опиши сценарии управления зависимостями на основе pip'а и CI/CD

рутина по сборке и доставке и управление зависимостями это немного разные вещи

зависимости прямым образом относятся к сборке, ну же

вариант с venv + pep freeze мне чет больше понравился

он мало кому нравится, кто плотно сталкивался с управлением зависимостями

Да, к pipenv'у есть много вопросов, но все же это лучше чем pip freeze

зависимости прямым образом относятся к сборке, ну же

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

сборка как один из кейсов использования этого

мы пробовали вариант хуже - никакого pip, все ставится из своего репозитория yum. В него пакеты собирабются из pip в полуавтоматическом режиме

зависимости прямым образом относятся к сборке, ну же

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

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

так собираешь то ты что? собираешь окружение...

так собираешь то ты что? собираешь окружение...

ну ок. Давай все же вернемся к вопросу о том как надо управлять зависимостями с помощью pip и CI/CD

Батл ?

мы пробовали вариант хуже - никакого pip, все ставится из своего репозитория yum. В него пакеты собирабются из pip в полуавтоматическом режиме

В итоге отказались от этого?

ну ок. Давай все же вернемся к вопросу о том как надо управлять зависимостями с помощью pip и CI/CD

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

Батл ?

раунд епт

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

Lock file

В итоге отказались от этого?

в итоге при очередном рефакторинге забили. Как и на фриз, просто релизится docker-образ, каждый тестируем

в итоге при очередном рефакторинге забили. Как и на фриз, просто релизится docker-образ, каждый тестируем

совершенно верно, докер много чего исключает

Lock file

file lock

При появлении багов - фиксируем максимальную версию и ладно

file lock

Что?

file lock

ты вообще в курсе что такое фиксация зависимостей?

Кажется, нет

Что?

да я хз, что там выше был за аргумент - lock file. Просто отзеркалировал))) подчеркнув бессмысленность аргумента.

lock file просто частная реализация в pipenv , она вообще меня не интересует

да я хз, что там выше был за аргумент - lock file. Просто отзеркалировал))) подчеркнув бессмысленность аргумента.

Lockfile вполне себе разумный аргумент.

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

Я же писал выше какие есть проблемы с pip freeze. Чтобы, например, добавить зависимость тебе нужно развернуть чистый venv, поставить туда все что нужно, и потом сделать pip freeze иначе у тебя в requirements.txt попадут dev-зависимости.

Lockfile вполне себе разумный аргумент.

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

Я же писал выше какие есть проблемы с pip freeze. Чтобы, например, добавить зависимость тебе нужно развернуть чистый venv, поставить туда все что нужно, и потом сделать pip freeze иначе у тебя в requirements.txt попадут dev-зависимости.

ну так я и ответил на это

слишком надумання проблема

ну так я и ответил на это

ты ответил что нужен CI/CD. Ну так расскажи какой должен быть флоу

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

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

слишком надумання проблема

почему надуманная? Аргументируй

ты ответил что нужен CI/CD. Ну так расскажи какой должен быть флоу

это комплексная задача, под которую берутся аж прям отдельные специалисты... Оно не надо это обсуждать, там много чего можно гибко понастроить

lock file просто частная реализация в pipenv , она вообще меня не интересует

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

почему надуманная? Аргументируй

выше то прочти , я описал в ответе

это комплексная задача, под которую берутся аж прям отдельные специалисты... Оно не надо это обсуждать, там много чего можно гибко понастроить

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

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

отличный аргумент, спасибо, я прозрел

отличный аргумент, спасибо, я прозрел

?

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

вы о какой задаче вообще?

вы о какой задаче вообще?

Фиксирование зависимостей, вроде

вот чет я не уверен

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

Верно подметил. Подразумевал следующее: 1. CI/CD + pip, docker 2. CI/CD + pipenv, docker В случае отсутствия CI/CD не вижу вообще смысл рассуждать об управлении зависимостями. Говняжь прямо куда хочешь

Верно подметил. Подразумевал следующее: 1. CI/CD + pip, docker 2. CI/CD + pipenv, docker В случае отсутствия CI/CD не вижу вообще смысл рассуждать об управлении зависимостями. Говняжь прямо куда хочешь

Ну так изначально речь шла про pip vs pipenv. С п.2 мне понятно, теперь расскажи про то как должен быть реализован п.1

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

да нечего рассказывать, заходишь в цицд и включаешь воображение)

да нечего рассказывать, заходишь в цицд и включаешь воображение)

можно побольше конкретики?

lock-файл CI/CD формирует и пушит в репозиторий?

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

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

опять слошная вода и невозможность сформулировать мысли

забудь кароче, пользуйтесь pipenv

опять слошная вода и невозможность сформулировать мысли

это опыт, сын

почему люди не могут просто ответить на вопрос?

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

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

- сколько будет 2+2? - я пытаюсь донести, что нету такой важности и частоты таких операций, чтобы считать 2+2 , учитывай наличие специализированных инструментов в среднестатистической компании

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

я тебе вопрос задавал об этом https://t.me/ru_python/874534

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

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

просто ответь, кто вызывает pip freeze - человек или CI?

- сколько будет 2+2? - я пытаюсь донести, что нету такой важности и частоты таких операций, чтобы считать 2+2 , учитывай наличие специализированных инструментов в среднестатистической компании

в батле побеждает pipenv

я тебе вопрос задавал об этом https://t.me/ru_python/874534

Есть проект, у него есть зависимости. Эти зависимости меняются/добавляются/удаляются. Нужно: 1. Уметь фиксировать все зависимости (lock-файл) 2. Разработчику должно быть удобно c этим работать

Есть проект, у него есть зависимости. Эти зависимости меняются/добавляются/удаляются. Нужно: 1. Уметь фиксировать все зависимости (lock-файл) 2. Разработчику должно быть удобно c этим работать

у меня есть и было куча проектов. В них редко менялись, добавлялись, удалялись зависимости(видимо плохо проектировал изначально). Я фиксировал зависимости через pip. Мне и моим коллегам это удобно

у меня есть и было куча проектов. В них редко менялись, добавлялись, удалялись зависимости(видимо плохо проектировал изначально). Я фиксировал зависимости через pip. Мне и моим коллегам это удобно

видимо плохо проектировал изначально или ничего не делал

просто ответь, кто вызывает pip freeze - человек или CI?

в CI/CD описывается этот вызов, или разные вариации вызовов, потом тыкается кнопка по описанному Task

ой

видимо плохо проектировал изначально или ничего не делал

совершенно верно, побеждает pipenv

кнопка

в CI

лол

в итоге все равно вызывает разработчик

и этот человек нам рассказывает про автоматизацию

кнопка

ну хочешь, обращайся по апи, если граф интерфейс не нужен

пускай и по кнопке

а если запускает человек - он может это сделать вне CI

и этот человек нам рассказывает про автоматизацию

блат, ну по событиям, по расписанию)))