SZ
Используем этот контейнер в качестве базового
🙈👍
Size: a a a
2021 March 18
И
Нужно начать с того что убедиться что тебе реально нужен приватный cpan. Если у тебя один perl проект, то выносить все в отдельные библиотеки — это просто трата времени. Если у тебя есть несколько разных проектов которые должны исползовать один и тот же код — то приватный cpan — это не единственный способ шарить одинаковый код между проектами. Можно тупо забирать из VCS, можно использовать что-то вроде git submodules, можно упаковывать в системные пакеты. У всех решенией есть и плюсы и минусы.
У меня есть несколько модулей которые много где переиспользуются. Думаю как в случае обновлений нормально их доставлять. Сейчас это не сделано никак, просто руками что-то копируется, а что-то увы забывается и получается в разных проектах разные версии одного и того-же модуля. В общем не очень...
Плюс когда новый проект начинаешь хотелось бы делать что-то вроде cpan install ... в том числе и для своих модулей.
Плюс когда новый проект начинаешь хотелось бы делать что-то вроде cpan install ... в том числе и для своих модулей.
И
Приватный cpan - первое, что в голову пришло.
b
Игорь
Приватный cpan - первое, что в голову пришло.
приватный cpan норм, тебе ещё картон для управления зависимостями, и будет ок )
b
ну или вариант с докером - таскать с собой всю помойку (место дешёвое, перл модули копейки занимают)
YK
для carton или cpm в cpanfile можно просто url-ы https://metacpan.org/pod/Carton#Specifying-a-CPAN-distribution
SZ
Игорь
У меня есть несколько модулей которые много где переиспользуются. Думаю как в случае обновлений нормально их доставлять. Сейчас это не сделано никак, просто руками что-то копируется, а что-то увы забывается и получается в разных проектах разные версии одного и того-же модуля. В общем не очень...
Плюс когда новый проект начинаешь хотелось бы делать что-то вроде cpan install ... в том числе и для своих модулей.
Плюс когда новый проект начинаешь хотелось бы делать что-то вроде cpan install ... в том числе и для своих модулей.
Держи всё в гите
SZ
Будешь потом просто через cpanfile и cpm обновлять
SZ
cpm умеет прям по git url выкачивать
DF
Ага, только с версионированием так себе у такой системы
IB
Ага, только с версионированием так себе у такой системы
Почему?
IB
requires 'Plack', git => 'git://github.com/plack/Plack.git', rev => '0.9970';МИ
requires 'Plack', git => 'git://github.com/plack/Plack.git', rev => '0.9970';Это не версионирование. rev тут — не версия и сравниваться не будет.
МИ
К сожалению, при хранении зависимостей в Гите нельзя сделать рекурсивное разрешение зависимостей. Даже cpm не умеет так делать. Если, допустим, есть зависимости X->Y->Z, то в Y нельзя указать Z через Гит. Придётся указать Z прямо в X.
Я просил Миягаву это починить, но он сказал что не будет по идеологическим соображениям.
Я просил Миягаву это починить, но он сказал что не будет по идеологическим соображениям.
МИ
Если зависимости только одного уровня X->Y, тогда можно обойтись одним Гитом и не поднимать локальный спан.
АК
К сожалению, при хранении зависимостей в Гите нельзя сделать рекурсивное разрешение зависимостей. Даже cpm не умеет так делать. Если, допустим, есть зависимости X->Y->Z, то в Y нельзя указать Z через Гит. Придётся указать Z прямо в X.
Я просил Миягаву это починить, но он сказал что не будет по идеологическим соображениям.
Я просил Миягаву это починить, но он сказал что не будет по идеологическим соображениям.
Есть версия cpanm из ветки, которая умеет. MR года два висел, а Миягава потом сказал, что сделает это в cpanm v2 и закрыл. Воз и ныне там...
АК
А, не, не писал и не закрывал Миягава. Просто висит MR. Три дня назад ему исполнилось 5 лет.
АН
поддерживает ли перл grpc ?
SZ
поддерживает ли перл grpc ?
Сам перл -- нет