Я использую Perl, работающий в пространстве пользователя (не установлен через root) и устанавливающий модули через командную строку cpan
. Я хотел бы знать, есть ли простой способ удалить модуль, не выполняя много работы, удаляя отдельные файлы.
Я искал этот вопрос в Интернете и нашел ответы на некоторые вопросы, но ответы, которые я нашел, либо обсуждают использование диспетчера пакетов Perl (для Microsoft Windows), в противном случае специфичные для операционной системы (BSDpan), предлагающие использовать cpanplus (с которым у меня было несколько неприятных переживаний), или закончился, указав на мертвую ссылку следующим образом: http://www.cpan.org/misc/cpan-faq.html#How_delete_Perl_modules
.
Мой вопрос конкретно в том, есть ли чистый способ удалить модуль, установленный через cpan
.
Вы не можете. В моем клиенте CPAN нет возможности выполнять такую функцию. Мы говорили о том, как мы могли бы сделать что-то подобное в этот уик-энд Perl QA Workshop, но в целом это сложно для всех причин, о которых говорил Эфир.
setuptools
. Это было решено в pip
с использованием (или генерацией после установки) пакета метаданных, который включает в себя список файлов.
Как правило, не существует специального механизма "удаления", который поставляется с модулями CPAN. Но вы можете попробовать make uninstall
в исходном каталоге, в который распакован модуль (это часто бывает под /root/.cpan
или ~/.cpan
), так как некоторые пакеты содержат эту директиву в своей установке script. (Тем не менее, поскольку вы установили модули в локальный (некорневой) каталог библиотеки, у вас также есть возможность уничтожить весь этот каталог и переустановить все остальное, что вы хотите сохранить.)
В большинстве случаев вы можете просто уйти с удалением файла A/B.pm
(для модуля A::B
) из вашего perllib - который, по крайней мере, сделает модуль непригодным. Большинство модулей также содержат список файлов для установки (называемый "манифест" ), поэтому, если вы можете найти это, вы узнаете, какие файлы вы можете удалить.
Однако ни один из этих подходов не будет адресовать любые модули, которые были установлены как зависимости. Там нет хорошего (автоматизированного) способа узнать, зависит ли что-то от этого модуля, поэтому вам придется удалить его вручную, как только вы убедитесь.
Трудность удаления модулей - одна из причин, почему многие разработчики Perl стремятся использовать систему контроля версий для отслеживания установок - например, см. статью статьи brian d foy в качестве дополнения к его предстоящей книге, в которой обсуждается использование git для управления пакетами.
App::cpanminus
из CPAN (для этого используйте cpan App::cpanminus
).cpanm --uninstall Module::Name
(обратите внимание на "m
" ), чтобы удалить модуль с помощью cpanminus.Это должно работать.
App::cpanminus
с помощью cpan App::cpanminus
не устанавливает никакого инструмента cpanm
, если я cpanm --uninstall Module::Name
я получаю -bash: cpanm: command not found
в OS X. Я что-то упустил
$PATH
.
В CPAN есть скрипты, пытающиеся удалить модули:
ExtUtils::Packlist показывает код удаления модуля модуля modrm
.
Обновление 2013: этот код устареет. Upvote bsb поздний ответ.
Мне не нужно часто удалять модули, но метод .packlist
на основе файлов никогда не подводил меня до сих пор.
use 5.010;
use ExtUtils::Installed qw();
use ExtUtils::Packlist qw();
die "Usage: $0 Module::Name Module::Name\n" unless @ARGV;
for my $mod (@ARGV) {
my $inst = ExtUtils::Installed->new;
foreach my $item (sort($inst->files($mod))) {
say "removing $item";
unlink $item or warn "could not remove $item: $!\n";
}
my $packfile = $inst->packlist($mod)->packlist_file;
print "removing $packfile\n";
unlink $packfile or warn "could not remove $packfile: $!\n";
}
Так как во время установки какого-либо модуля он в основном помещает соответствующие файлы .pm в соответствующие каталоги.
Поэтому, если вы хотите удалить модуль только для какой-либо цели тестирования или на самом деле лучше всего найти путь, где модуль хранится с помощью perldoc -l <MODULE>
, а затем просто переместите модуль оттуда в другое место.
Этот подход также можно рассматривать как более постоянное решение, но я не знаю о каких-либо негативных последствиях, поскольку я делаю это в основном для тестирования.