Если этот кейс откинуть, то первый кейс решается install_requires, а второй pipenv'ом

Ну и зачем дублировать и поддерживать два списка зависимостей.

О каком дублировании идет речь? библиотека это отдельная кодовая база со своим репозиторием, которая distribute'ится через pypi. Приложение - это отдельный продукт сделаный с использованием библиотеки (библиотек)

а многие так делают

Посмотри sentry как пример

Посмотрел, install_requires генерируется на основе requirements.txt

и теперь Pipfile заменяет requirements.txt

Для приложений - да, для библиотек - нет, т.к. для них смысла в pipenv'е я не вижу

Все что нужно в Python экосистеме - это нормальный стандарт для описания метаданных проекта и утилиты (можно одну или несколько) для управления зависимостями \ сборки проекта из этих метаданных.

надо чтобы в описании зависимостей было отдельно known-good

Ну так это, по-идее, можно сделать с помощью extras_require в setup.py. И устанавливать будешь так pip install somelib[known-good]

а с конфликатми что делать?

lib1: - lib2: - lib3 = 1.x [1.0 good] - lib4: - lib3 = 1.x [ 1.1 good]

Пекабояре здесь?

Пекабояре здесь?

мак + плейстейшн

ага

Пока вы играете в игры, конкуренты учатся и метят на ваше место???

Пока вы играете в игры, конкуренты учатся и метят на ваше место???

вот смотри есть 3 распространенных use case: библиотека, приложение и продукт (сервис). для библиотеки тебе достаточно описать install_requires, собрать и запушить на PyPI для приложения (возьмем пример бложика на джанго) ты описываешь requirements.txt \ Pipfile, устанавливаешь пакеты, генерируешь lock, деплоишь на сервер и теперь продукт - конечное приложение, которое собирается в пакет. для деплоймента - удобно иметь lock file, reproducible builds и все такое. чтобы собрать пакет - нужны loose зависимости Теперь следите за руками. Все нормальные пакетные менеджеры (cargo \ npm) решают все 3 use case парой файлов - описанием метаданных для сборки и зависимостей и lock file. Но в Python с этим всю жизнь был бардак.

Все нормальные пакетные менеджеры (cargo \ npm) решают все, кстати, а разве js'еры используют yarn.lock не потому, что npm это не умеет?

Все нормальные пакетные менеджеры (cargo \ npm) решают все, кстати, а разве js'еры используют yarn.lock не потому, что npm это не умеет?

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

работать ради того, чтобы работать?

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

Подскажите как правильно реализовать обёртку Middleware на Django для получения текущего пользователя. Я пытаюсь чат с примера Channels накрутить на веб-сайт.

Она же уже есть из коробки.

Там юзера не могу достать текущего

request.user ?

Да, там нету реквеста

Тогда и middleware не поможет. Она оперирует реквестом и респонзом.

Потому что они пушают свой формат метаданных проекта. Который ни разу не решает обе задачи. Потому что с новой тулзой должен быть формат описания зависимостей и метаданных проекта. Потому что их просили сделать хотя бы удобный инструмент импорта зависимостей из Pipfile в setup.py - они положили хер на это.

Как же быть

Кстати такой инструмент есть же, вроде: from pipenv.project import Project from pipenv.utils import convert_deps_to_pip pfile = Project(chdir=False).parsed_pipfile requirements = convert_deps_to_pip(pfile['packages'], r=False) test_requirements = convert_deps_to_pip(pfile['dev-packages'], r=False)

Всем привет, устоев и правил чата не знаю, по этому такой вопрос. Я занимаюсь артом (графику и прочее рисую). И мне не помешали бы клиенты. Могу я здесь каким-то образом прорекламироваться, работы кинкуть?))

тебе лучше в какой нибудь gamedev чатик

А кто может такие порекомедовать?

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

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

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

А если рассматривать pipenv только как инструмент для reproducable environment, т.е. как замену pip freeze > requirements.txt у тебя есть к нему претензии?