I'm in the process of putting together a portable build of Perl based on the fully open source Strawberry Perl distribution. The intention of this is for it to be placed in CommonFiles for use by other portable apps, like portablized Java is now.
Here's a little background on how strawberry perl is set up followed by my opinions on how to proceed:
Strawberry perl includes not only perl, but enough of MinGW to also compile CPAN modules. This makes it work nearly exactly like every other version of Perl out there except ActivePerl. ActivePerl's method of dealing with modules is to instead include a package manager which downloads pre-compiled modules from known repositories instead of compiling as needed. Both methods have pros and cons. Compiling isn't for the meek, but pre-compiled packages means you're waiting on someone else to do the work for you. Of course ActivePerl isn't open source so we can't include it (yet..) but we probably shouldn't actively preclude it from working either.
The way Strawberry perl is set up to handle this with a folder structure like this:
+--Strawberry
+--c (MinGW files)
+--CPAN (CPAN sources and build folders)
+--Perl (traditional Perl folder)
+-- bin (binaries)
+-- lib (libraries)
+-- site (modules)
This is vs ActivePerl's structure:
+--Perl
+--bin (binaries)
+--lib (libraries)
+--site (modules)
+--(other AP specific folders not used when running scripts)
The two Perl folders are interchangeable, and are all that are required to run perl scripts. As long as you have the required modules in each, you can use either to run perl scripts. My thought is that for Portable perl using Strawberry perl we should probably only include the Perl folder. This would allow us to standardize on CommonFiles\Perl in Portable Apps that require Perl, and users could either use our package or drop in ActivePerl if they like. Unfortunately this method precludes using Portable (strawberry) Perl fully to compile new modules.
One other thing to consider is size.. The Perl folder is 36MB, or about 31 when compressed. The entire strawberry distribution is over 120MB...
Anyone want to chime in with their opinion, or have a better idea?
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
There is a portable perl distribution already. It's called tinyperl. Takes just 750 KB.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
Unfortunately Tinyperl comes with very few Modules and no way to get more. Any serious Perl distribution needs access to CPAN modules, which Strawberry Perl provides. Also Tinyperl has not been maintained since 2003 and does not include the newest Perl release, 5.10.
formerly rayven01
Readme says:
* You can create your own lib.zip file. Just get a normal Lib, cut what you don't need and compress it with ZIP! See LibZip module for more!
So you can use all CPAN modules.
Even though it never caused me any problems, I definitely agree that lack of maintenance is a big problem.
I think that if you recompiled tinyperl with current binaries, you'd do much better job than making a 120 MB (actually probably even more on drive) monster that's huge overkill for 99% user.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
Are you trying to package up Perl as a full-blown language for users to work in, creating their own custom scripts, pulling down and building cpan modules, etc.
Or, are you trying to build a useful Perl implementation in common files that other Portable Apps can use as a perl interpreter, including, if they need to, dropping their own pre-built modules into the well-known directory tree.
Even if you use the cut-down Strawberry Perl, there is nothing to stop developers (or users who are developing) from having their own installation separate to the one in common files, which they can use for building new CPAN stuff, and then drop the ready-built files into the common files area.
Final question is how practical would it be to have something like
+--CommonFiles +--Perl +--bin +--lib +--site +--devtools +--c +--CPANOr would that completely kill Strawberry?
That's the question, really.. do we need both or can we get along with just Perl. Your final question brings up a good point though. I'm investigating that now. If it's possible, I would more than likely split it out even further though, like:
+--CommonFiles +--Perl +--bin +--lib +--site +--PortablePerl +--App +--Strawberry +--c +--CPAN +--PortablePerl.exe (launcher for a cmd shell with correct env variables for development)With this method I'd use the Multi installer to add an option whether to include the full development tools in the PortablePerl folder or just the CommonFiles\Perl.
formerly rayven01
I even typed it up in that form and then edited it, because I was at a loss to think of what "application" would be installed in the PerlPortable directory, since there isn't really one that applies to a language interpreter
The idea of a command prompt with its EVs set up right is an excellent one.
Personally, I'd favour that, with the multi-installer.
You might not want to have dependencies on other applications, but I'd recommend doing the CLI support via Command Prompt Portable.
IMO this directory structure would be confusing for most perl users.
Keeping consistent directory structure over all PA.com apps is good, especially when you start with app that you don't know. But nobody's gonna learn Perl just because it's portable...
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
This is a case where it's a tradeoff. If things are kept "easy" and all thrown in CommonFiles\Perl (Jimbo's first post) then you lose compatibility with PAF backup programs that backup data, interoperability the PAM menu, etc since everything in CommonFiles is ignored. If you split it up then you gain compatibility with those features and it makes it easier to explain things to non-developers. For instance I can see this being used by non-developers when they need to install a new CPAN module for use with a portable app. Clear concise directions (or even a perl script) could be provided if the PortablePerl.exe cmd shell launcher was available from the menu, whereas otherwise the directions would include having to delve into the directory structure of CommonFiles to do the same. Personally I think it's better to cater to casual users. Developers are going to have a much easier time making things work how they want since they're generally more technically inclined to begin with.
As for Command Prompt Portable if I do this I would definitely add a check for that, and probably Console Portable as well with an ini option to set the default.
formerly rayven01
I wasn't aware that there are programs relying on PAF directory structure. Now I agree that you should try to make it PAF compatible.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
you lose compatibility with PAF backup programs
I don't use the suite, but I thought that the backup utility only backed up the contents of the Data folders. The stuff for installing modules would be part of the application -- no reason to back it up since you can just reinstall. Unless you want to backup user installed modules (i.e. Perl/site/lib).
While I think that making things easy for casual users is a laudable goal, I'm not sure that it's worth the effort. I wouldn't expect many non-programmer types to be installing portable Perl, much less modules from CPAN. Non-techies can manage (the GUI version of) PPM but they'll be lost at a command line.