Re: [Catalyst] on the topic of PAR file distribution, why is it frowned upon?
Anybody else tried Shipwright? Rob How has shipwright worked with catalyst apps? I'm wondering how to ensure that dependancies are identical for dev and production environments. Shipwright looks like it should solve the problem, maybe with a little bit of local::lib, but has anyone evolved a working recipe? I'd like to move a couple of apps from relying on a mini-cpan into shipwright as it looks a lot more robust. However, the Shipwright docs unfortunately don't cover this particular use-case. The ideal situation will be to have each app directory containing all dependencies and app code, with a script to build a vessel which can be pushed to production. This allows us to develop each app separately without worries about different apps being on different Catalyst versions or anything else. This works ok with a mini-cpan for each app, but Shipwright is _much_ better at resolving and capturing module dependancies that we currently do manually. - Chris ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] on the topic of PAR file distribution.
On 1 Mar 2010, at 02:08, Toby Corkindale wrote: I was thinking it'd be in Module::Install::Catalyst, with some automatically-added -M options to par. Yes, that sounds more sane... Speaking of M-I-C, is there a good reason why STDERR is redirected to /dev/null, as well as __WARN__? I ask, because it makes debugging catalyst_par builds a PITA.. I always go in and edit MIC to undo that stuff now, and can't see a good reason not to take it out. I think it's just a reduction of the amount of stuff spraffed to the screen. However, I'd be all in favour of taking it out if it doesn't make the normal build much noisier. Patch welcome. I tried to fix this (and made a branch which you'll find in our svn), but this just made PAR shit itself on my mac, and given I'm not a PAR user and nobody else was showing any interest, I gave up. If there is an active PAR user out there who would like to get this fixed - come chat to someone in #catalyst-dev, as that can totally happen. I'm trying to checkout the git repo, but despite following http://wiki.catalystframework.org/wiki/contrib I am getting an error when trying to clone http://git.shadowcat.co.uk/catagits/Catalyst-Devel.git I think you wanted git:// rather than http. Is the contrib page out of date perhaps? The gitweb still seems to work, but I can't clone from it. s/out of date/wrong/. Please fix? :) (The repository metadata should have the correct URI, if it doesn't please log a bug!) Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] on the topic of PAR file distribution.
On 26/02/10 13:04, Tomas Doran wrote: On 26 Feb 2010, at 01:34, Toby Corkindale wrote: On 26/02/10 11:27, Tommy Butler wrote: What's the downside of this? How is this going to pose a problem for me? Installing from subversion and then CPANning all the required libs into the system via the makefile is terribly slow and error prone. There's an obvious negative there. What's the negative with using PAR when compared to this other method of deployment? [snip] Secondly, PAR is a nightmare. It's meant to automatically locate all your dependencies, but in practice this never finds all of them. Eg. Building a catalyst_par for a fastcgi-based app is broken out of the box. (It doesn't pick up Catalyst::ScriptRunner) Patches to require the appropriate modules in Catalyst.pm so that Catalyst does work out the box would be welcome. Is requiring the modules in Catalyst.pm the correct way to do this? I was thinking it'd be in Module::Install::Catalyst, with some automatically-added -M options to par. Speaking of M-I-C, is there a good reason why STDERR is redirected to /dev/null, as well as __WARN__? I ask, because it makes debugging catalyst_par builds a PITA.. I always go in and edit MIC to undo that stuff now, and can't see a good reason not to take it out. I tried to fix this (and made a branch which you'll find in our svn), but this just made PAR shit itself on my mac, and given I'm not a PAR user and nobody else was showing any interest, I gave up. If there is an active PAR user out there who would like to get this fixed - come chat to someone in #catalyst-dev, as that can totally happen. I'm trying to checkout the git repo, but despite following http://wiki.catalystframework.org/wiki/contrib I am getting an error when trying to clone http://git.shadowcat.co.uk/catagits/Catalyst-Devel.git Is the contrib page out of date perhaps? The gitweb still seems to work, but I can't clone from it. ta, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] on the topic of PAR file distribution, why is it frowned upon?
I've actually had pretty good results deploying my web apps with Shipwright. The docs and the code are rough, but it actually works pretty well. It sputters a bit on configure-requires and on some of the stranger cases of dependencies, but sounds like it works better than PAR. Anybody else tried Shipwright? Rob ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] on the topic of PAR file distribution, why is it frowned upon?
On 26/02/10 11:27, Tommy Butler wrote: Hello all, I will be deploying a catalyst app onto several dozens of servers in the next months, which will probably turn into more than that eventually. It is a year in the making, and quite complex in terms of all the things it requires to run (libraries). Given that, a PAR distribution file seems like a great way to go. Yet my co-worker told me that this has been frowned on as of late-- that there has been a shift in opinion about deploying cat apps as PARs. What's the downside of this? How is this going to pose a problem for me? Installing from subversion and then CPANning all the required libs into the system via the makefile is terribly slow and error prone. There's an obvious negative there. What's the negative with using PAR when compared to this other method of deployment? The main problems are that PAR doesn't actually work very well. Firstly, it is severely broken on perl 5.10.0, so you'll either need to stick with perl 5.8.x or go to perl 5.10.1. (Or backport fixes from perl 5.10.1 to .0, but there lies insanity.) Secondly, PAR is a nightmare. It's meant to automatically locate all your dependencies, but in practice this never finds all of them. Eg. Building a catalyst_par for a fastcgi-based app is broken out of the box. (It doesn't pick up Catalyst::ScriptRunner) So you'll need to go through a long cycle of * build par * attempt to run it, and discover which modules are missing * add those modules to list of extras * Repeat. A lot. You'll also need to explicitly list all the /var/lib/* things you need, like libpq.so, libxml.so, etc as those aren't picked up.. and all their dependencies manually too. I really don't like deployment methods that are based on trial-and-error. It doesn't give me any confidence that we did manage to find all the extra modules to list as inclusions.. and so you can bet that there's one more missing, that won't be discovered until your app is crashing in production. So, there are some negatives for PAR. The question is, do they outweigh the negatives for using CPAN to install random, latest-and-possibly-broken packages via the Makefile every time? Some shops have a rule that you must only use the versions of modules that are available pre-packaged for the operating system. This gets around the problems of having to install everything by hand, and also means you get consistent versions of modules.. However it also means you're stuck with a small subset of CPAN, and usually very old versions as well. (For eg, Debian is still on Catalyst 5.7 I believe.) My own solution was a fourth option: Build your own Perl, and all the required modules, installed into a custom directory - and then ship this with your application. It'll blow the size out by a hundred meg or so, but at least you know it'll work, and it's using known-good versions of CPAN modules. -Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] on the topic of PAR file distribution, why is it frowned upon?
On 26 Feb 2010, at 01:34, Toby Corkindale wrote: On 26/02/10 11:27, Tommy Butler wrote: Hello all, I will be deploying a catalyst app onto several dozens of servers in the next months, which will probably turn into more than that eventually. It is a year in the making, and quite complex in terms of all the things it requires to run (libraries). Given that, a PAR distribution file seems like a great way to go. Yet my co-worker told me that this has been frowned on as of late-- that there has been a shift in opinion about deploying cat apps as PARs. Conceptually, deploying a Catalyst app as a PAR is a great idea. Practice however is somewhat different :( What's the downside of this? How is this going to pose a problem for me? Installing from subversion and then CPANning all the required libs into the system via the makefile is terribly slow and error prone. There's an obvious negative there. What's the negative with using PAR when compared to this other method of deployment? The main problems are that PAR doesn't actually work very well. Firstly, it is severely broken on perl 5.10.0, so you'll either need to stick with perl 5.8.x or go to perl 5.10.1. (Or backport fixes from perl 5.10.1 to .0, but there lies insanity.) Secondly, PAR is a nightmare. It's meant to automatically locate all your dependencies, but in practice this never finds all of them. Just so. In fact, it won't find everything you declare in Makefile.PL (just the things found when perl -c ing your app). It will also miss .so (system shared library) files that might not be on all systems. Common examples being libexpat, libxml2 and libssleay - there are loads of others :) Eg. Building a catalyst_par for a fastcgi-based app is broken out of the box. (It doesn't pick up Catalyst::ScriptRunner) Patches to require the appropriate modules in Catalyst.pm so that Catalyst does work out the box would be welcome. I tried to fix this (and made a branch which you'll find in our svn), but this just made PAR shit itself on my mac, and given I'm not a PAR user and nobody else was showing any interest, I gave up. If there is an active PAR user out there who would like to get this fixed - come chat to someone in #catalyst-dev, as that can totally happen. So you'll need to go through a long cycle of * build par * attempt to run it, and discover which modules are missing * add those modules to list of extras * Repeat. A lot. Quite.. You'll also need to explicitly list all the /var/lib/* things you need, like libpq.so, libxml.so, etc as those aren't picked up.. and all their dependencies manually too. Oh yes - DB libraries, more fun :) I really don't like deployment methods that are based on trial-and- error. It doesn't give me any confidence that we did manage to find all the extra modules to list as inclusions.. and so you can bet that there's one more missing, that won't be discovered until your app is crashing in production. So, there are some negatives for PAR. The question is, do they outweigh the negatives for using CPAN to install random, latest-and-possibly-broken packages via the Makefile every time? The other option? :) Some shops have a rule that you must only use the versions of modules that are available pre-packaged for the operating system. This gets around the problems of having to install everything by hand, and also means you get consistent versions of modules.. However it also means you're stuck with a small subset of CPAN, and usually very old versions as well. (For eg, Debian is still on Catalyst 5.7 I believe.) Depends which debian you consider the one true version. The debian perl guys++ recently, as they've put in a lot of work to get debian updated to the latest Catalyst and recommended modules. AFAIK 5.80 is still only in 'unstable', but that's still totally reasonable given that 'stable' in debian terms usually translates as 'antideluvian'. :) My own solution was a fourth option: Build your own Perl, and all the required modules, installed into a custom directory - and then ship this with your application. It'll blow the size out by a hundred meg or so, but at least you know it'll work, and it's using known-good versions of CPAN modules. That's totally fair. There's a middle road here of course - if you can standardise on 'an os' at a time, as long as it's not deadrat then 'system perl' isn't so bad (as long as you use Task::Weaken cough)... And with local::lib per-app perl modules are easy to ship around.. And of course you can keep your local::lib in git etc.. So generally personally I tend to try and use the perl which is there, and build per-app CPAN stacks.. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive:
