Как удалить модуль Perl, установленный через `cpan`? - PullRequest
Новая
       24

Как удалить модуль Perl, установленный через `cpan`?

61 голосов
/ 13 апреля 2010

Я использую Perl, работающий в пространстве пользователя (не устанавливается через root) и устанавливаю модули через командную строку cpan. Я хотел бы знать, существует ли простой способ удаления модуля без необходимости выполнять большую работу по удалению отдельных файлов.

Я искал этот вопрос в Интернете и нашел несколько ответов, но ответы, которые я нашел, похоже, либо обсуждают с помощью диспетчера пакетов Perl (для Microsoft Windows), либо для конкретной операционной системы (BSDpan), предлагая использовать cpanplus (с которым у меня было несколько неудачных опытов), или закончил указанием на неработающую ссылку следующим образом: http://www.cpan.org/misc/cpan-faq.html#How_delete_Perl_modules.

Мой вопрос, в частности, есть ли чистый способ удалить модуль, установленный через cpan.

Ответы [ 6 ]

44 голосов
/ 06 апреля 2015
  1. Установить App::cpanminus из CPAN (используйте: cpan App::cpanminus для этого).
  2. Введите cpanm --uninstall Module::Name (обратите внимание на "m"), чтобы удалить модуль с помощью cpanminus.

Это должно сработать.

38 голосов
/ 13 апреля 2010

Вы не можете. В моем клиенте CPAN нет функции, позволяющей сделать это. Мы говорили о том, как мы могли бы сделать что-то подобное на семинаре Perl QA Workshop в эти выходные, но, как правило, сложно по всем причинам, упомянутым Ether.

29 голосов
/ 13 апреля 2010

Как правило, в модуле CPAN нет специального механизма удаления. Но вы можете попробовать make uninstall в исходном каталоге, в который распакован модуль (это часто в /root/.cpan или ~/.cpan), так как некоторые пакеты содержат эту директиву в своем скрипте установки. (Однако, поскольку вы установили модули в локальный (не корневой) каталог библиотеки, у вас также есть возможность удалить весь этот каталог и переустановить все остальное, что вы хотите сохранить.)

Большую часть времени вы можете просто удалить файл A/B.pm (для модуля A::B) с вашего perllib - что по крайней мере сделает модуль непригодным для использования. Большинство модулей также содержат список файлов, которые нужно установить (так называемый «манифест»), поэтому, если вы сможете найти это, вы будете знать, какие файлы вы можете удалить.

Однако ни один из этих подходов не будет обращаться к модулям, которые были установлены как зависимости. Нет хорошего (автоматизированного) способа узнать, зависит ли что-то еще от этого модуля, поэтому вам придется удалить его вручную, как только вы будете уверены.

Сложность удаления модулей является одной из причин того, что многие разработчики Perl переходят на использование системы контроля версий для отслеживания установок - например, см. статью Брайана Д. Фоя в качестве дополнения к его новой книге , в которой обсуждается использование git для управления пакетами.

23 голосов
/ 25 июня 2012

В CPAN есть сценарии, которые пытаются удалить модули:

ExtUtils :: Packlist показывает пример кода удаления модуля, modrm.

17 голосов
/ 13 апреля 2010

Обновление 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";
}
2 голосов
/ 21 мая 2015

Поскольку на момент установки любого модуля он в основном помещал соответствующие файлы .pm в соответствующие каталоги. Поэтому, если вы хотите удалить модуль только для каких-то целей тестирования или временно, лучше всего найти путь, где хранится модуль, используя perldoc -l <MODULE>, а затем просто переместить модуль оттуда в другое место. Этот подход также может быть опробован как более постоянное решение, но я не знаю о каких-либо негативных последствиях, так как я делаю это в основном для тестирования.

...