Almost every day on the Perl groups on LinkedIn (or Facebook, or StackOverflow, or somewhere like that) I see a question that includes the restriction “I do not want to use any modules”.
There was one on LinkedIn yesterday. He wanted to create a MIME message to pass to sendmail, but he didn’t want to install any modules. Because “getting a module installed will have to go though a long long process of approvals”.
And I understand that. I really do. We’ve all seen places where getting new software installed is a problem. But I see that problem as a bug in the development process. A bug that needs to be fixed before anything can get done in a reasonable manner. Here’s what I’ve just written in reply:
Of course it can be achieved without modules. Just create an email in the correct format and pass it to sendmail.
Ah, but what’s the right format? Well, that is (of course) the tricky bit. I have no idea what the correct format is. Oh, I could Google a bit and come up with some ideas. I might even find the RFC that defines the MIME format. And then I’d be able to knock up some code that created something that looked like it would work. But would I be sure that it works? In every case? With all the weird corner-cases that people might throw at it?
This is where CPAN modules come in handy. You’re using someone else’s knowledge. Someone who is (hopefully) an expert in the field. And because modules are used by lots of people, bugs get found and fixed.
A lot of modern Perl programming is about choosing the right set of CPAN modules and plumbing them together. That’s what makes Perl so powerful. That’s what makes Perl programmers so efficient. We’re standing on the shoulders of giants and re-using other people’s code.
If you’re not going to use CPAN then you might as well use shell-scripting or awk.
If you’re in a situation where getting CPAN modules installed is hard, then fixing that problem should be your first priority. Because that’s a big impediment to your Perl programming. And investing time in fixing that will be massively beneficial to you in a very short amount of time.
The obvious solution is to install your own module tree (alongside your own Perl) as part of your application. But that might be overkill in some situations, so you could also consider using the system Perl and asking your sysadmin to install packages from your distribution’s repositories. Of course, that might need a change in process. But it’s a change that is well worth making; a change that will improve your (programming) life immensely.
Update: Some very interesting discussion about this over on Reddit.
Just fix Perl so its not so difficult to deal with this situation. Fix it one, and everyone benefits. The alternative above is many, many people fighting against corporate processes.
I’m not sure there’s a way to fix software so that it magically unbreaks bad local policy. If you have an idea or proposal to do this, I’m all ears. Maybe you’re thinking about something like rbenv? It’s already possible to use a per-application install library and ‘use lib’ to do that.
I find nothing wrong with the ‘perl way’ of using cpan minus:
curl -L http://cpanmin.us | perl – App::cpanminus Some::New::ModuleName
That will drop the module and any requirments into ~/perl5
You can then copy that folder anywhere and when you run your app, just include the library path with the ‘-I’ flag: perl -I /home/user/perl5
If that is still not good enough. Just use fathpacker which will take your app and the requirements and write one giant perl file with all the source…
“The obvious solution is to install your own module tree” – ok, how? In a paranoid corporate environnment.
The easiest way is to use Carton, https://metacpan.org/pod/Carton
OK, I get it, there are ways to make Perl modules work without root via some add-ons (but there’s usually a caveat or two). The thing is, why doesn’t it just work out of the box?
Mu. It already does work out of the box. As mcmahon said above, install modules into a directory that is writable for you (e.g.
./lib) and then add that directory to the search path for modules (e.g.-Icommand line switch).Carton provides some extras like dependency tracking and pinning that are not strictly necessary for that kind of fire-and-forget deployment.
This is a good point. It’s easy now to install modules for your own use (on dev box, hosted server, etc), but actually deploying to production could still be impossible, either practically or politically.
Depending on how code is deployed, something like using local::lib and actually checking in CPAN modules into the source tree may be the only way.
Installing modules for your own locally is easy with local::lib (and the help of cpanm). Carton is needed only if you need to reproduce it reliably… or you can try PAR.
Another point: Even if copying some perl .pm-files to one or another directory is possible… On our production systems, there is (normally) no compiler installed. not even “make”….
And then, installing perl modules is difficult again.
This means you as a programmer regrettably never learnt sysadmin basics. Production systems with as little software as possible are more secure and easier to maintain, eliminating compilers/build environments is a big step towards that goal. The correct procedure to deploy on such a system is to build a native package (e.g. rpm, deb) on a development/build server (which is stupidly easy for Perl software, just one command), and then ship the package to the production system. Visit your local devops user group to get acquainted with industry best practices.
So there’s a few approaches that Perl programmers in the know use for problems like this. Generally if I can avoid system Perl and install an application specific Perl using a tool like plenv or perlbrew, that is what I do. That gives you a lot of bonuses for solving this type of problem and has the big upside that your sysadmin can fully lock down system Perl and just stop worrying about supporting your application.
Even if you must use system Perl, you can still use tools like local::lib (and tools related such as Carton) to manage a locally controller set of libraries for your application.
FWIW this approach is the same one used by Python and Ruby; Perl is not breaking new ground here, so mentioning that to your sysadmins might help.
As a last resort you can take care to only use pure Perl modules and then you don’t need a compiler. You can use a web application builder like Web::Simple and tools like Moo and you can stay 100% pure Perl and never need access or anything special to run or deploy your application (for example you can use Fatpacker to roll up a pure Perl application into one big file and just run it.
Because the community didn’t start off going a great job explaining all these deployment options, you get this ‘I want to use Perl but not CPAN’. That’s not going to get you very far. If you can only use whats out of the box you might need to shop and see if there is a language that has those features in its core libs. Perl is reluctant to add more to core because in the past we adding stuff and turned out to be a mistake. Also many projects would prefer to not be in core because they want to release more frequently than being in core would allow. So if you are going to do meaningful modern Perl work, you need to solve the CPAN problem. There is no way around it. Anything you cook up on your own is going to be trouble for the next person to maintain. I’ve seen this over and over.
Actually, I completely agree with the idea that installing modules from CPAN should be the way to fix things.
But with sl4a and the perl addon for that, you’re actually struck.
So I wanted a little web server to throw a little perl cgi at it (which I wanted to use for learning ancient Greek vocabulary in my cell phone’s browser). Then, there was no web framework in core perl and no way to install modules from CPAN on android.
I ended up implementing a subset of HTTP, plus adding my cgi into the core of that little webserver, not because any company rule disallowed CPAN usage, but because the platform was (and still is) actually broken (in the lack-of-CPAN sense).
In the mean time, someone made it possible to install a debian userland next to android’s which would have fixed that (well… somewhat, to my knowledge still missing the Android.pm part which allows to interact with the phone itself), but that
a) was too late for me
b) eats a lot of space on the phone, especially if you own one with no microSD slot.
So writing my own partial implementation of HTTP rescued me from coding in android’s usual java-like nightmare of a language.
But I also had to fix the problem that android’s font didn’t contain some of the Greek characters with accents, so I had to find a solution to that as well (installing another system font would have required to root the phone which was not possible with my particular device at the time). I ran a little script on my desktop to fix that as well (tell sm to display one character a time using the more complete freefont, then capture a screenshot of the root window, then convert that into a smaller version, remove the 100% white parts at the left and right ends to make the font a proportional one, and replace each Greek character by a little picture of it in the cgi before sending it to the browser).
There you have it. Some platforms are just broken. But fortunately, you can still fix your problems using a more decent language than whatever the platform chose as its default.
I also had this problems: cpan shells not running, unknown HTTP_PROXY and other problems, no compiler.
So I wish to see only “pure perl modules” when searching on metacpan and help installing dependend modules via web browser. Thats why my CPAN modules are pure perl only using core modules.
I used to work in such a place, the reason given was security because anyone can put anything in an opensource module. I eventually convinced them to use the module packaged with the Linux distro because it has been through another level of scrutiny and checking (in theory!). After that it became commonplace to install new modules this way, the first time is always the hardest.
I see the “thumb-up” buttons for Twitter and Facebook. Where are the buttons for “thumb-down,” or another finger?
Wow! This is very interesting. I didn’t know that module selection could become a political issue. With more and more useful modules becoming available in Perl and other programming languages, I imagine such selection processes proffer potential to slow development down to a grinding halt.
A lot of hard work goes into developing many modules, and “re-inventing the wheel” so-to-speak feels wrong since such effort could instead go into adding features to already-existing modules or improving them in other ways.