Perl modules, was: Re^11: Begginer's question: If loops one after the other. Is that code correct?

[predrag]

Hi Hauke D,

I've partially changed the title of this node but am not sure if that is ok? Probably I had to change it once before, when new question about converting to Cyrillic appeared but I wasn't sure if I could do that the right way. I wonder if it is possible to do now and if yes, should I do that?

Thanks for the links. I would like to learn CGI scripting later this year and it is very useful for me to know that CGI module is not more recommended.

I will have in mind the possibility to have separate Perl installations. Then, in scripts, I should address the version I want to use?

Two days ago, I've installed the old Ubuntu version (12.04) on my Virtual Box and there is a little higher Perl version then I have on other systems. I was surprised with so many Perl modules in Ubuntu Software Center and suppose just a part are CPAN but others are not. So, I've installed several through this Center and just few through CPAN. Then later, I've read in your post about recommendation to avoid modifying the Perl in the system and about installing modules two ways.

I think my systems work well till now, but will have in mind the warning.

Among other modules, I've installed Chart::Clicker (not sure now but probably with cpanminus) because found on the web that it is a simple yet powerful tool for plotting graphs etc. It was very surprising to see that it resulted in 102 distributions installed! The examples for that module work very well and graphs are really nice but I would have a question: ok, for a desktop computer the number of these modules is maybe not important but for the server, is it recommended to have just that so demanding module or work with some others?

At the and, I would also ask You, if it is ok to sometimes send You a personal message, when I am not sure whether my reply to your post is interesting to others or not?

[haukex]

Hi predrag,

I've partially changed the title of this node but am not sure if that is ok?

Yes, changing the node title is ok, in this node I've also made a change to the title to shorten it a bit. See also How do I compose an effective node title? Note that if threads go too far off-topic, or if there are follow-up questions that are not directly related to the original question, often it's better to start a new thread (a good example being your question of how to specify which Perl version to use, which I've answered below).

I would like to learn CGI scripting later this year and it is very useful for me to know that CGI module is not more recommended.

Yes, there are several more modern web frameworks now: Plack, Catalyst, Dancer, Dancer2, and Mojolicious (all of these implement the new PSGI specification). All of these are good, in my personal opinion I like Mojolicious. Here is a tutorial for getting started with Mojolicious::Lite.

... separate Perl installations. Then, in scripts, I should address the version I want to use?

A typical set-up would be to have the system Perl in a location like /usr/bin/perl, and to have one or more other Perl installations in e.g. ~/perl5/perlbrew (when using perlbrew). However, I normally* wouldn't recommend changing the shebang line ("#!/usr/bin/perl") to a specific installation, because that will likely not work when the scripts are copied to other machines.

Instead, one would ensure that the environment variable PATH is pointing to the desired Perl installation (such as with "perlbrew switch perl-5.24.1", can be checked with the command "which perl"), and then in your scripts the shebang line "#!/usr/bin/env perl" will cause the perl currently in your PATH to be used. Changing the PATH to select a Perl installation also has the advantage that a command like cpan Module::Name will install to the selected Perl installation.

Also, in your Perl scripts you can specify a minimum required Perl version with e.g. use 5.024; for Perl v5.24 (this has the advantage that the new default features of that Perl version are enabled). Is is uncommon and usually not necessary to specify "use exactly this version of Perl".

* However, the aforementioned advice about the shebang line can change in the case of scripts uploaded to a server that you do not have control over. Some webhosts limit their customer's ability to use custom Perl versions, instead providing one or more Perl installations themselves, such as /usr/local/bin/perl5.16 or /opt/perl5.20/bin/perl. In such cases, it might be necessary for you to change the shebang line to point to a specific installation of Perl.

for the server, is it recommended to have just that so demanding module or work with some others?

1nickt and hippo already discussed some of the pros and cons of this. The number of modules you have installed on a machine won't make a difference, only the modules your script uses will make a difference in the start-up time of the script. Traditional CGI scripts would get re-executed on every request to the web server, so start-up times on CGI scripts would make a difference, especially if they get many requests per minute. There are however more modern web servers in which the scripts keep running between requests, in which case the start-up times do not matter. Of course, if this is just a small web page on which you don't expect many requests, start-up times of the scripts may not matter much at all. Otherwise, it would be wise to consider ways to optimize, such as using one of the more modern implementations that keep the scripts running. Another approach might be to not re-generate the charts on every request, instead keeping them cached and only re-generating them when necessary, such as based on an interval or when the data changes.

I would also ask You, if it is ok to sometimes send You a personal message, when I am not sure whether my reply to your post is interesting to others or not?

Personal messages are ok, but note that they are limited in length. In general, anything related to Perl (including web interfaces with Perl) is on-topic here, so it is of interest :-) Posting publicly also means more people can learn from the discussions.

Regards,
-- Hauke D

[predrag]

Hauke D, lnickt and hippo, thanks a lot to All.

The reason why I've asked the opinion about Chart::Clicker wasn't about space on the server but closer to the reasons that hippo mentioned. lnickt also mentioned the problem of loading too many modules. Regarding memory, I think there will be enough on the server (at least 1GB and later maybe 2GB).

The additional reason for my question was because I would like to have something optimal, that is, for example not too large or too complex without reasons. I simply have no sense now of what is optimal and what is not for plotting Perl graphs, but lnickt made a comment that helped me to see that:

It's difficult to imagine a solution producing high quality graphs from a system graphics library

Of course, I understood later that having such nice graphs requires some additional "costs".

Now, I have installed two modules for graphs: GD::Graph and Chart::Clicker. The first one requires ImageMagic and I have it installed, and the second requires Moose, and it is installed as a dependence. I don't know if some other modules can be recommended for graphs, I know for GIFgraph too. From your comments I understand that Moose will be very useful for me in the future, for more advanced use of Perl.

Examples I've tried for both modules work and I must say I prefer graphs by Chart::Clicker.

Hauke D thanks for the help about posting on perlmonks etc. I 've already read different FAQs but obviously need some additional time to be more familiar with all that. I see discussions can quickly go out of topic, so one need to think in advance while choosing the right title, or change title often. Thanks for the explanations about Perl installations too, and I believe it will become clearer when I start to use perlbrew. Today, I've looked at different Perl directories a little and found many modules and other files and directories.

Hauke D Your explanations about CGI scripting are very useful for me but it is probably out of this topic (OT), so I should start a separate topic, but it is maybe too early, because I didn't step in CGI yet. Anyway, I will remember what you wrote

I dream about one big project for my website for very long time (much older then that idea of converting Latin letters into Cyrillic). During the time, depending ot my knowledge, experience and conditions I went through different phases about how to realize that project.

Now, with Perl things appear in a completely different light. I am thinking of sending a post on perlmonks about that but maybe I should wait till I begin with the work and first results. On the other side general comments will probably be more useful for me. The right thing is maybe in the middle.

[predrag]

Hauke D I was thinking again about your post and hope that it is not a mistake to reply to your comments, even if we maybe go a little out of the topic.

Traditional CGI scripts would get re-executed on every request to the web server, so start-up times on CGI scripts would make a difference, especially if they get many requests per minute. There are however more modern web servers in which the scripts keep running between requests, in which case the start-up times do not matter. Of course, if this is just a small web page on which you don't expect many requests, start-up times of the scripts may not matter much at all. Otherwise, it would be wise to consider ways to optimize, such as using one of the more modern implementations that keep the scripts running. Another approach might be to not re-generate the charts on every request, instead keeping them cached and only re-generating them when necessary, such as based on an interval or when the data changes.

During last year, my website had about 400-1000 daily visits and with the new design and much of new content I expect more visits in the future. So, I should have all that in mind while working on my CGI scripts.

I would like to realize web monitoring on my website, with data about bee hive weight, weather etc. It would be ideal if some or all of these data are presented visually, so this is why I asked a question about modules for plotting in Perl.

From your comment I see that maybe your last suggestion is most appropriate for me ( not re-generate the charts on every request) because in the simpler version, data would changes probably two times a day. Pages with these data will be very attractive to visitors, so it can significantly increase web traffic.

Anyway, when I have some results, I will ask perlmonks for comments

regards

predrag

[haukex]

Hi predrag,

data would changes probably two times a day

One way to do this would be with a cron job calling a Perl script that generates the charts twice a day and saves them as image files. Then, the web server would only have to serve up static files, without the need of calling a CGI script to get the images.

Regards,
-- Hauke D

[1nickt]

Hi predrag,

Chart::Clicker is one of those distributions that has *lots* of dependencies, mostly because it uses the Moose object management system. The next time you install a new module that also requires those same dependencies, Perl will see that you already have them and they won't be installed again.

There should be no issue with space on your server or your home machine.

A long time ago when computers were not so powerful, there was concern about loading too many modules (whether directly or as dependencies) because your script could be slow to compile. But unless you are in a very specialized situation this should not be a concern either.

Hope this helps!

[hippo]

The next time you install a new module that also requires those same dependencies, Perl will see that you already have them and they won't be installed again.

Unless of course that new module requires more recent versions of those dependencies.

A long time ago when computers were not so powerful, there was concern about loading too many modules (whether directly or as dependencies) because your script could be slow to compile. But unless you are in a very specialized situation this should not be a concern either.

That's a bit more contentious. Quite a lot of the time I avoid long (and broad) dependency chains. Reasons for this include:

• The slow-compilation startup penalty to which you referred.
• The extra memory requirements.
• The increased fragility of the entire module stack.

Given predrag's stated aim of investigating CGI then all of these points become relevant for him, I would suggest.

[1nickt]

"Quite a lot of the time I avoid long (and broad) dependency chains"

As do I, quite a lot of the time. Here I was responding to what the OP wrote:

Among other modules, I've installed Chart::Clicker (not sure now but probably with cpanminus) because found on the web that it is a simple yet powerful tool for plotting graphs etc. It was very surprising to see that it resulted in 102 distributions installed! The examples for that module work very well and graphs are really nice but I would have a question: ok, for a desktop computer the number of these modules is maybe not important but for the server, is it recommended to have just that so demanding module or work with some others?

It's difficult to imagine a solution producing high quality graphs from a system graphics library -- his stated aim here -- that doesn't require both a lot of dependencies and a large memory footprint. It's also difficult to imagine that he won't sooner or later wind up installing Moose, like it or not. My comment was intended to put his mind at ease about what seemed questionable to him.