The question How do I upgrade strawberry perl without wiping \perl\site\lib\ and \perl\site\bin\? was asked in 2011 and it appears Strawberry did throw out any CPAN installs the user did whenever we upgraded to a newer version. Is this still the case? I found a comment from Adam Kennedy which seems related but I'm not sure whether the change was actually made and what its implications are.
Since Strawberry Perl is said to be "100% Open Source" I tried looking for a development site, a place where we could get more details and look at discussions, but I couldn't find any, the strawberryperl.com site is strangely devoid of any information in this regard. Even its Wikipedia page is (slightly) more informative. (Edit: I found http://code.google.com/p/strawberry-perl/ which could be a neat central portal of links, also http://search.cpan.org/~kmx/Perl-Dist-Strawberry-3.012/script/perldist_strawberry is quite informative.)
Also, in case Strawberry still does this, how can I make a local backup copy of the modules? I don't want to have to use CPAN's autobundle and redownload everything from scratch unnecessarily.
Update for future reference: from the comments I gather that since the content in site/lib and site/bin are currently build-dependent in Strawberry Perl, it's necessary to wipe them out and start afresh when installing a new version. This necessity might go away if Strawberry introduces a separate arch-directory to store architecture dependent stuff.
I would just rename C:\strawberry to C:\strawberry-old before installing the new version. Chances are you could just copy modules from the old installation to the new one (not forgetting to look for bits in the "auto" directories). That said, I would probably just reinstall everything from CPAN anyway to get the latest versions. It helps if you have a .bat file that automates this for your favourite additions.
Related
I thought it would be a good idea in general to update all software on my computer regularly. Since CPAN modules are not managed by my package manager I figured I should do cpan -u every once in a while. It was only after executing this that I read the man page note on this:
-u Upgrade all installed modules. Blindly doing this can really break
things, so keep a backup.
Why should this break anything? And how should I keep my CPAN modules up to date otherwise; do I need to keep track of all manually installed modules (cpan doesn't seem to do this) and only update those regularly? How about the dependencies of my manually installed modules?
Why did cpan -u upgrade stuff for ~15min even though I haven't installed a single CPAN module?
Can I revert the cpan -u? Is it enough to delete ~/.cpan for this?
Why should this break anything?
It shouldn't, but complex systems are complex and sometimes things do break (e.g. if a module is updated with a non-backwards compatible change, or depends on a C library which has bugs which only show up in combination with specific dependencies).
And how should I keep my CPAN modules up to date otherwise;
Just keep backups in case things break.
Why did cpan -u upgrade stuff for ~15min even though I haven't installed a single CPAN module?
Perl is distributed with a large collection of modules, and other modules may have been installed by your distribution.
Can I revert the cpan -u?
You can overwrite it with the backup that the documentation recommended you take.
Is it enough to delete ~/.cpan for this?
No. That directory is used by the installer tool to cache data about available modules, to store source code, and to hold build artefacts. The installed files are written to your lib like any other library.
New or update code is new or updated bugs. I have the opposite view of Quentin: why would changing a bunch of stuff keep not break things? That's what I expect with most updates. However, the Perl 5 porters take great pains to test perl distributions against as much of CPAN as they can. That doesn't mean that your particular use of a module (and how you've worked around existing bugs) is stable.
Some modules that come with perl are also on CPAN. These are "dual-lived" modules and they might update from CPAN.
The cpan tool doesn't revert anything for you, but you can do what I do sometimes. Make your installation a git repo. Branch when you change it. Try the branch with your code. If anything goes wrong you can always switch back to master. You don't even need to commit the changes! Tools such as Pinto help you manage sets of Perl modules.
There are some other things to consider.
First, I recommend that you don't mess with the system perl. Let the system do that. If you want a fresher perl that you manage yourself, install a different one. You might like perlbrew for that (I don't, but that's no big deal).
You can screw up that one as much as you like and the system won't start doing weird things. Consider major changes like removing . from #INC and Deprecating unescaped left braces in regexes. Those were changes in perl but they broke some important things.
Second, you can configure cpan to install somewhere besides the system directories. The -I switch will use local::lib for you. Besides that, you can configure it manually.
cpan fails with this weird error as follows
Error: Unable to locate installed Perl libraries or Perl source code.
It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.
(You get this message, because MakeMaker could not find "D:\fbl_esc_bcd_tb\tools\perl\lib\CORE\perl.h")
Running make test
Make had some problems, maybe interrupted? Won't test
Running make install
Make had some problems, maybe interrupted? Won't install
Problem is I can't install new active perl versions in this environment and the tool I want to coverage on does not run outside this environment.
Short answer: The ActiveState PPM repository has a precompiled version of Devel::Cover you should be able to install.
Long answer: That's not a normal message from MakeMaker so I'm willing to guess its an ActiveState addition, but its probably true. The problem is exactly what the error message says; your distribution is missing some important files, specifically the C header files for Perl, so it cannot compile C code necessary for modules like Devel::Cover. This is often the result of an overzealous sysadmin or packager looking to save a few dozen K of disk space. You could probably take the header files from the 5.8.7 source, copy them into the CORE directory and it will probably work. It won't make anything worse.
I agree with Evan that, assuming this is a Windows machine, you should switch to Strawberry Perl which plays much better with the rest of the Perl community than ActivePerl.
Otherwise, ActiveState is a commercial company and they have paid Perl support. Give them a ring.
Active Perl does not use CPAN. If you want to use CPAN use Strawberry Perl. Active Perl uses binary distribution through its ppm system. There are a few third party repos for it if the official one doesn't have Devel::Cover -- though the official probably has Devel::Cover.
Most people these days are moving to Strawberry and away from AS. In my opinion, it is far more stable and CPAN-friendly, and surely less proprietary. Also, expect to be able to get stable versions of most everything - AS has been known to lag years in many occasions in the official repos. strawberry also comes with its own compiler and build environment so you can even get ::XS versions working with ease.
I would like to ask my system administrator to install various Perl modules such as Moose and Data::Alias. The system is Red Hat Enterprise Linux 5, running Perl 5.8.8. The only problem that I can think of is that some already-installed modules might need to be upgraded and thus run the risk of breaking something. What else should I be concerned about?
I do not know your company's policy, but it would probably be a better idea not to mess with your system perl and install the additional libraries and their prerequisites (and even a dedicated perl) in a different location and use lib.
See also How do I keep my own module/library directory? in perlfaq.
Our systems administrators are the ones who are concerned with making sure requested Perl modules don't break anything else on their systems.
So we ask, then they can say "No, that will break X, please install that in user-space." or "We'll install that at non-standard location Y, for compatibility reasons." I don't know all of the things they take into consideration when making that decision. The only thing I am supposed to know is whether or not my applications will break when modules are installed/updated.
If your system administrators are passing this responsibility (i.e. knowing the impact on the system as a whole) to you as a developer, it's probably much safer to go along with Sinan's suggestion and install the modules you need in a non-standard location for yourself. Having to be a system administrator and a developer at the same time while being paid to be only one is no fun.
The trick is to not get rid of your old setup until you know your new setup works. The rub is that the CPAN toolchain doesn't care and will happily install new files over old ones without giving you a way to uninstall your damage.
If I'm working on a big project where I'm going to upgrade modules, I like to put the new modules in their own, new directory. I can test things by settingPERL5LIB to the new directories, and if it doesn't work out, I'm back to the old setup with a simple change of the environment.
Some people do something similar with source control. They put their modules directory in a versioning system. When they install new modules, they check in the source. When something breaks, they just roll back the changes. They can also tag versions so they can roll back to any working point.
This is an often asked question especially if you are using shared hosting or have a hosting provider that is leery of installing perl modules.
There is a fix, a way to work around this problem of mixing system modules and your own modules, and that fix is called local::lib. local::lib provides a way for you to install modules locally, in a library specified by you, which you have control over. You can use /home/you/perl5/ for example, or any path you think will work.
PS - Moose modules will most likely not interfere with other perl 5 modules since Moose has clean and separate namespace. It does require lots of modules from CPAN however, so warn your sysadmin in advance. :)
Also, ask your sysadmin to upgrade perl to 5.10, that brings lots of good new stuff into perl's core and allows you to use some shiny new perl technology.
I'm tasked with replicating a production environment to create many test/sit environments.
One of the things I need to do is build up Perl, with all the modules which have been installed (including internal and external modules) over the years. I could just use CPAN.pm autobundle, but this will result in the test environment having much newer versions of the external modules that production has.
What is the easiest/best way to get and install (a lot of) version specific Perl modules.
bdfoy has the best large scale solution, but if you just want to install a few modules you can ask the CPAN shell to install a specific distribution by referencing a path to a tarball (relative to the top of the CPAN tree).
cpan> install MSCHWERN/Test-Simple-0.62.tar.gz
Throw a URL to BackPAN into your URL list and you can install any older version.
cpan> o conf urllist push http://backpan.perl.org/
This is in the CPAN.pm FAQ under "how do I install a 'DEVELOPER RELEASE' of a module?"
cpan install App::cpanminus
cpanm Your::Module#1.23
(Carton, as referenced in other answers, uses cpanm underneath to resolve explicit version requirements.)
Make your own CPAN mirror with exactly what you want. Stratopan.com, a service, and Pinto, tools that's built on top of, can help you do that.
The CPAN tools only install the latest version of any distribution because PAUSE only indexes the latest version. However, you can create your own, private CPAN that has exactly the distributions that you want. Once you have your own CPAN mirror with only what you want, you point your CPAN tools at only that mirror so it only installs those versions. More on that in a minute.
Now, you want to have several versions of that. You can create as many mirrors as you like, and you can also put the mirrors in source control so you can check out any version of the mirror that you like.
Tools such as CPAN::Mini::Inject can help you set up your own CPAN. Check out my talks on Slideshare for the basic examples, and some of my videos on Vimeo for some of the demonstrations. Look at anything that has "CPAN" or "BackPAN" in the title. I think I might have some stuff about it in The Perl Review too, or should by the next issue. :)
Lately, I've been working on a program called dpan (for DarkPAN) that can look at random directories, find Perl distributions in them, and create the structure and index files that you need. You run dpan, you get a URL to point your CPAN client toward, and off you go. It's part of my MyCPAN-Indexer project, which is in Github. It's not quite ready for unsupervised public use because I mostly work with corporate clients to customize their setup. If you're interested in that, feel free to ask me questions though.
Also, I recently released CPAN::PackageDetails that can help you build the right index file. It's still a bit young too, but again, if you need something special, just ask.
[It's almost five years on and this is a well-asked and well-answered question that has had a lot of views. Since this page must still come up in Google searches, an update can't hurt.]
Carton is worth mentioning here. Carton is a relatively recent tool in the same style as App::cpanminus, App::cpanoutdated, perlbrew, et. al. The author (Miyagawa) calls it "alpha" quality, but even in its current state carton helps simplify the maintenance of multiple environments of version tuned modules across machines.
Pinto too is another recent tool relevant to some of the responses (in fact one of the respondents is a contributor).
Stratopan.com is another alternative. Stratopan provides private CPANs in the cloud. You can fill your Stratopan repository with specific versions of modules (and their dependencies) and then install them using the standard Perl tool chain. The repository changes only when you decide to change it, so you'll get always get the versions of the modules that you want.
Disclaimer: I operate Stratopan.
It seems that creating a cpanfile listing all your modules and desired versions (using the == <version> syntax to lock it to a specific release) could serve well here, too. That would mean using Carton or cpanm for installing the modules.
Doing this would have the benefit of being able to quickly/easily tweak the file to test upgrading specific modules in a dev or staging environment - something that a private CPAN mirror wouldn't let you do (without creating multiple mirrors).
It seems that most of the installers for Perl are centered around installing Perl modules, not applications. Things like ExtUtils::MakeMaker and Module::Build are very well suited for modules, but require some additional work for Web Apps.
Ideally it would be nice to be able to do the following after checking out the source from the repository:
Have missing dependencies detected
Download and install dependencies from CPAN
Run a command to "Build" the source into a final state (perform any source parsing or configuration necessary for the local environment).
Run a command to install the built files into the appropriate locations. Not only the perl modules, but also things like template (.tt) files, and CGI scripts, JS and image files that should be web-accessible.
Make sure proper permissions are set on installed files (and SELinux context if necessary).
Right now we have a system based on Module::Build that does most of this. The work was done by done by my co-worker who was learning to use Module::Build at the time, and we'd like some advice on generalizing our solution, since it's fairly app-specific right now. In particular, our system requires us to install dependencies by hand (although it does detect them).
Is there any particular system you've used that's been particularly successful? Do you have to write an installer based on Module::Build or ExtUtils::MakeMaker that's particular to your application, or is something more general available?
EDIT: To answer brian's questions below:
We can log into the machines
We do not have root access to the machines
The machines are all (ostensibly) identical builds of RHEL5 with SELinux enabled
Currently, the people installing the machines are only programmers from our group, and our source is not available to the general public. However, it's conceivable our source could eventually be installed on someone else's machines in our organization, to be installed by their programmers or systems people.
We install by checking out from the repository, though we'd like to have the option of using a distributed archive (see above).
The answer suggesting RPM is definitely a good one. Using your system's package manager can definitely make your life easier. However, it might mean you also need to package up a bunch of other Perl modules.
You might also take a look at Shipwright. This is a Perl-based tool for packaging up an app and all its Perl module dependencies. It's early days yet, but it looks promising.
As far as installing dependencies, it wouldn't be hard to simply package up a bunch of tarballs and then have you Module::Build-based solution install them. You should take a look at pip, which makes installing a module from a tarball quite trivial. You could package this with your code base and simply call it from your own installer to handle the deps.
I question whether relying on CPAN is a good idea. The CPAN shell always fetches the latest version of a distro, rather than a specific version. If you're interested in ensuring repeatable installs, it's not the right tool.
What are your limitations for installing web apps? Can you log into the machine? Are all of the machines running the same thing? Are the people installing the web apps co-workers or random people from the general public? Are the people installing this sysadmins, programmers, web managers, or something else? Do you install by distributed an archive or checking out from source control?
For most of my stuff, which involves sysadmins familiar with Perl installing in control environments, I just use MakeMaker. It's easy to get it to do all the things you listed if you know a little about MakeMaker. If you want to know more about that, ask a another question. ;) Module::Build is just as easy, though, and the way to go if you don't already like using MakeMaker.
Module::Build would be a good way to go to handle lots of different situations if the people are moderately clueful about the command line and installing software. You'll have a lot of flexibility with Module::Build, but also a bit more work. And, the cpan tool (which comes with Perl), can install from the current directory and handle dependencies for you. Just tell it to install the current directory:
$ cpan .
If you only have to install on a single platorm, you'll probably have an easier time making a package in the native format. You could even have Module::Build make that package for you so the developers have the flexibility of Module::Build, but the installers have the ease of the native process. Sticking with Module::Build also means that you could create different packages for different platforms from a single build tool.
If the people installing the web application really have no idea about command lines, CPAN, and other things, you'll probably want to use a packager and installer that doesn't scare them or make them think about what is going on, and can accurately report problems to you automatically.
As Dave points out, using a real CPAN mirror always gets you the latest version of a module, but you can also make your own "fake" CPAN mirror with exactly the distributions you want and have the normal CPAN tools install from that. For our customers, we make "CPAN on a CD" (although thumb drives are good now too). With a simple "run me" script everything gets installed in exactly the versions they need. See, for instance, my Making my own CPAN talk if you're interested in that. Again, consider the audience when you think about that. It's not something you'd hand to the general public.
Good luck, :)
I'd recommend seriously considering a package system such as RPM to do this. Even if you're running on Windows I'd consider RPM and cygwin to do the installation. You could even set up a yum or apt repository to deliver the packages to remote systems.
If you're looking for a general installer for customers running any number of OSes and distros, then the problem becomes much harder.
Take a look at PAR.
Jonathan Rockway as a small section on using this with Catalyst in his book.