I work in a project that uses Perl scripts on machines that are maintained by system folks, and installing packages such as Perl modules is no easy task - you usually have to call the person with the permissions to do that, wait several days, learn the API of the package, and then remember to install it on every newly configured machine ever installed.
The alternative that is many times chosen is just calling system() (or backtick notation, ``, inside Perl) and using the output of the shell command that does what you want. Of course it's not always possible, and when it use, there is usually a wrapping to do around the command call, but it's generally easier.
My question is when is the trade-off pulling towards either side, in your experience?
Edit: adding an example:
I want to print the total size of a directory in a human-readable format, or list all regular files bigger than a certain size, and du seems to make this easier than installing modules that do the same thing...
Oh, that's an easy one. One always prefers modules because the tighter integration makes it possible to pass around data that do not suit the traditional IPC.
What, did you expect help in rationalising your suffering under crappy sysadminship?
The core issue seems to be the perceived difficulty and length of time to install Perl modules. I would identify why they have problems installing the packages and try and help streamline their process.
A common solution is to modify your process. Admins don't typically like to install straight from CPAN, but as a developer you can use a local CPAN repo. You "freeze" the packages you use there, and then promote them for use in production.
That said the trade-off between using modules or shelling it out as follows:
Data
Modules typically return structured data, shelling out returns unstructured text that you have to parse.
Performance/Resource Usage
Shelling out creates a whole other process, modules usually provide functionality within the current operating process.
Additional Dependencies
Shelling out makes your program dependent on whatever you're shelling out to. Keep in mind that some basic programs change in output and behavior from OS to OS, so you may also be coupling yourself to a particular OS or set of OSes.
Modules, always modules. And, when I say always, I mean "almost always."
Modules are easier to control and to debug. It's easier to require a module be installed than some unrelated utility. It's more portable to use a module than to rely on the chancy command line syntax of a particular command.
You have a bunch of modules that go with the core distro. Just use them.
You can install modules right in your home directory and when the time comes negotiate with the sysadmins: http://perl.jonallen.info/writing/articles/install-perl-modules-without-root
As said above, always modules, because ls ain't dir...
Related
Problem:
I am using a lot of CPAN modules and hard-coded perl functions in many different scripts (a lot of which is duplicated), and I want to make my code base DRY (don't repeat yourself) by extracting all of the common code (and maybe even by some refactoring), both own and cpan code into a common module and use that across my scripts, so that I need to change the code only one place when changes occur (they do).
So I want to ask you whether you are sitting on some functions you have implemented during your perl career that you would put permanently into such a common module so that when writing new scripts, you would only need to write code specific to the core functionality of the script, and use the common module for rest of the code.
Don't refactor CPAN Modules. Treat these as mystery boxes. If there's an issue of using multiple cpan modules that do more or less the same work, standardize on one.
I have a bunch of local Perl modules which I put in the Local namespace. For example, Local::WinAD to access and manipulate our active directory. This Local namespace will never be used by CPAN. It's stored in our version control system as a project, and can be checked out and installed on any system. You can use the use lib pragma.
If you do modules, do them right. Use #EXPORT_OK and not #EXPORT. (Or, even better, make them object oriented modules). Use POD documentation and do extensive unit testing via the Test::Simple and the Test::More modules.
Pretend you'll be submitting them to CPAN.
And, also search CPAN very carefully to make sure that you're not duplicating already done work. After all, you want to practice DRY which includes not redoing work already done for you by CPAN.
Does anyone know of a scripting language that's included with most platforms (say Mac/Windows/Linux)? I haven't been able to find one. So far javascript in web browsers or compiled java are about it. Jython comes close.
My goal is to be able to download a file from the web or portable storage and just run it, without having to install something first, or have special user permissions, or edit it, or rename it, or give it executable privilages. It would give you access to generally accepted metaphors in computing: input, output, persistent storage, time, spawning tasks, sockets, fixed and floating point math, unicode, etc. Ideally it would abstract away minutia like line endings, endianness, and yielding for other processes.
I don't want to get into why having a universal language/virtual machine is important, or at the very least, useful. I feel that we are missing a middleware above the operating system level, something like POSIX but less esoteric, and without it, we all are forced to spend a disproportionate amount of time reinventing the wheel or writing special cases. For me, availability and a complete feature set are more important than speed (which could come later).
Thanks in advance for any insights you can provide,
Zack Morris
You will be able to run carefully written sh scripts on almost all unix systems.
If you want to add Microsoft systems, then it is more difficult, but still possible to provide a single script file, that will "autodetect" the interpreter it's running on and select between a sh part and a command.com or whatever they have on Microsoft systems.
Once you can run a script on a known system you can further download or unpack and install automatically whatever software you need.
I'm looking for the right GPG Perl module to use for a small project. I see there are numerous competing modules providing almost identical functionality, but some have a slew of unaddressed bugs, haven't received an update in half a decade, etc. Is there a GPG module one should always use, or do I just need to bite the bullet and assess which is the best for my needs and whose bugs will have the least impact?
I recently used Ruby's GPGME module to do some pretty cool stuff with GPG. GPGME is a C library, and various people have ported it to other scripting languages. I'd try out the following one and see if it works for you. It should function as if you're writing a native GPGME-linked C program.
Crypt::GpgME
Cheers!
This is more of a use-case type of question... but also generic enough to be more broadly applicable:
In short, I'm working on a module that's more or less a command-line wrapper; OO naturally. Without going into too many details (unless someone wants them), there isn't a crazy amount of complexity to the system, but it did feel natural to have three or four objects in this framework. Finally, it's an open source thing I'll put out there, rather than a module with a few developers in the same firm working on it.
First I implemented the OO using Class::Std, because Perl Best Practices (Conway, 2005) made a good argument for why to use inside-out objects. Full control over what attributes get accessed and so on, proper encapsulation, etc. Also his design is surprisingly simple and clever.
I liked it, but then noticed that no one really uses this; in fact it seems Conway himself doesn't really recommend this anymore?
So I moved to everyone's favorite, Moose. It's easy to use, although way way overkill feature-wise for what I want to do. The big, major downside is: it's got a slew of module dependencies that force users of my module to download them all. A minor downside is it's got way more functionality than I really need.
What are recommendations? Inconvenience fellow developers by forcing them to use a possibly-obsolete module, or force every user of the module to download Moose and all its dependencies?
Is there a third option for a proper Perl OO framework that's popular but neither of these two?
To be perfectly fair, seeing virtually everything interesting these days in Perl world has Moose somewhere as a dependency, I don't see it being much a debt for other "fellow Perl developers".
Chances are they already have it installed as we speak!
Edit: Some statistics:
Moose is currently rated at 65th place on the "Most Depended on" modules list, Aliases top 100, with over 1637 packages depending on it. Thats almost as much as stuff like Time::HiRes , and more than DBI, and I don't think you're as likely to question depending on those would you?
The currently accepted "modern Perl OO framework" is Moose. I'd say make your users download it, or you can bundle it up with your modules in the installation using PAR::Packer.
Quoting from "But I can't use CPAN" (...because my users won't want to install things):
Assuming you're just handling your users a tarball, then Module::Install provides a solution - if you put your script into script/ and then do
install_script(glob 'script/*');
auto_install;
in your Makefile.PL, then not only will 'make install' put your script somewhere useful for you but 'make installdeps' will invoke cpan (or if present, cpanplus) to install all missing dependencies for you.
Well, there's Mouse, which is like Moose but without all the dependencies (and some of the features). It also starts up a bit faster. I haven't tried it myself, but it's generally well thought of.
To add to the existing fine answers...
Some of what was recommended in PBP isn't bad advice, but Perl marches on. When it was written, inside-out objects were the new hotness. Now the Moose has absorbed all. There is MooseX::InsideOut which gives you the power of Moose with the total encapsulation of Class::Std, but unless you work with undisciplined programmers its really not necessary.
Those features of Moose you don't need now, you'll need them eventually. Even if you don't need all of them, with Moose you won't have to use and learn Yet Another OO System every time you need an interesting feature. And god forbid you need TWO features at the SAME TIME!
There is also a Perl Module Object::InsideOut , actively maintained as of 2010.
Kind of a predecessor to Moose, or to be clear: development started independently at the same time as Moose started,
I know it exists but I haven't used it.
What are the disadvantages of the Tk module compared to other solutions to create a GUI in Perl?
I toured the various gui modules for Perl recently, and here is my summary (disclaimer: ultimately I found that none of the existing modules met my needs so I started writing my own gui toolkit).
Tk - Decent to work with and the interface is very perlish. The gui itself is a bit dated looking, and doesnt take advantage of any of the operating system's native widgets (like filepickers). On most systems it will require a C compiler to install.
Wx - Difficult to work with, un-perlish interface. Large programs almost require a gui builder to keep track of everything. Support for os level widgets is mixed. Nicer looking than Tk IMO. Compilation is involved, requires installing several libraries, can be difficult to get running on windows. The assembly of programs is very procedural, and does not map cleanly to what the program will actually look like.
Qt - last I looked this module was more or less abandoned and only supports Qt3. I didn't try to install it, but i imagine it needs a compiler.
Prima - Similar to Tk it has a dated appearance. Requires a compiler.
W32::GUI - I ruled this out early since it is not cross platform.
XUL::Node / POE::XUL::Node - rather heavy dependency tree that includes C code. Seems unmaintained and I had mixed experiences getting it to install. Windows was a no go, OSX was a no go, it had limited functionality on OpenSUSE. It also only supports a subset of the XUL language.
I found that none of the existing gui toolkits made it easy enough to distribute your application to end users. It is ok to expect programmers to jump through the hoops of resolving library dependencies and compiling code, but end users aren't going to do that. So the first requirement I had was to be pure Perl.
Secondly, nearly all of the existing gui toolkits force you to work in a very procedural manner: Create a container. Create a packer for the container. Create an object. Set properties on that object. Add the object to the packer. Run the packer to fill the container object. Repeat.
Instead, I find that nested design (like HTML) is easier to follow for two reasons. First off, since objects are nested, there is no need to name everything (label_456, label_457...). Secondly, the structure of the program mirrors the structure of what is displayed.
So I started work on XUL::Gui, and its been coming along rather well. It is pure Perl, and only depends on core modules for ease of installation. It has one external requirement, which is that a recent (3+) copy of Firefox is installed. It uses the familiar design pattern of web development with nested tags styled with CSS. It is certainly at a level where you could write fully featured single window applications with it.
Hopefully this helps you to figure out which toolkit is best for your project.
Tk has not been developed in a very long time. ActiveState now recommends development with their Tkx toolkit, which provides a thin layer over TclTk. It means that themed widgets are possible. But, TclTk is still quite primitive compared with many other GUI toolkits.
I haven't tried XUL:Gui but it seems the way to go.