Here's what bites me and many other CPAN authors: forgetting to list that one dependency. Maybe you think it's core. Maybe you forgot to add a module you threw in at the last moment. Maybe some dumbass named Ovid forgets to take out the call to Data::Dumper::Simple that he threw in there for debugging (yeah, that was embarrassing).
I'm trying to think of the best ways to handle this.
Thoughts?
Re:Virtual servers
Ovid on 2007-07-31T10:43:18
While that sounds like a fantastic idea (I already have Parallels on my MacBook, along with Vista), I suspect it's a bit more than most developers are looking for, or are able to implement. Ease of use is of paramount importance here. If we can get an 80% solution with 20% of the work, that would be a huge win.
Of course, if you want to write the code which automates setting all of this up, I'm sure folks would consider it
:) Re:Virtual servers
Alias on 2007-08-01T04:12:24
qemu debian image with every single Perl pre-installed.:)
Product of the PITA work, comes in handy from time to time.
http://pitatesting.net/guests/x86-linux-debian-sarge-perl.tar.gz
Warning: About 600 meg in size, expands to a 4gig disk image.
Overkill, ok maybe:)
Re:Virtual servers
drhyde on 2007-08-01T12:02:32
I use Parallels virtual machines for smoke-testing CPAN. I'm normally happy to tell people how to get at a guest account on those VMs if they want to test their modules against minimal installs of various versions of perl.So far, I've given access to everyone who's asked. I'd probably only refuse for those very few people who I know abuse community resources. The minimal barrier to entry is that you have to email me to get access.
At the end of every test, report %INC and at the end of the test run, report every module in %INC, which version is was released with and if it's not core, check if it's listed as a dependency.
Perhaps this could be done with a special test target, but I think this is a brillant solution.
Re:I vote for (b)
Ovid on 2007-07-31T10:46:23
I was thinking about a test target, though I'm unsure of how to remotely capture %INC. I'm wondering if it's something that would have to be built into each of the tests?
Now that I stop to think about it, it would be trivial to write a simple Test::More wrapper that Module::Build could load. This would only work with tests which use Test::More, but that would cover the vast majority of them.
Re:I vote for (b)
ddick on 2007-07-31T11:08:09
how could you stop it from reporting the wrong result foreval { require Optional::Module; }
if ($@) {
# we don't have the module, but we can survive without it..
}
Re:Why not list core modules as dependencies?
jjore on 2007-08-02T05:45:36
It breaks stuff to list core modules as dependencies. I forget what. Wish I didn't. Sorry.Yes, there is
GunnarWolf on 2007-08-13T16:14:24
For Debian's dh-make-perl, up to the currently-shipping version, we had a manually specified list of core modules. The problem is, this list changes with time. If you take a look at this commit, you will agree (I hope!) that automatic querying makes much more sense than hard-coding lists.
Re:This is hard.
Aristotle on 2007-07-31T16:33:50
For what version of perl?
I have no idea what compells you to mention PPI in this context.
I think this sort of module would only do good if it had a robust implementation and that is probably very hard.
You think a simple implementation that gets us ¾ of the value of a completely airtight implementation is worthless? Why?
Re:This is hard.
tsee on 2007-07-31T19:41:33
I have no idea what compells you to mention PPI in this context.
That's because you misunderstood me. Given a distribution to be tested, you need to know the minimum perl version it's compatible with to be able to USE Module::CoreList at all. To get a list of core modules, you need a perl version, remember? I mention PPI because it's used to implement Perl::MinimumVersion.
You think a simple implementation that gets us ¾ of the value of a completely airtight implementation is worthless? Why?
Because suppose there is a "Test::Dependencies" which works akin to Test::Pod or so. In that case, spurious failures would mean it's useless. That's the case I was thinking about.
If you implement it as a separate make/Build target so the author can run it if he likes and gets a full report as Ovid or Andy suggested, that may be useful.
Re:This is hard.
Aristotle on 2007-07-31T20:05:26
Given a distribution to be tested, you need to know the minimum perl version it’s compatible with
Ah. I can see that in your previous comment now, but you weren’t quite explicit enough about the point, so I didn’t understand you correctly on first read.
If you implement it as a separate make/Build target
I thought it was a given that checking the dependency list is done before you upload to PAUSE. This sort of test would be useless if it ran after your distro ship had sailed.
Re:This is hard.
drhyde on 2007-08-01T12:07:26
I thought it was a given that checking the dependency list is done before you upload to PAUSE. This sort of test would be useless if it ran after your distro ship had sailed.How touchingly naive
:-) It's amazing how many people don't bother checking. Aside from plain and simple coding errors, undeclared dependencies are one of the most common problems with modules. It's hard to blame the authors though. If you use LWP::UserAgent every day it's hard to remember that it's not core. Even harder to remember is that Storable, for instance, hasn't always been in core and that merely declaring it as a pre-requisite can make your code work on older perls. Re:This is hard.
Aristotle on 2007-08-01T16:54:04
No, what I meant is that I thought it was a given that any automatic depency list checker would be for use before, not after, uploading.
If anyone thought people always checked the list themselves, we wouldn’t even be having this discussion…
Now, doesn't it make you feel stupid...
GunnarWolf on 2007-08-13T16:16:32
To contribute with a post, just to find out you have already done so?:-)
