Re: Pure Perl Modules, XS Modules, what's the current trends?

At the moment, I basically keep good track of what CPAN modules I use and keep them in a app-specific perllib and also say in the dev notes that this is so, and it'd be a good idea to install these modules yourself (a Bundle is used, at the moment)

Actually, Bundles are (and have always been) kind of a dirty hack. The newer trend is toward Task modules, which themselves are implemented using Module::Install. See the docs in Task for a more detailed explaination.

I know of the Best module, but the low version number and long-time-since-hacked-upon date makes me wonder how good it'd work as well.

I have used Best and it is totally stable and production worthy (IMO of course).

Low version numbers don't mean a thing, nor does it matter how long ago something has been hacked on (unless you are talking like +5-6 years, in which case the module may not be in keeping with current community best practices (no, not the Damian's book, the communities best practices, there is a subtle difference). In the case of Best the code is so simple that I would be more worried if there more releases. If you look over the Changes file you will see that most of the releases have been for doc fixes and a few minor bugs which tells me that other people are using this module and that the author cares about clarity of his documentation, both very good signs.

I hope people can understand the importance of having a fall back, pure perl implementation of some of these modules. I do understand that in many instances, these modules are much much slower, but it is better than nothin'.

I disagree with the importance of Pure Perl fallbacks, they are nice to have in some cases, but really, just about every *nix system comes with a C compiler and with the existence of things like Strawberry Perl the Windows platform is becoming less of an issue. IMO, effort is better spent making it easier to compile and install C based extensions then it is spent re-writing these extension in a slower Pure Perl version.

Is there a better method that you guys use?

If you are looking to distribute your code easily without your users needing to install 1/2 of CPAN, then you might want to look into PAR, which is about as close to PHP-ease-of-installation as Perl gets these days.

-stvn

Comment on Re: Pure Perl Modules, XS Modules, what's the current trends?

Replies are listed 'Best First'.
Re^2: Pure Perl Modules, XS Modules, what's the current trends? by skazat (Chaplain) on Dec 20, 2007 at 21:22 UTC
Low version numbers don't mean a thing, nor does it matter how long ago something has been hacked on (unless you are talking like +5-6 years, It is hard to distinguish between Production Ready and not, without signifiers, like version numbers that are above, "1", or something like that. There's always the "Just, because it's on CPAN, doesn't mean it's made of Gold" , idea - but what is? and what isn't? Sometimes it's hard to distinguish. I disagree with the importance of Pure Perl fallbacks, they are nice to have in some cases, but really, just about every nix system comes with a C compiler and with the existence of things like Strawberry Perl the Windows platform is becoming less of an issue. IMO, effort is better spent making it easier to compile and install C based extensions then it is spent re-writing these extension in a slower Pure Perl version. Still, the ecological nitch is that the users don't know how to use CPAN, even if they have it available. I tear out my own hair sometimes when CPAN gets unyieldy. That's not something my users are even going to attempt. If you are looking to distribute your code easily without your users needing to install 1/2 of CPAN, then you might want to look into PAR, which is about as close to PHP-ease-of-installation as Perl gets these days. If I could find an easy enough to use tutorial on how to do exactly that, I would - but the docs on CPAN still read as if I know what the heck I'm already doing. Perl is only user-friendly to Perl hackers, it seems. It's why people use* php. And a app packaged in PAR needs PAR to work! It's a chicken 'n egg thing again. -justin simoni skazat me	[reply]
Re^3: Pure Perl Modules, XS Modules, what's the current trends? by stvn (Monsignor) on Dec 20, 2007 at 21:45 UTC
It is hard to distinguish between Production Ready and not, without signifiers, like version numbers that are above, "1", or something like that. There's always the "Just, because it's on CPAN, doesn't mean it's made of Gold" , idea - but what is? and what isn't? Sometimes it's hard to distinguish. But a version 1.0 or above is no more reliable an indicator, I have seen lots of lumps of crap wrapped up in a bow with a big 1.0 on it and uploaded to CPAN. In the end you have to do things like; 1) ask the community 2) look for indicators like the ones I mentioned in my post (resolved bugs, nicely updated docs, etc) and finally 3) read the code and make your own judgement. In the end, it is open source, so you can always patch it and send the fix to the author, or just fork the whole module and maintain your own version. Still, the ecological nitch is that the users don't know how to use CPAN, even if they have it available. I tear out my own hair sometimes when CPAN gets unyieldy. That's not something my users are even going to attempt. But how is a Pure Perl version of Module::X going to make that any easier? I have had hard times installing Pure Perl modules too, it is not just C/XS based modules that cause issues. If I could find an easy enough to use tutorial on how to do exactly that, I would - but the docs on CPAN still read as if I know what the heck I'm already doing. Perl is only user-friendly to Perl hackers, it seems. It's why people use php. The PAR Tutorial is pretty good actually, and anything you don't understand you can just ask here or on IRC and I am sure you can get people to help you. And a app packaged in PAR needs PAR to work! It's a chicken 'n egg thing again. This is not actually true, you can tell PAR to package it all into a self contained file which only depends on itself. Look in the PAR Tutorial it specifically says "Requires only core Perl to run on the target machine". -stvn	[reply]
Re^4: Pure Perl Modules, XS Modules, what's the current trends? by skazat (Chaplain) on Dec 20, 2007 at 22:45 UTC
I'll try out PAR when I have enough time to give it a good grok. It may not be the best fit for this project, but it would be an interesting thing to have in the toolbox. But how is a Pure Perl version of Module::X going to make that any easier? The Pure Perl versions have an advantage, since you can just bundle them up in a download with, say, (in my case) a webapp that requires it. I can't really do that with an XS module. Of course now, since I'm not using CPAN, all the package goodness is out the window. I'm hoping to move this particular app into a mode where you can install it via `make; make test; make install` if you want (using Module::Install) and if you don't know how to do that, you can just download a prepackaged deal. Currently, you're only choice is the prepackaged deal. Popular with end-users, not so elegant when looked at by Perl Hackers. What to do? -justin simoni skazat me	[reply]