in reply to putting perl and modules in your source code repository

How you're going to do this will largely depend on the infrastructure you have available. For example, we simply installed global perl's in /some_share/$platID, and then have some logic in shell to pick the current platform ID based on uname, etc. However, what we haven't done is automate the building of anything (though I've cried for it).

What I'd prefer seeing is that the perl source was put into its own repository/branch/whatever that we could build on each platform. And that part of this was that we could insert new CPAN tarballs into the mix, and simply rebuild on each platform and reinstall.

In the meantime, since I can't easily add modules to the global perl trees, I simply check in the tarballs to the build, and have make run my preparation script which untars them and runs Makefile.PL/make/make install or Build.PL/build/build install as appropriate to install to the build directory (i.e., a private lib directory). But I'd like to be able to submit it globally, and, using a form of continuous integration, get it applied to the global perls automatically.

As for your last question, "prove" is a good way to determine if a given build of perl is compatible. If the unit tests run clean, it's probably sufficient (assuming adequate unit test coverage). But I'm going to end here before I head into a full-blown rant.

  • Comment on Re: putting perl and modules in your source code repository

Replies are listed 'Best First'.
Re^2: putting perl and modules in your source code repository
by perl5ever (Pilgrim) on Apr 13, 2009 at 20:42 UTC
    One thing I've found that it is extremely important to be able to recreate exactly the same environment. This is useful for deployment, debugging, etc. We've run into too many problems where we see a problem in production that we can't reproduce in development. That's why want to store perl and the modules in the repo. We also have a global perl install, and it's causing too many problems. For one thing, you can't add/modify a module without potentially disrupting someone else's work, and then keeping dev, test and prod in sync is a pain.

    Re: prove... that would be helpful if we had any unit tests. :-)