It’s not only Module::* modules that suffer from *nix bias. I regularly come across interesting modules, only to find that they won’t install on Windows.

And there is the whole Win32::* namespace that doesn't install elsewhere.

I think it is inevitable that there will be platform dependencies.

I also can't blame *nix authors who never use and don't have access to Win32 for not wishing to get involved in porting stuff to that platform; I feel similarly going the other way.

What does bug me somewhat are infrastructural modules -- Module::Build et.al -- that break on Windows because of:

• the use of '*nix tricks', that self-respecting *nix die-hards consider unnecessary and pointless.

  Eg. having multiple files who's names are identical except for case. (Build.pl & build.pl)

  There's no benefit on *nix; and it is guaranteed to break on windows.

• the attempts to re-create *nix shell environments on Windows, in Perl.

  Is using perl -MExtUtils::Command -e cp /some/path/somefile /someother/path/somefile everywhere really better than using copy \some\path\somefile \someother\path\somefile on one platform?

  ExtUtils::Command - utilities to replace common UNIX commands in Makef
  +iles etc.
  The module is used to replace common UNIX commands. In all cases the f
  +unctions work from @ARGV rather than taking arguments. This makes the
  +m easier to deal with in Makefiles. 
  perl -MExtUtils::Command -e cat files... > destination
  perl -MExtUtils::Command -e mv source... destination
  perl -MExtUtils::Command -e cp source... destination
  perl -MExtUtils::Command -e touch files...
  perl -MExtUtils::Command -e rm_f files...
  perl -MExtUtils::Command -e rm_rf directories...
  perl -MExtUtils::Command -e mkpath directories...
  perl -MExtUtils::Command -e eqtime source destination
  perl -MExtUtils::Command -e test_f file
  perl -MExtUtils::Command -e test_d directory
  perl -MExtUtils::Command -e chmod mode files...
  [download]

  And that justifiction...wow!

• Attempts to be 'clever'.

  Example: I don't use the cpan shell; because rather than doing the simple, obvious thing of just using the compiler command:cl -c ... and letting the system (path) mechanism find it (the right one); or fail if it isn't accessible; they decide to do a search for the compiler in a list of "well-known places" -- none of which would be considered well-known by any windows developer -- and when they don't find the compiler in any of those places, they take it upon themselves download and install a compiler. And break my system in the process.

  That's just willful bloody vandalism in my opinion.

• Others, that detailing the few I have has made me so hot under the collar, I better stop :)

My sense is that this problem is slowly getting better (or is that just wishful thinking?)

Dunno. At times in the past it has seemed that things were improving in this regard; but then the prevailing wind changes and they swing again.

Unfortunately, I’ve become dependent on P5U,

Your choice of course; but (from personal experience) you may come to regret becoming dependent upon tools and utilities that do not directly contribute to your applications purpose.

That's not a criticism of p5u per se -- tobyink produces good code and maintains them well.

But generally, there is a fine line between using useful tools when they are effective; and becoming dependent upon those useful -- but not strictly required -- tools, to the point that if they fail, you do.

This is the same difference between a library and a framework.

With a library, if the library fails, or fails to be maintained, or becomes unavailable; you can mock up that library yourself, even if all it does is return hard-coded, known-to-work results in the interim; and your application can continue forward.

With a framework; if it ceases to be usable for any reason, because your application is structured to the requirements and architecture of that framework; it effectively needs to be re-written from scratch. You are locked in to the continued availability and efficacy of the framework; and worse, all of its dependencies.

Add to that the undeniable correlation between: the authors of frameworks; and the propensity to re-use 50% of CPAN in every module they write; and you knowingly sit yourself atop a time-bomb with 57 varieties of trigger all in the hands of a bunch of irreplaceable programmers you don't know and whom are scattered to the four winds, every time you choose to type use Framework::Du::Jour; at the top of your code.

When Moose was framework du jour for a while; I tried to caution its authors against the practices that would make it the ticking time bomb it became. To no avail.

Just beware of installing unnecessary dependencies into your applications and processes.