|
in reply to Installing Module::Info 0.35 for Strawberry Perl 5.22.0
Note that the Win32 module is reported as being used on line 624 of file Bar.pm. Not only does that file contain no mention of Win32; but it’s only 24 lines long! How does the call find an unmentioned module on a non-existent line of code?
Win32.pm is an unusual module. It doesn't need to be loaded, to be used: C:\test>perl -E"say Win32::GetOSVersion();"
Service Pack 16060012107681
It is effectively demand-loaded. And that is probably the source of the problem. At some point in the process of loading the used modules, Win32 get demand loaded in order to satisfy some requirement of one of those used modules; and in the process, Win32 gets added to %INC.
Module::Info detects the presence/addition of Win32 and throws its hands up in horror.
If its purpose is to check that a certain set of required modules can be loaded -- a pointless test as they would be detected and clearly flagged by the standard Perl mechanisms anyway -- but if that is its purpose, it should stick to doing that. And only that.
There is no sense in calling foul because an extra module is loaded. That is none of its business with respect to its defined purpose.
Module::Info, like so many of the modules in the Module::* namespace is developed by *nix programmer without reference to, or concern for, anything outside that platform. Also, like so many of them, it is "testing" something that it is pointless to test. Something that if it failed, Perl's standard error reporting mechanisms would detect and report anyway; and in a far clearer and more usable fashion.
The best solution -- and I do mean best; not simplest or most convenient -- would be to disable all the tests that are dependent upon Module::Info; and refuse to allow it on your systems. It does things it shouldn't do.
|
Re^2: Installing Module::Info 0.35 for Strawberry Perl 5.22.0
by Athanasius (Archbishop) on Jun 28, 2015 at 16:38 UTC
|
Hello BrowserUk,
Thanks, that’s very helpful. I didn’t realise that Win32 is a “magic” module — that explains a great deal.
Module::Info, like so many of the modules in the Module::* namespace is developed by *nix programmer without reference to, or concern, for anything outside that platform.
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. :-( My sense is that this problem is slowly getting better (or is that just wishful thinking?)
The best solution ... would be to disable all the tests that are dependent upon Module::Info; and refuse to allow it on your systems.
Unfortunately, I’ve become dependent on P5U, so I think I’m going to have to let Module::Info come along for the ride. But your information makes me feel much more comfortable about the prospect of by-passing the failing tests.
Thanks again!
| [reply]
[d/l]
[select] |
|
|
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...
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.
| [reply]
[d/l]
[select] |
|
|
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
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l]
[select] |
|
|
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?
| [reply] |
|
|
