I have a perl program that I want to convert into a bioperl module. How do I do that? Is there an up-to date tutorial? That's really all I need.
Thank you.
For module naming conventions and other information (whether you're writing it for CPAN or not), start with perlnewmod. To make an actual module, first install Module::Starter and use module-starter command line utility to create your skeleton.
Related
How to download the p4.pm(perforce) module for Perl script?
Is it possible to use modules without installing them?
How to download
https://swarm.workshop.perforce.com/projects/p4perl/archives/main.zip
Is it possible to use modules without installing them?
Yes, see blib. What's the point, though? The code has to sit somewhere as a file so that Perl is able to read it, then it might as well be in the intended installation directories so that manipulating the include path becomes unnecessary.
I am working on creating an agent in perl which does several actions. It uses several modules which are in .pm format and also few libraries. Now i want to convert it as one executable file so that i can install in n number of servers by copying that single file. Is it something i can achieve in perl? I am just a beginner in perl, perhaps my question might sound dumb but it will teach me something.
pp script provided with PAR::Packer is able to create single-file executables. An example from its page:
pp -o foo foo.pl bar.pl # Pack 'foo.pl' and 'bar.pl' into 'foo'
Some modules are included with Perl, so even though they're separate modules, they will work on other Perl installs without installing those modules. These include File::Copy, File::Find, Time::Piece.
You can see the listing of all standard modules on the Perldoc home page. Be sure to set the drop down version field (located on the left side) to the version that you're using. It goes all the way back to Perl 5.8.8 which is on Solaris.
It is entirely possible that the modules you need are already included in the standard Perl distribution, so there's no need to worry. Sometimes, you can substitute a non-standard module that's being used for one that's a standard module with little rewriting.
Some modules include compiled C code and can't be redistributed. They must be compiled on the machine they'r running on and installed. However, most modules are pure Perl modules, and can be redistributed with a program.
If a module isn't a standard module, and it's a pure Perl module, there are two ways it can be redistributed:
Perl has an #INC list that says what directories to search for when you search for modules. There's a Perl use lib pragma that allows you to add directories. You could include modules as sub directories for your program, and then zip up the entire structure. Users would unzip the entire directory tree which would include your program and the modules you need. By the way, the default #INC usually includes the current directory.
The other way is to append the modules to your program and then remove the use statement for that module (since it's now part of the file). This is a bit tricky, but it means a single program file.
Just remember that a module might require another module, so check thoroughly.
Another thing you can do is check for the module, and if it isn't there, download it via CPAN. Testing is easy:
BEGIN {
eval {
require My::Module; Module->import( LIST );
};
if ($#) {
die qq(Module doesn't exist);
}
}
Of course, doing a die is sort of silly because use would do that. However, it might be possible instead of dying to load the module via the CPAN module programmer's interface. I've never done that, and I don't know people who have. But, it is possible.
So, your best bet is to check to see if your program uses standard Perl modules, and if not, see if you can modify the program to use them. For example, if your program uses Archive::Zip, you might be able to modify it to use IO::Uncompress::Unzip and IO::Compress::Zip instead.
Otherwise, your choice is to try include those modules for installation (and watch for recursiveness and non-Pure Perl modules) or to try to detect that a module isn't installed, and programmatically install it.
The answer is a bit complicated.
The nature of Perl makes it practically impossible to compile a perl script in most use cases, so that a single executable could be distributed (with executable in the Windows sense). There are ways to do something similar, but sadly I don't know them.
But you can actually embed the Perl interpreter inside any C application, including the Perl source (your scripts + modules). When you statically link all C libraries, this should work as well. You can then use the Perl API to call your scripts.
If all of the servers you target are guaranteed to run the exact same OS, using the exact same libraries, and are preferably a *nix of some sort, it would be possible to pack all required files into an archive and write an install script. It is possible to write self-extracting shell scripts that contain the archive they are about to unpack. Same goes with perl, using the special __DATA__ command and the DATA filehandle:
#!/usr/bin/perl
print for <DATA>;
__DATA__
1
2
3
prints
1
2
3
Works great for piping data to tar as well.
You should include all dependent modules and all compiled libraries into the file and figure out a metadata system to install all files to the correct place.
As a general rule, software should rather be compiled on the target system itself, than just copying the binary files. It is too easy to overlook architecture differencies, configuration files or special registration entries hidden from view.
If you have to target different systems, it might be better to write a script that delegates the bulk of the installation to cpan or whatever perl package manager you prefer. This will be more flexible than hard-coding filepaths.
#!/bin/bash
cpan install Foo::Bar
cpan install Acme
cpan install ...
# etc.
I would stick with that.
The most elegant solution would be to create your own package or distribution like the ones you download from CPAN. As you would include a metadata file referencing all your dependencies, cpan would figure out everything by itself and do possibly neccessary compilation. I don't think this exactly is a beginners topic, but it would give you max flexibility and maintainability (easy upgrades!). This should make it fairly easy to include some installation tests.
This is just for starters, I am sure the internet or somebody else with more knowledge will elaborate.
Hi All,
I have converted the perl script to perl executable using perlcc .So
Now I want to convert perl executable to perl script. Is there any way
to do this...?
No.
I remember compiling my first C program in 1992, cc -o code.c code.c, and then wondering where my source-code disappeared to. (If this is what you did, restore from backups. No backups? Well, think about doing backups.) No, it's not possible. You might be able to work out the algorithm by studying the binary very very carefully, but it's unlikely to help. It would probably be easier to rewrite the application from scratch.
best way to convert perl and all script to exe stand alone file use htwoo project in sourceforge.net
download project link :
http://downloads.sourceforge.net/project/htwoo/Hadi-Kiamarsi-HTWOO-2.rar?r=&ts=1363693006&use_mirror=freefr
download tutorial movie :
http://youtu.be/UQVuFQX4uOo
I am trying to install some Perl modules into a non-standard location, let's call it /non/standard/location. I used
perl Makefile.PL PREFIX=/non/standard/location
make;make install
to install them.
In the script which uses the module, it seems to be necessary to specify a long directory path including the version of Perl, like so:
#!/usr/local/bin/perl
use lib '/non/standard/location/lib/perl5/site_perl/5.8.9/';
use A::B;
Is there any use lib or other statement which I can use which is not so long and verbose, and which does not include the actual version of Perl, in order that I don't have to go back and edit this out of the program if the version of Perl is upgraded?
Probably not addressing all your questions, but do you know local::lib? When it’s available in the system perl, you can just use local::lib. If not:
use lib glob '~/perl5/lib/perl5';
use local::lib;
That’s probably a bit constraining – not sure how it works on Windows –, but it’s good enough for my purposes. Of course, if you can set up the environment before the script runs (.bashrc, SetEnv etc.), you can forget about the use lib glob, as the right path will be already set in PERL5LIB.
Currently I have installed via the following prescription, which seems to fix things.
perl Makefile.PL --no-manpages --skipdeps PREFIX=/non/system/location INSTALLSITELIB=/non/system/location/lib INSTALLSITEBIN=/non/system/location/bin INSTALLMAN1DIR=/non/system/location/man/man1 INSTALLMAN3DIR=/non/system/location/man/man3
I welcome any constructive criticism of this. I want to use --no-manpages but the INSTALLMAN1DIR seems to be necessary anyway.
I inherited a project which is supposed to be able to be deployed to other servers. This project has a number of simple module dependencies which however might not be present on all target machines.
As such I'd like to be able to run a single command line script that checks which Perl modules are installed and tries to automatically install missing ones via CPAN.
Since this should be very basic (i.e. needing to install stuff to run the module installer would defeat the point) said script should only use Perl 5.8.8 core modules.
Does something like that exist already or would i need to write it myself?
Creating a Bundle package is one possible answer.
You can then look at something like CPAN::Shell (see CPAN module) to automate the process.
/I3az/
Update re: brian's comment about Task:: - Here are some pertinent links:
Writing a CPAN Task (using Module::Install)
"Task:: or Bundle::"? (Perlmonks)
Use Module::Install, it will be bundled with your module/program. You can use "auto_install" command to automatically install dependencies.