когда делаю pip install -r requirements.txt всё ок, но вот с модулем из git беда =(

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

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

я там public repo сделал. вообще, надо бы его выложить в общий pip

в общем, попробуй git@ добавить, как я выше написал. Может сразу заработает

username недостаёт тебе

Если репозиторий private, то надо по ssh с него тянуть (git@).

У меня, например, проекты из разных git-репозиториев, они все приватные, приходится настраивать config для ssh, чтобы можно было работать с несколькими ключами. Не очень удобно, но другого способа я не знаю

вот так ещё попробуй git+git://gitlab.i.somedomain.com

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

кстати, почему ты версии пакетов не указываешь явно?

кстати, почему ты версии пакетов не указываешь явно?

Ой, я помню эту тему. Ой, что сейчас будет...

я тут почитал, а разве requirements поддерживает git+git протокол?

https://pip.readthedocs.io/en/1.1/requirements.html#requirements-file-format -e надо указывать

https://pip.readthedocs.io/en/1.1/requirements.html#requirements-file-format -e надо указывать

странная ссылка. Вот: https://pip.pypa.io/en/stable/reference/pip_install/#git

да, он умеет git+git

Что странного? Там написано, что нужно "-e" указывать перед

Ой, я помню эту тему. Ой, что сейчас будет...

что будет? о_0 Разве оно при очередном деплое не должно нечаянно стянуть мажорный апдейт какого-либо пакета и упасть из-за несовместимости кода?

что будет? о_0 Разве оно при очередном деплое не должно нечаянно стянуть мажорный апдейт какого-либо пакета и упасть из-за несовместимости кода?

срачик будет:)

но да, так оно и делает

Что странного? Там написано, что нужно "-e" указывать перед

странно что ты линканул документацию к pip 1.1, когда он 9+

поэтому я вот и перешел на двойной requirements и очень жду pipfile стабильный

поэтому я вот и перешел на двойной requirements и очень жду pipfile стабильный

что такое двойной requirements?

странно что ты линканул документацию к pip 1.1, когда он 9+

Что в гугле нашлось :)

что такое двойной requirements?

я же показывал. пишу ручками requirements.in

Формат requirements файлов не менялся, поэтому что 9, что 1, без разницы.

я же показывал. пишу ручками requirements.in

на своей тачке в девелоп ветке живу так, обновляю по возжможности потом pip freeze -r requirements.in > requirements.txt и в тестах, на CI и на проде живу с фриженым requirements.txt

Формат requirements файлов не менялся, поэтому что 9, что 1, без разницы.

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

Вот на счёт версий кстати недавно напоролся. Ставим сначала PyQt 5.7.1, он с багами, откатываемся на PyQt 5.7.0 и он не работает. Не работает, потому что вместе с ним не откатывается SIP, который 4.19 для 5.7.1, и 4.18 для 5.7.0 Это баг дистрибьютинга или родовая травма всей этой pip-идеи?

Вот на счёт версий кстати недавно напоролся. Ставим сначала PyQt 5.7.1, он с багами, откатываемся на PyQt 5.7.0 и он не работает. Не работает, потому что вместе с ним не откатывается SIP, который 4.19 для 5.7.1, и 4.18 для 5.7.0 Это баг дистрибьютинга или родовая травма всей этой pip-идеи?

а как откатывался? pip install --upgrade --force ?

pip install -U —force-reinstall

вообще, при откатах лучше вайпать venv, конечно

угу, ты откатился как-то криво, видимо )

на своей тачке в девелоп ветке живу так, обновляю по возжможности потом pip freeze -r requirements.in > requirements.txt и в тестах, на CI и на проде живу с фриженым requirements.txt

хм, а профит в чём?

Ну можно попробовать повторить в чистом venv

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

Вот я и спрашиваю, это проблема конкретного пакета (кривой setup), либо это вообще проблема общая при даунгрейде?

хм, а профит в чём?

r...in нужен чтобы хранить твои услови на пакеты, что ты в голове считаешь зависимостями, а r...txt - это фриз, чтобы вот ничего поновее не сломало тебе ничего

локально я увижу обновление либы, когда установлюсь из r...in и проверю, что ничего не поломалось, тогда соберу новый r...txt

теоретически, если с тестами всё хорошо, это можно автоматизировать на CI, но лучше это делать в отдельном pipeline

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

это ж не очень как-то

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

не постоянно, а когда я захочу

мне же никто не мешает спокойно жить с r...txt

так когда ты захочешь ты можешь и .txt начать менять

нет, его нельзя просто так менять, оно делается freez-ом и тестируется

это некая осмысленная операция

но к ней легко придти через r...in

у меня чаще просто development.txt и production.txt внутри pip_requirements/

подозреваю что почти тоже самое

а какая в них разница?

ключевая штука здесь pip freeze -r r...in

это очень очень полезная команда

у меня чаще просто development.txt и production.txt внутри pip_requirements/

а это вот неудобно, когда у тебя docker и python onbuild. да и вообще. requirements.txt есть - сразу понятно, берем его и не паримся, пока не сломается. а в твоем случае не очень понятно что брать, чтобы на сервере демку поднять без тебя

./build.sh && ./up.sh :) в случае чего - README.md

крч, это я олень и забыл libffi-dev в зависимости добавить ))

крч, это я олень и забыл libffi-dev в зависимости добавить ))

а причём здесь оно? о_0

а причём здесь оно? о_0

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

аа. Так блин, я думал тебе пип говорит что урл не найден

надо было у тебя вывод потребовать :)

./build.sh && ./up.sh :) в случае чего - README.md

ну т.е. свои велосипедики вместо существующих инструментов. ну тоже путь, да;)

не не

ап-то компоуз поднимет =)

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

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

потому что докер-образ надо собрать )

так ./build.sh и всё

девопсу вообще нужен минимум геморроя с апп-историей

так ./build.sh и всё

а что там внутри будет?

вот там и будет сборка докер-образа

ERROR: S client not available

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

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

вот там и будет сборка докер-образа

фу бля

https://rutube.ru/video/419a16ec7734e9a211b0d82dd0e274ee/

идея в единых точках входа, не завязанных на проект

чтобы было понятно куда идти всегда

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

ну, типа да

docker-compose.yml Dockerfile requirements.txt

я вот знаю зачем эти штуки, а какой смысл ты вкладывал в файлики в папке pip_requirements, мне не очень ведомо

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

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

Ясно.

на пред. проекте юзался shippable.com для тестов и каждый раз много времени занимала установка requirements

на пред. проекте юзался shippable.com для тестов и каждый раз много времени занимала установка requirements

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

я вот знаю зачем эти штуки, а какой смысл ты вкладывал в файлики в папке pip_requirements, мне не очень ведомо

я подумал, наверное, ты прав. Надо меньше враппить в шелл и рассчитывать на нормальных девопсов.

Привычки с определённого проекта остались

если мы про докер, то там же кэш для этого, не?

а, ну да https://medium.com/playmoweb-android-ios-development/speed-up-your-builds-with-docker-cache-bfed14c051bf#.3i1t5q553

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

я тоже не очень понимаю как этот кэш работает

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

ну, докеровский. поэтому и надо все весии явно в requirements.txt писать

я тоже не очень понимаю как этот кэш работает

построчно. если строка не изменилась, кэш не инвалидирован. для COPY и ADD проверяется источник

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

т.е. вот RUN pip install requirements.txt не инвалидирует кэш, если requirements.txt изменился

поэтому надо делать перед жтим явно COPY requirements.txt, потом pip install, потом COPY весь проект

ну т.е. свои велосипедики вместо существующих инструментов. ну тоже путь, да;)

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

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

pip freeze же

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

где? результат я отдаю requirements.txt, а как я его подготовил - это уже мои проблемы

ну и опять же, я использую возможности pip freeze

где? результат я отдаю requirements.txt, а как я его подготовил - это уже мои проблемы

вот метод подготовки и есть велосипед

вот метод подготовки и есть велосипед

чего это? стандартная возможность pip freeze

более того, утвержденная в Pipfile как основной форкфлоу