Re: Best practice for version control of locally installed CPAN modules
I did some experimenting yesterday with CPAN::Mini::Inject and our
Subversion repository:
As many of you know, in the Subversion source control system every
file has a URL - it can be a file:// url, an http:// URL, an svn://
URL, etc.
I think what will work well for us is to use CPAN::Mini::Inject to
put the tar.gz files of CPAN modules into a local CPAN repository,
which happens to be in our Subversion repository. So in our
Subversion repository we could have:
svn://svn.example.com/trunk/CPAN/authors/id/S/SS/SSORICHE/CPAN-
Mini-Inject-0.18.tar.gz
Then we have our local CPAN configuration set to use a CPAN url of
http://svn.example.com/trunk/CPAN
So, the public CPAN modules we use - the specific versions - will be
in our local CPAN mirror, and canb be installed using the standard
CPAN tools - we simply configure them to only know about our local
CPAN mirror. That way module dependencies are managed more easily.
Also, if we create Makefile.PL or Build.PL files for our own local
code when we install our local code using those files the
dependencies will also be taken care of, so one of our local
Makefile.PL might have in it:
'PREREQ_PM' => {
'Our::Cool::Module => '1.03', # locally created
'Test::More' => '.47', # public CPAN module
},
and if Our:Cool::Module happens to depend upon Some::Other::Module
that will
be taken care of.
This approach seems to require that we put CPAN-friendly tar.gz files
of our code in our local CPAN mirror, and that might be OK, but we
could actually also do the following:
- We're installing Module::AAA and it depends on Module::BBB version
1.20
which is not installed, and is also not in our local CPAN mirror,
so the build stops.
- We then have a choice:
- Either install Module::BBB 1.20 manually or
- Make a tar.gz package of Module::BBB 1.20 and inject into our
local mirror.
Re: Trends in Code Quality
On Mar 1, 2006, at 7:36 PM, Kirrily Robert wrote: In my experience developers latch on to test-driven development like a crack habit because once they get into the swing of it, it really is a very effective, stress-reducing way to work. That was one of the really surprising (pleasantly so) things for me - I *feel better* doing TDD, it is actually easier for me in most cases, as well as faster (for me) and more accurate - I write better code. Of course, Your Milage May Vary (YMMV) --- Matisse Enzer <[EMAIL PROTECTED]> http://www.matisse.net/ - http://www.eigenstate.net/
Re: Trends in Code Quality
On Mar 1, 2006, at 12:35 AM, Jeffrey Thalhammer wrote: ... This trend is being driven by a "flight to quality" among software consumers. ... Jeff I think that is a good theory - I mean, it is a testable theory. I hope it is true, but I am not sure. I suggest you interview a few IT managers - come up with a list of 6 questions and ask them to answer in email - I can introduce you to a couple outside of the company you are at now, and I bet other people can to - getting answers from a dozen different IT managers would add useful information. And consider the different environments - small company, large company, fast-moving, slow-moving, etc. --- Matisse Enzer <[EMAIL PROTECTED]> http://www.matisse.net/ - http://www.eigenstate.net/
Re: Trends in Code Quality
Matisse Enzer <[EMAIL PROTECTED]> wrote: > Jeff I think that is a good theory - I mean, it is a testable theory. > I hope it is true, but I am not sure. I suggest you interview a few > IT managers - come up with a list of 6 questions and ask them to > answer in email - I can introduce you to a couple outside of the > company you are at now, and I bet other people can to - getting > answers from a dozen different IT managers would add useful > information. And consider the different environments - small company, > large company, fast-moving, slow-moving, etc. Ooooh, a testable theory! When you do this, can you post the results as Test::Harness output so we can calculate the Kwalitee of the theory? Something like ok 1 - IT Managers like code quality not ok 2 - Programmers are lazy etc... Thanks, Tyler
