AM
Size: a a a
2020 May 28
RB
А с pep-582 что-то стало понятно? Это же который node-modules для питона?
💭П
https://github.com/frostming/pdm
Они на свет ползут!
Они на свет ползут!
Пакетный менеджер, в докере?
KK
https://github.com/frostming/pdm
Они на свет ползут!
Они на свет ползут!
Ситуация, которую мы заслужили. Ещё со времён setuptools не могли разгрести проблемы с пакетами. И гора этих проблем не уменьшается.
pip, судя по всему, тоже не смог стать достаточно хорошим, что бы подходил большинству для решения наиболее частых задач. Вот и пилят все свои "самые лучшие" пакетные менеджеры.
pip, судя по всему, тоже не смог стать достаточно хорошим, что бы подходил большинству для решения наиболее частых задач. Вот и пилят все свои "самые лучшие" пакетные менеджеры.
AM
Да. К сожалению за 10 лет bundler так и не смогли нормально скопировать. Единственное что я любил в руби.
KK
Про API в pdm не увидел в доках. Т.е. это очередной CLI-only инструмент, который будет проблемно юзать в сторонних проектах (например в том же zc.buildout)
KK
Видимо у него есть "фатальный недостаток". И он медленно развивается.
KK
А ещё он только для установки пакетов
KK
С помощью него нельзя разрабатывать и публиковать пакеты
RB
Чисто cli это разве плохо? Плохо что он дюже примитивный. Нет привычных цивилизованным людям лок файлов, не такого понятия как dev-dependency (я знаю про requirements.dev и constraints, но это убожество), и вроде как он не всегда может построить "бесконфликтный" граф зависимостей, но с этим я не сталкивался
SZ
А ещё он только для установки пакетов
а какой из пакетных менеджеров делает что-то иное?
RB
poetry )
KK
Чисто cli это разве плохо? Плохо что он дюже примитивный. Нет привычных цивилизованным людям лок файлов, не такого понятия как dev-dependency (я знаю про requirements.dev и constraints, но это убожество), и вроде как он не всегда может построить "бесконфликтный" граф зависимостей, но с этим я не сталкивался
Чистый cli сложно использовать в других проектах, которые хотят использовать такой инструмент как часть своего workflow. Потому что возня с subprocess-ами и парсингом выхлопа утилиты в stdout - это больно.
SZ
наверно надо как-то разделять управление пакетами и управление разработкой своего пакета.
я пытаюсь провести аналогию с каким-нибудь apt или pacman, они - пакетные менеджеры в чистом виде, и вроде не позволяют куда-то что-то заливать. либо это явно не особо публичный функционал.
с точки зрения понимания что такое пакетный менеджер в линуксе, pip - это как раз оно.
я пытаюсь провести аналогию с каким-нибудь apt или pacman, они - пакетные менеджеры в чистом виде, и вроде не позволяют куда-то что-то заливать. либо это явно не особо публичный функционал.
с точки зрения понимания что такое пакетный менеджер в линуксе, pip - это как раз оно.
KK
Аналогия не совсем подходящая. apt и товарищи работают только с одним "проектом" - твоя операционка. Они не могут поставить "зависимости" только под твой проектик, внутри его локальной папочки.
KK
А для языков программирования "глобальная" помойка пакетов - это скорее полезное исключение, нежели сильная необходимость.
ИК
наверно надо как-то разделять управление пакетами и управление разработкой своего пакета.
я пытаюсь провести аналогию с каким-нибудь apt или pacman, они - пакетные менеджеры в чистом виде, и вроде не позволяют куда-то что-то заливать. либо это явно не особо публичный функционал.
с точки зрения понимания что такое пакетный менеджер в линуксе, pip - это как раз оно.
я пытаюсь провести аналогию с каким-нибудь apt или pacman, они - пакетные менеджеры в чистом виде, и вроде не позволяют куда-то что-то заливать. либо это явно не особо публичный функционал.
с точки зрения понимания что такое пакетный менеджер в линуксе, pip - это как раз оно.
pacman поставляет с собой библиотеку, которую ты можешь использовать.
ИК
pip - не поставляет этого.