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.

I didn’t realise that Win32 is a “magic” module — that explains a great deal.

Unfortunately, that's only half of the story.

Win32 ports of Perl implemented some functions in core, but in the namespace Win32, so they were available without having to load the Win32 module, and without loading the module. Other functions were implemented only in the Win32 module and were available only after that module had been loaded.

That's not very clean, but at least it was documented by marking all in-core functions with [CORE] in the documentation of the Win32 module.

Now (and that's new to me, too, just reading the documentation Win32CORE and Win32), the functions marked with [CORE] are no longer in-core, they are replaced with stubs that implicitly load the Win32 module.

I don't think the stubs are much cleaner than having the functions in core. But at least it allows to update the Win32 code independant from perl. I would have prefered extending the heuristics for "(perhaps you forgot to load "%s"?)" to detect when a [CORE] function was called without having loaded the Win32 module. This way, perl -E "say Win32::OSVersion()" would result in the error message "Undefined subroutine &Win32::OSVersion called (perhaps you forgot to load "Win32"?)  at -e line 1." instead of just "Undefined subroutine &Win32::OSVersion called at -e line 1.". But that would have caused badly written old scripts to complain or crash, and as we all know, that's a no-go for new perl versions. Well, except for given/when and the smartmatch operator.

The difference between Win32 [CORE] and Win32 non-[CORE] functions never made sense for me. Win32::BuildNumber() is specific for ActiveState Perl and is by definition not portable, not even to other Win32 ports. All other functions could be in an external XS module, as they are mostly thin wrappers for Win32 API calls.

Alexander

Unfortunately, that's only half of the story.

That sounds like you are attributing the failure to install a module, because of the failure of a second module, on the existence of a 3rd module, that isn't used by either of the first two?

And despite the fact that the first module installs & runs perfectly, if you remove the second module from the picture. How can you hold the third module responsible?

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!