Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CPAN For Private Code


Published on

This presentation explores the motivations for and benefits from organizing private code into CPAN-style distributions. It was first given to the San Francisco Perl Mongers in February 2010.

Published in: Technology, Art & Photos
  • Dating for everyone is here: ❤❤❤ ❤❤❤
    Are you sure you want to  Yes  No
    Your message goes here
  • Follow the link, new dating source: ❶❶❶ ❶❶❶
    Are you sure you want to  Yes  No
    Your message goes here
  • That's a nice write up. I linked to it on , and I would also like to mirror it there. Would you please license it under an open media licence such as CC-by or CC-by-sa?


    -- Shlomi Fish
    Are you sure you want to  Yes  No
    Your message goes here

CPAN For Private Code

  1. 1. Jeffrey Thalhammer S o f t w a r e S y s t e m s
  2. 2. Using CPAN For Private Code San Francisco Perlmongers February 23, 2010
  3. 3. On The Menu Tonight... Reasons To Create CPAN Distros Case Study: Foo Financial Company Assorted Tools You Can Use
  4. 4. This presentation was originally titled... Why You Should Create CPAN Distros
  5. 5. But it really is about... Why Perl Applications Should Have Build Systems ...and CPAN is just one way to do it.
  6. 6. Well, why?
  7. 7. Organization! Products Distributions Modules Subroutines Statements
  8. 8. A Well-Known Layout A proper place for... scripts libraries tests
  9. 9. Dependency Management Does All The Work Meta-Version Control Detect Circular Dependencies Identify Dependency Flavors: “requires” “build_requires” “configure_requires” “author_requires”
  10. 10. Separation Of Concerns Author-time Build-time Install-time Usernames and Passwords Resource Paths Configuration Stuff
  11. 11. Sharing And Distribution Easy to identify (i.e. named, versioned) Easy to transport (as *.tar.gz files) Well-known install procedure
  12. 12. Tool Chain Support CPAN Module::Build More on this later...
  13. 13. Case Study: Foo Financial Company 500k lines of Perl code 100s of scripts, 100s of modules No automated test cases RCS-like version control Quasi-separate DEV and PROD Deploy by manually copying to PROD
  14. 14. Havoc Ensued Which files need to be deployed? Which versions of the files? How do I role back? What are the parts of this system? How do changes affect other parts?
  15. 15. A Solution: Divide product into Distros. Publish Distros into a private CPAN. Assemble product from private CPAN. Automate everything!
  16. 16. SVN CruiseControl commit trunk/ Foo-Reporting/ checkout $ ./Build Foo-Interfaces/ $ ./Build test Foo-Utilities/ Empty Distro. $ ./Build install Simply depends Foo-Everything/ on other top- $ ./Build dist level Foo::* add & Every modules trunk/CPAN/authors/id/F/FOO/ commit commit Foo-Reporting-8.01.tar.gz Foo-Reporting-8.01.tar.gz produces a Distro with a Foo-Interfaces-2.37.tar.gz new version A private CPAN, containing Foo-Utilities-6.01.tar.gz number everything that Foo-Everything-1.02.tar.gz Foo depends on HTTP GET $ cpan Foo-Everything A temporary location, that will /tmp/lib/perl5/site_perl contain all Foo::* installs modules and Foo/ their non-core Foo/ dependencies Finished product! archives Foo-1.45.tar.gz
  17. 17. Some Tips: At first, put Everything in one fat Distro. But later, may 1000 Distros bloom! Think about how to name & number versions. Create special accounts for automated jobs. Any SCM and build server will do the job. Know your target Perl environment.
  18. 18. Some Supporting Tools CPAN::Mini CPAN::Mini::Inject CPAN::Site Module::Starter Dist::Zilla
  19. 19. Jeffrey Thalhammer S o f t w a r e S y s t e m s