|
dragonchild has asked for the wisdom of the Perl Monks concerning the following question:
In the CB, Intrepid brought up a discussion about PPM and Makefile.PL's that have core modules as prerequisites. He indicated that there was an issue with PPM that broke installations.
Now, I don't use PPM as I'm a Unix developer, but my questions to the Perl community would be:
- Is this the case? If so, on what PPM versions? What OSes? How reproducible? Are there bug reports about this?
- Is there an easy patch? If so, has anyone offered it to the maintainers of PPM? Who is that, anyways?
- Is there an easy way to detect if PPM is installing my module as opposed to CPAN or commandline?
- Should module authors take any action on this topic? If so, what should that action be?
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
|
Re: PPM and core modules
by bart (Canon) on Dec 21, 2004 at 16:22 UTC
|
I've had a problem with it, yes, when I tried to install Data::Dump::Streamer from PodMaster's repository. It insisted on reinstalling Data::Dumper, the same version I had installed, even. At least part of the problem would appear to be PPM's differentiating between "::" and "-", which is common in distribution names. PodMaster's PPD file specifies
<DEPENDENCY NAME="Data-Dumper" VERSION="2,121,0,0" />
thus with a hyphen.
I'm not sure that's the only problem, as PPM might be checking only the list of additionally installed modules. Might. I'd have to investigate this further.
Just my 2 cents... At least now you know of a specific case of an occurring problem. | [reply]
[d/l] |
|
|
Which version of ppm do you have? That sounds like a bug that's been fixed.
| [reply] |
Re: PPM and core modules
by DaWolf (Curate) on Dec 21, 2004 at 16:59 UTC
|
Let me tell you what I know (wich is not much {grin}):
- PPM is maintained by ActiveState.
- AFAIK - at least on Windows plataforms - PPM explicitly install packages from a list of pre-registered repositories. Since it uses it's own file format (.ppd), you can't install modules directly from CPAN, since the majority of them (the ones I've seen at least) are distributed in another format (the well known extract-configure-make-make install routine).
- There are some CPAN cases (specially Win32 modules) where the author gently posts a URL where you can download the .ppd file.
Regards,
| [reply] |
Re: PPM and core modules
by KeighleHawk (Scribe) on Dec 21, 2004 at 20:06 UTC
|
PPM is a CPAN like sorta replacement created by ActiveState. It's original intent (I assume) was to address the needs of Win32 users who commonly did not have a C/C++ compiler installed and therefore could not easily (or at all) install Perl modules that contained C/C++ modules that needed compiled. ActiveState would provide a pre-compiled copy of the needed files and PPM could slap them in place.
As far as I know, there is no way to know what modules are installed or how they are installed expect by possibly inspecting any artifacts that may be left over from the installation process.
I too have stomped on a good installation with a bad via PPM. It was simple enough to correct (re-install the original) so I did not explore it further. I don't recall at the moment if I ever did the same with cpan.
As for what to do about it? Not much. At this time, the "standard" distribution for Perl modules is CPAN. PPM is going to mostly be of interest to Win32 users/developers. However, ActiveState has since expanded it's efforts to include Linux, Solaris and HP/UX.
One might see the possibility of a convergance of PPM and CPAN but I would not expect that anytime soon since there is still a basic philosophy difference that distinguishes thier audiences (ie. compile your own, or download binaries only).
Some would argue that PPM has no use for pure Perl modules becuase you don't need to compile anything. However, PPM does offer (again mostly Win32 users) a complete package for accessing remote module repositories and installing from them. CPAN on Win32 can be a bit of a bugger to get working since, like many Open Source initiatives, it relies on other software to be installed to work (ftp, gcc, make, various unix utils, etc.) Most of these are already present on a standard UNIX installation but **not** a Win32 installation. Unfortunatly, ActvieState does not seem to be very automated, nor very religious about insuring thier repository is either complete or current which is somewhat disappointing.
As for setting up a Cygwin environment all I can say is, Cygwin "grates" on some, especially Win32 users and people tend to love or hate it.
I would guess, but don't feel like looking, that Active State uses PPM for it's other scripting language ports as well.
So generally speaking I would say, PPM will exist to encourage/support usage by developers who do not want or need to otherwise setup a complete "Open Source/UNIX" developement environment but would rather download, install and maintain a binary only development environment for a single development language (eg. Perl). CPAN will continue to be the "source of record" and the source for it's main audience, Open Source UNIX developers who generally speaking already have the required tools in place to automatically roll thier own with each installation.
Perhaps in the future, ActiveState will do a better job of keeping thier repository more in sync with CPAN and so make the issue less of a concern...
| [reply] |
Re: PPM and core modules
by hsmyers (Canon) on Dec 21, 2004 at 17:00 UTC
|
I think that PPM is ActiveState's to maintain. And if I understand your third point, PPM installs from the repository that it is pointed at, so at a guess it would be neither CPAN or 'your' module but rather the one from the designated source. Generally speaking PPM shouldn't be a particular concern for authors, instead the maintainers of PPM should be concerned about the modules the authors have written.
--hsm
"Never try to teach a pig to sing...it wastes your time and it annoys the pig."
| [reply] |
Re: PPM and core modules
by BravoTwoZero (Scribe) on Dec 22, 2004 at 03:00 UTC
|
Hey, I'll cop to working with Activestate Perl on Windows! I've installed a number of modules, both with Makefile.PL/nmake and with PPM. While I haven't hosed an otherwise working install with a muffed PPD dependency, I'm sure it's possible. That's an essential problem with package-based installs, IMHO.
I have found that, with PPM3 and Activestate Perl 5.6 (so my Win32::AdminMisc PPD installs cleanly... it's more for the sanity of the other NT admins), I have had no issues. But, as long as I'm installing PPDs, I'm at the mercy of the maintainers. Cygwin isn't a bad option, either. It's just not the one I use in production for Perl on Win32. Ditto the non-Activestate Perl for Win32.
As for the purpose of PPM, I think Activestate was hoping for adoption of PPDs across the OS landscape. They've had a Redhat install for a long time, though I've never even been slightly tempted to try it. It's not an awful idea (after all, I use it... I use RPMs, too, usually with Apt for RPM... maybe I'm more of a devotee of packages than I think ;), but in an ideal world, I'd nmake every module on every system.
Is there an easy way to detect PPM vs. CPAN? Sure. You'll be calling the PPM utility to install PPDs. Otherwise, at least on a non-Cygwin Win32 system, you probably aren't using CPAN. You might be, by Hanky, because we're a resourceful lot. But the odds are against it. So, at least there's no ambiguity.
Should module authors take action? As mentioned before, PPM is Activestate's deal. If you're Dave Roth, Jenda Krynicky, Jens Helberg or another of many good Win32 module builders, you're probably rolling your own PPD anyway. It would be great if all modules worked on Win32, but that isn't practical. I'd say modules directed at Win32 targets should consider PPD building, but I'm just as happy that they build good, useful modules.
On that note, thanks to everyone who has ever developed a module. I may not have used it (or used it well), but I owe you anyway!
Amatuers discuss tactics. Professionals discuss logistics.
And... my cat's breath smells like cat food.
| [reply] |
Re: PPM and core modules
by PodMaster (Abbot) on Dec 22, 2004 at 08:23 UTC
|
He indicated that there was an issue with PPM that broke installations.
Thats vague, but AFAIK (and I'd like to think I know), there is no issue with core module prerequisites.
Is there an easy way to detect if PPM is installing my module as opposed to CPAN or commandline?
No, however there may be ways to detect if ppm installed your module (perldoc ppm), or rather I should say your distribution.
Should module authors take any action on this topic? If so, what should that action be?
I have a feeling the answer is no.
| MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!" | | I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README). | | ** The third rule of perl club is a statement of fact: pod is sexy. |
| [reply] |
|
|
