Perl and the Catalyst framework on Arch Linux

ido50 · 2009-03-20 13:08:34

Hi there.

After years of using Debian unstable (only distribution I've ever used), I've switched to Arch Linux due to various reasons, and am generally satisfied. There's only one thing that's keeping me from being completely satisfied, is Perl and Catalyst, a web development framework in CPAN.

First of all, I have found that Arch has a considerably smaller number of Perl module packages, compared to Debian, and that it does not have packages for Catalyst. Which shouldn't be a problem since you can install everything from CPAN. But that turned out to be a huge problem. Catalyst depends on SQLite3 and the DBIx::Class perl modules (among many others). Unfortunately, when trying to install DBIx::Class, the cpan shell complains that my SQLite3 version is buggy and cannot be used.

Well, I have tried everything: Installing Perl from source with ABS, installing SQLite3 from source with ABS and from the SQLite website without ABS. I have tried creating packages with pacpan, but it's very hard to use when using the --prefer-cpan option. Nothing works.

After days of failures after failures, I had no choice but to take an older hard drive and install Debian unstable on it, as my job is web development with Catalyst.

Can anyone help me with the process of setting up a complete Perl installation with Catalyst/DBIx::Class/Sqlite3/etc.? What can be done in order to make pacman packages of perl modules more readily available?

Thanks,
Ido Perelmutter.

Mod edit - links changed to BBCode format, tomk

juster · 2009-03-20 19:44:13

I just ignored the errors from 'make test' since I wasn't going to be using SQLite. That is probably a "bad thing to do" but it never affected me. But I went back now and found a quick fix.

Poking around in the Makefile.PL I found that you can provide the command line argument USE_LOCAL_SQLITE. Settings this to 1 will compile the module with the SQLite that is included in the module tarball. It's so small he included it, how cool! This version of SQLite did not give me any errors in 'make test'.

Just in case you need help, to compile the module without CPAN you would download it, cd to the dir with the tar.gz file, then do:

tar zxf DBD-SQLite-1.14.tar.gz
cd DBD-SQLite-1.14
perl Makefile.PL USE_LOCAL_SQLITE=1
make
make test
sudo make install

Xyne · 2009-03-20 21:47:22

ido50 wrote:

Can anyone help me with the process of setting up a complete Perl installation with Catalyst/DBIx::Class/Sqlite3/etc.?

Yes. Yes, I can.

ido50 wrote:

What can be done in order to make pacman packages of perl modules more readily available?

Use pacpan.

It can create packages from CPAN modules, resolve dependencies, detect equivalent packages, etc. In your case, run

pacpan Catalyst DBIx::Class

I've tested the above and it now works fine on my system. If pacman complains about conflicting files etc, you should remove any CPAN modules that you've manually installed and then try again. In fact, you should remove any manually installed CPAN modules regardless... using pacpan is a much cleaner way to install them.

Thanks btw... building these packages brought several CPAN irregularities to my attention and led to several improvements in pacpan.

ido50 · 2009-03-23 23:16:04

juster and Xyne: Thanks a lot for the help. I've finally managed to do it, but it wasn't easy. I guess I should have written that a proper Cataylst installation is done by installing the Catalyst::Devel module and not just the Catalyst module (which is provided by Catalyst::Devel), so maybe that's why Xyne managed to do it but I still faced some difficulties.

Anyway, here's all the steps I'd done:

1. Removed perl completely as I had installed way too many modules from cpan manually, then reinstalled Perl.
2. Updated pacpan.
3. Created a perl-dbd-sqlite (For DBD::SQLite) package from ABS with makepkg, adding the USE_LOCAL_SQLITE option to the PKGBUILD file.
4. Installed DBIx::Class with pacpan.
4.1. pacpan got stuck while installing JSON::Any, in the "installing dependencies" step. So I quit and installed JSON::Any with pacpan.
4.2. Continued installing DBIx::Class with pacpan, no problems thanks to the new DBD::SQLite package.
5. Installed Catalyst::Devel with pacpan.
5.1. Failed complaining file conflicts when installing the HTTP::Response module, which is weird because before doing all of this I completely removed perl and all its modules from my computer. Anyway, I restarted build_cpan with --pacman-args -f to force overwriting, and it continued.
5.2. Failed again when building Data::OptList with this error: "error: failed to prepare transaction (could not satisfy dependencies)", and after a newline: ":: perl-data-optlist: requires", which is weird... What does it require?
5.3. Tried to install Data::OptList itself with pacpan, same failure.
5.4. Created a PKGBUILD file for Data::Optlist and created a package with makepkg.
5.5. Continued pacpan for Catalyst::Devel, build_cpan failed immediately for Sub::Exporter with same error messages as above.
5.6. Created a PKGBUILD file for Sub::Exporter and created a package with makepkg.
5.7. Continued pacpan for Catalyst::Devel, build_cpan failed immediately for B::Hooks::EndOfScope, with the same error messages as before. Something seems to have screwed pacpan.
5.8. Did the same thing for B::Hooks::EndOfScope.
5.9. Restarted pacpan for Catalyst::Devel with no particular hope, but it actually managed to continue, but failed the same way again after a while with Catalyst::Devel itself.
5.10. Created a package with makepkg yet again.
6. That's it, I finally have a working Catalyst installation!

Thanks again, and thanks Xyne for creating pacpan, it's great, but there's definitely room for improvement.

By the way, I'm more than willing to create a repository of CPAN modules, but as I'm still new to Arch will need some help with that (On the technical side I mean, I have a server with a lot of space).

Last edited by ido50 (2009-03-23 23:19:34)

Xyne · 2009-03-23 23:33:32

Funny that you should reply now... I updated pacpan about an hour ago (improved meta-data handling).

I've just tested "pacpan Catalyst::Devel" and it does fail on the first run due to file conflicts (due to overlapping module files... a fault of CPAN). Running "pacpan Catalyst::Devel" again after the error creates a new "build_cpan" which completes successfully due to pacpan's ability to detect installed perl modules. The overall process:

pacpan Catalyst::Devel
./build_cpan
pacpan Catalyst::Devel
./build_cpan

Note that the second time pacpan is run, it takes much less time:

$ pacpan Catalyst::Devel
--> Catalyst::Devel RETRIEVING CPAN INFO 
-->   parent FOUND PKG: perl-parent (already installed)
-->   Catalyst::Plugin::Static::Simple FOUND PKG: perl-catalyst-plugin-static-simple (already installed)
-->   Catalyst::Plugin::ConfigLoader FOUND PKG: perl-catalyst-plugin-configloader (already installed)
-->   Class::Accessor FOUND PKG: perl-class-accessor (in repo)
-->   Template FOUND PKG: perl-template (already installed)
-->   Module::Install FOUND PKG: perl-module-install (already installed)
-->   Catalyst::Action::RenderView FOUND PKG: perl-catalyst-action-renderview (already installed)
-->   Config::General FOUND PKG: perl-config-general (already installed)
-->   Catalyst FOUND PKG: perl-catalyst-runtime (already installed)
-->   File::Copy::Recursive RETRIEVING CPAN INFO 
-->     PathTools FOUND PKG: perl (already installed)
-->   Path::Class FOUND PKG: perl-path-class (already installed)
==> SUCCESS: generated build script: build_cpan
--> run "./build_cpan" to build and install the packages
--> run "./build_cpan --help" to see the available build options

Here's the full list of packages that the above commands create and install:

             perl-catalyst-devel-1.08-1  perl-template-2.20-1  perl-appconfig-1.66-2  perl-parent-0.221-1  perl-module-install-0.80-1  perl-yaml-tiny-1.36-1  
             perl-par-dist-0.44-1  perl-module-scandeps-0.83-1  perl-file-remove-1.42-1  perl-file-copy-recursive-0.38-1  perl-config-general-2.42-1  
             perl-catalyst-plugin-static-simple-0.20-1  perl-mime-types-1.27-1  perl-catalyst-plugin-configloader-0.22-1  perl-config-any-0.17-1  
             perl-catalyst-action-renderview-0.09-1  perl-data-visitor-0.22-1  perl-tie-toobject-0.03-1  perl-test-use-ok-0.02-1  perl-test-mockobject-1.09-1  
             perl-universal-isa-1.01-1  perl-universal-can-1.12-3  perl-namespace-clean-0.11-1  perl-b-hooks-endofscope-0.07-1  perl-variable-magic-0.32-1  
             perl-mouse-0.19-1  perl-catalyst-runtime-5.71000-1  perl-tree-simple-visitorfactory-0.10-1  perl-tree-simple-1.18-1  perl-text-simpletable-0.05-1  
             perl-http-request-ascgi-0.5-1  perl-class-accessor-0.31-3  perl-http-body-1.05-1  perl-yaml-0.68-1  perl-file-modified-0.07-1  perl-data-dump-1.14-1  
             perl-class-inspector-1.23-1  perl-class-data-inheritable-0.08-1  perl-cgi-simple-1.108-1  perl-path-class-0.16-1

If you have everything working already, I don't expect you to test that but please report back if you do. I'll gladly try to implement further improvements, but there are some intrinsic limitations due to the CPAN itself (overlapping modules, incomplete META.yml files, etc).

I'll add some more info to the site eventually explaining how best to work around errors when they pop up, as most of them are trivial.

*edit*
Added a "troubleshooting" section to the page.

Last edited by Xyne (2009-03-24 00:26:51)

Daenyth · 2009-03-24 00:06:05

I don't know if you already know about this, but there are a large number of perl modules already available on the AUR, so check there as well.

juster · 2009-03-24 05:41:47

A bad part about perl packages on AUR is they can go out of date quickly. The perl-catalyst-devel package is for version 1.08, from July 2008. But, slightly more on topic (re: the original problem) is that AUR packages don't run "make test".

The original problem was that "make test" failed for DBD::SQLite. If ido50 had used the AUR package they would have never known that the perl module they installed had a potential problem (bug!?), because AUR perl modules never run tests. Even the example PKGBUILD for perl modules on the "Perl Package Guidelines" page of the wiki does not run tests. This just seems to be the norm for Archlinux for some reason.

It just seems strange that ido50 says "Hey, WTF my test failed!" and we go, "Here's a solution, we fixed your failed tests by ignoring them!"

ido50 · 2009-03-24 06:13:44

Xyne wrote:

Funny that you should reply now... I updated pacpan about an hour ago (improved meta-data handling).
I've just tested "pacpan Catalyst::Devel" and it does fail on the first run due to file conflicts (due to overlapping module files... a fault of CPAN). Running "pacpan Catalyst::Devel" again after the error creates a new "build_cpan" which completes successfully due to pacpan's ability to detect installed perl modules. The overall process:
pacpan Catalyst::Devel
./build_cpan
pacpan Catalyst::Devel
./build_cpan
Note that the second time pacpan is run, it takes much less time:
$ pacpan Catalyst::Devel
--> Catalyst::Devel RETRIEVING CPAN INFO 
-->   parent FOUND PKG: perl-parent (already installed)
-->   Catalyst::Plugin::Static::Simple FOUND PKG: perl-catalyst-plugin-static-simple (already installed)
-->   Catalyst::Plugin::ConfigLoader FOUND PKG: perl-catalyst-plugin-configloader (already installed)
-->   Class::Accessor FOUND PKG: perl-class-accessor (in repo)
-->   Template FOUND PKG: perl-template (already installed)
-->   Module::Install FOUND PKG: perl-module-install (already installed)
-->   Catalyst::Action::RenderView FOUND PKG: perl-catalyst-action-renderview (already installed)
-->   Config::General FOUND PKG: perl-config-general (already installed)
-->   Catalyst FOUND PKG: perl-catalyst-runtime (already installed)
-->   File::Copy::Recursive RETRIEVING CPAN INFO 
-->     PathTools FOUND PKG: perl (already installed)
-->   Path::Class FOUND PKG: perl-path-class (already installed)
==> SUCCESS: generated build script: build_cpan
--> run "./build_cpan" to build and install the packages
--> run "./build_cpan --help" to see the available build options
Here's the full list of packages that the above commands create and install:
             perl-catalyst-devel-1.08-1  perl-template-2.20-1  perl-appconfig-1.66-2  perl-parent-0.221-1  perl-module-install-0.80-1  perl-yaml-tiny-1.36-1  
             perl-par-dist-0.44-1  perl-module-scandeps-0.83-1  perl-file-remove-1.42-1  perl-file-copy-recursive-0.38-1  perl-config-general-2.42-1  
             perl-catalyst-plugin-static-simple-0.20-1  perl-mime-types-1.27-1  perl-catalyst-plugin-configloader-0.22-1  perl-config-any-0.17-1  
             perl-catalyst-action-renderview-0.09-1  perl-data-visitor-0.22-1  perl-tie-toobject-0.03-1  perl-test-use-ok-0.02-1  perl-test-mockobject-1.09-1  
             perl-universal-isa-1.01-1  perl-universal-can-1.12-3  perl-namespace-clean-0.11-1  perl-b-hooks-endofscope-0.07-1  perl-variable-magic-0.32-1  
             perl-mouse-0.19-1  perl-catalyst-runtime-5.71000-1  perl-tree-simple-visitorfactory-0.10-1  perl-tree-simple-1.18-1  perl-text-simpletable-0.05-1  
             perl-http-request-ascgi-0.5-1  perl-class-accessor-0.31-3  perl-http-body-1.05-1  perl-yaml-0.68-1  perl-file-modified-0.07-1  perl-data-dump-1.14-1  
             perl-class-inspector-1.23-1  perl-class-data-inheritable-0.08-1  perl-cgi-simple-1.108-1  perl-path-class-0.16-1
If you have everything working already, I don't expect you to test that but please report back if you do. I'll gladly try to implement further improvements, but there are some intrinsic limitations due to the CPAN itself (overlapping modules, incomplete META.yml files, etc).
I'll add some more info to the site eventually explaining how best to work around errors when they pop up, as most of them are trivial.
*edit*
Added a "troubleshooting" section to the page.

Well I must have updated pacpan just a while before you updated it, since I now see that a newer version is available:)

Anyway, as I already finished installing, I can't verify your process. By the way, it seems that a lot of perl packages on Arch are not updated, which makes using --prefer-cpan kinda tempting. Problem is when I tested pacpan with --prefer-cpan (a few days ago, haven't tried it since) it never created the build_cpan script. It went through the dependency search, but when it finished, it didn't do nothing... Want me to try it on something and report back?

Xyne · 2009-03-24 06:39:14

ido50 wrote:

Want me to try it on something and report back?

If you have the time and motivation, definitely. You can post your feedback in this thread to avoid further threadjacking of this one.

I'll look into adding a "test" option to the pacpan build script.

Arch Linux

#1 2009-03-20 13:08:34

Perl and the Catalyst framework on Arch Linux

#2 2009-03-20 19:44:13

Re: Perl and the Catalyst framework on Arch Linux

#3 2009-03-20 21:47:22

Re: Perl and the Catalyst framework on Arch Linux

#4 2009-03-23 23:16:04

Re: Perl and the Catalyst framework on Arch Linux

#5 2009-03-23 23:33:32

Re: Perl and the Catalyst framework on Arch Linux

#6 2009-03-24 00:06:05

Re: Perl and the Catalyst framework on Arch Linux

#7 2009-03-24 05:41:47

Re: Perl and the Catalyst framework on Arch Linux

#8 2009-03-24 06:13:44

Re: Perl and the Catalyst framework on Arch Linux

#9 2009-03-24 06:39:14

Re: Perl and the Catalyst framework on Arch Linux

Board footer