如何在不丢失模块的情况下更新 Windows 上的 Perl？

How can I update Perl on Windows without losing modules?

提问by piCookie

At work I'm using Perl 5.8.0 on Windows.

在工作中，我在 Windows 上使用 Perl 5.8.0。

When I first put Perl on, I went to CPAN, downloaded all the sources, made a few changes (in the .MAK file(?) to support threads, or things like that), and did nmake/ nmake test/ nmake install. Then, bit by bit, I've downloaded individual modules from CPAN and done the nmake dance.

当我第一次把Perl的，我去CPAN，下载的所有来源，做了一些改变（在.MAK文件（？），以支持线程，或类似的东西），并做nmake/ nmake test/ nmake install。然后，一点一点地，我从 CPAN 下载了各个模块并完成了 nmake 舞蹈。

So, I'd like to upgrade to a more recent version, but the new one must not break any existing scripts. Notably, a bunch of "use" modules that I've installed must be installed in the new version.

所以，我想升级到更新的版本，但新版本不能破坏任何现有的脚本。值得注意的是，我安装的一堆“使用”模块必须安装在新版本中。

What's the most reliable (and easiest) way to update my current version, ensuring that everything I've done with the nmake dance will still be there after updating?

更新我当前版本的最可靠（也是最简单）的方法是什么，确保我在 nmake dance 上所做的一切在更新后仍然存在？

采纳答案by brian d foy

As others noted, start by installing the new perl in a separate place. I have several perls installed, each completely separate from all of the others.

正如其他人指出的那样，首先在单独的地方安装新的 perl。我安装了几个 perls，每个 perls 都与所有其他 perls 完全分开。

To do that, you'll have to configure and compile the sources yourself. When you run configure, you'll get a chance to specify the installer. I gave detailed instructions for this in an "Compiling My Own Perl" in the Spring 2008 issue of The Perl Review. There's also an Item in Effective Perl Programmingthat shows you how to do it.

为此，您必须自己配置和编译源代码。运行时configure，您将有机会指定安装程序。我在The Perl Review 2008 年春季刊的“编译我自己的 Perl”中对此给出了详细说明。在Effective Perl Programming中还有一个 Item向您展示了如何去做。

Now, go back to your original distribution and run cpan -ato create an autobundle file. This is a Pod document that lists all of the extra stuff you've installed, and CPAN.pm understands how to use that to reinstall everything.

现在，返回到您的原始发行版并运行cpan -a以创建一个自动捆绑文件。这是一个 Pod 文档，列出了您安装的所有额外内容，CPAN.pm 了解如何使用它来重新安装所有内容。

To install things in the new perl, use that perl's path to start CPAN.pm and install the autobundle file you created. CPAN.pm will get the right installation paths from that perl's configuration.

要在新的 perl 中安装东西，请使用该 perl 的路径启动 CPAN.pm 并安装您创建的 autobundle 文件。CPAN.pm 将从 perl 的配置中获得正确的安装路径。

Watch the output to make sure things go well. This process won't install the same versions of the modules, but the latest versions.

观察输出以确保一切顺利。此过程不会安装相同版本的模块，而是安装最新版本。

As for Strawberry Perl, there's a "portable" version you can install somewhere besides the default location. That way you could have the new perl on removable media. You can test it anywhere you like without disturbing the local installation. I don't think that's quite ready for general use though. The Berrybrewtool might help you manage that.

至于Strawberry Perl，有一个“便携式”版本，您可以安装在默认位置之外的其他地方。这样你就可以在可移动媒体上拥有新的 perl。您可以在任何您喜欢的地方进行测试，而不会干扰本地安装。不过，我认为这还没有完全准备好供一般使用。该Berrybrew工具可以帮助您管理。

Good luck, :)

祝你好运， ：）

回答by Andy Lester

I would seriously consider looking at using Strawberry Perl.

我会认真考虑使用Strawberry Perl。

回答by Michael Carman

You can install a second version of Perl in a different location. You'll have to re-install any non-core modules into the new version. In general, different versions of Perl are not binary compatible, which could be an issue if you have any program-specific libraries that utilize XS components. Pure Perl modules shouldn't be affected.

您可以在不同的位置安装第二个版本的 Perl。您必须将所有非核心模块重新安装到新版本中。通常，不同版本的 Perl 不是二进制兼容的，如果您有任何使用 XS 组件的特定于程序的库，这可能是一个问题。纯 Perl 模块不应该受到影响。

回答by dland

If you stay within the 5.8 track, all installed modules that contain XS (binary) extensions will continue to work, as binary compatibility is guaranteed within the same 5.8 series. If you moved to 5.10 then you would have to recompile any modules that contain XS components.

如果您保持在 5.8 轨道内，所有已安装的包含 XS（二进制）扩展的模块将继续工作，因为二进制兼容性在同一 5.8 系列中得到保证。如果您移至 5.10，则必须重新编译包含 XS 组件的所有模块。

All you need to do is ensure that the new build lists the previous include directories in its @INC array (which is used to look for modules).

您需要做的就是确保新构建在其 @INC 数组（用于查找模块）中列出以前的包含目录。

By the sounds of it, I think you're on Windows, in which case the current @INC paths can be viewed with

根据它的声音，我认为您使用的是 Windows，在这种情况下，可以使用以下命令查看当前的 @INC 路径

perl -le "print for @INC"

Make sure you target your new Perl version in another directory. It will happily coexist with the previous version, and this will allow you to choose which Perl installation gets used; it's just a question of getting your PATH order sorted out. As soon as a Perl interpreter is started up, it knows where to look for the rest of its modules.

确保在另一个目录中定位新的 Perl 版本。它将与以前的版本愉快地共存，这将允许您选择使用哪个 Perl 安装；这只是一个整理你的 PATH 顺序的问题。Perl 解释器一启动，它就知道去哪里寻找它的其余模块。

Strawberry Perl is probably the nicest distribution on Windows these days for rolling your own.

Strawberry Perl 可能是当今 Windows 上最好的发行版，可用于推出您自己的发行版。

回答by Kev

When I did it I installed the newer one into a separate directory. There's a bit of added confusion running two versions, but it definitely helps make sure everything's working first, and provides a quick way of switching back to the old one in a pinch. I also set up Apache to run two separate services, so I could monkey around with the newer Perl in one service without touching the production one on the old Perl.

当我这样做时，我将较新的安装到一个单独的目录中。运行两个版本会增加一些混乱，但它确实有助于确保一切正常工作，并提供了一种在紧要关头切换回旧版本的快速方法。我还设置了 Apache 来运行两个独立的服务，这样我就可以在一个服务中使用较新的 Perl，而无需接触旧 Perl 上的生产服务。

It's probably a lot wiser, in hindsight, to install on a separate computer, and do your testing there. Record every configuration change you need to make.

事后看来，安装在单独的计算机上并在那里进行测试可能要明智得多。记录您需要进行的每个配置更改。

I am not sure about building it yourself—I always just used prepackaged binaries for Windows.

我不确定自己构建它——我总是只使用预打包的 Windows 二进制文件。

I'm not sure I understand exactly what you're asking. Do you have a list of changes you made to the 5.8 makefile? Or is the question how to obtain such a list? Are you also asking how to find out which packages above the base install you've obtained from CPAN? Are you also asking how to test that your custom changes won't break those packages if you get them from CPAN again?

我不确定我是否完全理解你在问什么。您是否有对 5.8 makefile 所做更改的列表？或者是如何获得这样一个列表的问题？您是否还询问如何找出您从 CPAN 获得的基本安装之上的哪些软件包？如果您再次从 CPAN 获取它们，您是否还询问如何测试您的自定义更改不会破坏这些包？

回答by Sam Kington

I think the answer to this involves virtualisationof some kind:

我认为这个问题的答案涉及某种虚拟化：

1. Set up an exact copy of your current live machine. Upgrade Perl, using the same directory locations and structures as you're using at the moment.
2. Go through your scripts testing them on the new image.
3. Once you're happy, flip the switch.

1. 设置当前活动机器的精确副本。升级 Perl，使用与您目前使用的相同的目录位置和结构。
2. 通过您的脚本在新图像上测试它们。
3. 一旦你感到高兴，拨动开关。

The thinking behind this is that there's probably all sorts of subtle dependencies and assumptions you haven't thought of. While unlikely, the latest version of a particular module (possibly even a core module, although that's even more unlikely) might have a subtle difference compared to the one you were using. Unless you've exhaustively gone through your entire codebase, there's quite possibly a particular module that's required only under certain circumstances.

这背后的想法是，可能存在您没有想到的各种微妙的依赖关系和假设。虽然不太可能，但与您使用的模块相比，特定模块的最新版本（甚至可能是核心模块，尽管更不可能）可能会有细微的差异。除非您已经详尽地浏览了整个代码库，否则很可能只有在某些情况下才需要某个特定模块。

You can try and spot this by building a list of all your scripts - a list that you should have anyway, by dint of all your code being under version control (you areusing version control, e.g. Subversion, yes?) - and iterating through it, running perl -con each script. e.g. this script. That sort of automated test is invaluable: you can set it running, go away for a coffee or whatever, and come back to check whether everything worked. The first few times you'll probably find an obscure module that you'd forgotten about, which is fine: the whole point of automating this is so that youdon't have to do the drudge-work of checking every single script.

您可以通过构建所有脚本的列表来尝试发现这一点 - 无论如何都应该拥有一个列表，通过将所有代码都置于版本控制之下（您正在使用版本控制，例如Subversion，是吗？） - 并迭代它，perl -c在每个脚本上运行。例如这个脚本。这种自动化测试是无价的：您可以将其设置为运行，然后出去喝杯咖啡或其他什么，然后回来检查是否一切正常。最初几次您可能会发现一个您已经忘记的晦涩模块，这很好：自动化的全部意义在于您不必做检查每个脚本的苦差事。

回答by Alexander Farber

Why don't you use ActivePerl and its "ppm" tool to (re)install modules?

为什么不使用 ActivePerl 及其“ppm”工具来（重新）安装模块？