On 23 Jun 2009, at 08:59, Tobias Kremer wrote:
These things make the local::lib approach a bit more unappealing for us. For one thing, it appears to be still quite a bit rough around the edges and I doubt that there's anything I personally could do about it because my knowledge there is limited. Secondly, we really would like to have a central repository for our development AND production systems. What proven alternatives are there if you have developers working on OS X, Ubuntu etc. and deploy on a different (Debian) system?
Erm, well, the new --self-contained feature is a little rough round the edges, sure.
local::lib itself just works given what it was originally trying to accomplish.
I think you need a better separation between development and staging. If you're not running something production like in staging, then IMO you're really screwed.
Developers can then use what they like (and whatever OS/versions of modules) they want, if they want to install the app locally, but that's unsupported. I'd also make a 'production like' (i.e. same OS) vmware machine available with the 'standard' dependencies - all of your developers should be given enough horsepower to run vmware, problem solved.
What about CPAN::Mini? At first, it sounds strange to have a whole copy of the CPAN around (although it's not that big), but then again it sounds really cool to just "make installdeps" and have everything installed in the correct version in a cross-platform compatible way.
Yes, you can just point an ftp server at a CPAN::Mini, then set your CPAN shell to use that as your CPAN mirror - it'll just work..
By the way: Would it theoretically be possible to install specific versions of a CPAN distribution? Is there possibly already work underway to achieve this? I think that this would really solve a lot of deployment trouble ...
Erm, it's already practically possible. You just need to ask the CPAN shell for a specific revision.
So, how are you doing your deployment? :) I believe this is an area where there's still a lot of homebrew stuff going on and it would be nice to have one (or 2-3) ways to do it! I'd be willing to write something up for the wiki if there's enough input.
At work I debian package everything. But you're still going to make one package per dependency per platform.
That's a lot of work.. And it totally precludes having different applications with different versions of the same module on the same machine.
I guess this comes down to how many environments you're prepared to 'officially' support, and what your constraints are.
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/
