views:

264

answers:

3

Recently I read a blog post saying that it is a good practice to develop Perl applications just as you would develop a CPAN module. (Here it is – thanks David!) One of the reasons given was that you could simply run cpan . in the project dir to install all the dependencies. This sounds reasonable, and I also like the “uniform interface” that you get. When you come across such an application, you know what the makefile does etc. What are other advantages and disadvantages to this approach?


Update: Thanks for the answers. I’ve got one more question about the dependency installing, I’ll post it separately.

A: 

publishing things to CPAN mean responsibility. you need provide a good document, further supporting and others. or else, don't go CPAN.

Thanks

Fayland Lam
Actually publishing the code to CPAN wasn't what was asked - "good practice to develop Perl applications just as you would develop a CPAN module" doesn't imply that you actually release it to CPAN, just that you develop in the same way as you would for a module you were planning to release to CPAN.
David Precious
You mean, if you don't publish to CPAN, you don't need to provide a good document or support your code?
brian d foy
He is just bitter that someone on IRC didn't like his use of the MooseX:: namespace.
jrockway
+10  A: 

Generally, yes, I'd say it's a good idea. Catalyst makes this easy, as the catalyst.pl helper script will set up a basic framework for your web app, completed with a Makefile.PL etc.

This means that packaging your application and deploying it to a server is trivially easy.

Edit: I think the original blog post you were thinking of was Write your code like it's going on CPAN from Perlbuzz.

"By treating code we were never going to release to CPAN as if we were, we win the support of all of the CPAN toolchain. A toolchain that is getting better every day."

David Precious
+6  A: 

Yes, simply because "CPAN module" only establishes very liberal practices. I prefer Module::Install, I believe most sane people should too. To get a basic distribution running with module install I simply use module-starter:

module-starter --mi --module "Foo::Bar" --author "Evan Carroll" --email "[email protected]"

Then right after, I edit the pod in lib/Foo/Bar.pm: I don't like pod in the middle of my code. I typically move it all to the bottom and delete the FUNCTION, and VERSION section too, because 99.9% of my modules are OO with Moose, and Module::Install will read it from $Foo::Bar::VERSION.

Then I run git-init, edit the .gitignore file and add 'MANIFEST', 'Meta.yml', 'Makefile.old', 'blib/', 'inc/', and what ever temp files the editor I'm creating might be using. (If you're pushing to CPAN you'll want to add the .gitignore, and .git/ to MANIFEST.skip that way they don't go up too.) Then I git add ., and I've got my module in git with a bootstrapped build/test system.

Then I run github, create a repo, upload my module, and add the public repository to Makefile.PL repository git://github.... and start coding.

Even if you don't push to CPAN, module-install provides a pretty good foundation for a good module.

Other advantages, you can run make dist, and get a tarball and host it very easily on a private http server, and then simply tell a client or a server to install with cpanp http://host/path. You also get all of the advantages of Module::Install, it will use dmake on windows, and download dmake if you don't have it. It is pretty magical with cross platform goodness.

There are no major disadvantages, or even note-worthy minor ones.

Evan Carroll
Have you tried Dist::Zilla?
brunov