Question? Alternative to loading modules!!!

[ChicksHateMe]

I consider myself still a newbie so I am looking for help, not flaming.
Thanks in advance.

I have written a few Perl programs, and I enjoy it. I like it more than
doing stuff in PHP. I don't want to start the whole PHP - Perl thing,
but I like the power and ease of Perl, and who's faster doesn't matter
to me.

The one thing I dislike is trying to deal with website/hosts and
getting the modules installed that I need. It's a PITA.

I have Sometimes taken modules and just simplified them and used them
as an "include" instead of loading them. For some simple ones this
seems to work fine.


1. Where I am doing this for my own specific sites, what I am wondering
is, if there are any issues I may run into?

2. Would installed modules run faster than using the modules as a
simple include where possible and needed??

I've only used some simple modules so far this way, so I am wondering
also;

3 Is there an EASY way to convert a module to a simple include, or will
I OFTEN run into issues?? Things like assigned vars, etc??

Again, the reason I ask, Is I LOVE perl and want to learn more, but in
some cases it is REALLY difficult to get the hosts to load Perl
modules, packages, bundles, etc... So, in that way, it's hard to
actually run some software on sites ( i.e. pre-written CMS packages).
I Think this is a MAJOR reason why PHP based CMS's are far more
popular and supported than Perl Based ones.

This does make going with PHP a little easier route for CMS's and the
sort, BUTTT I am fighting and kicking to find a way to use Perl and
modules in a more simple way.

Thanks in advance

 

[Gunnar Hjalmarsson]

I consider myself still a newbie so I am looking for help, not flaming.

That introduction is in itself a reason for flaming, but I'll pass.

I have Sometimes taken modules and just simplified them and used them
as an "include" instead of loading them.

Exactly what do you mean by that? You'd better let us know how you do
it, or else it's difficult to comment on your specific questions.

Again, the reason I ask, Is I LOVE perl and want to learn more, but in
some cases it is REALLY difficult to get the hosts to load Perl
modules, packages, bundles, etc...

Note that there are ways to install modules in an own library for Perl
modules. If you have shell access, you may be able to do it 'the right
way', while you otherwise can at least copy the .pm files of pure Perl
modules into the library.

Not to mention the option to change hosting provider, of course.

 

[Chris Mattern]

I consider myself still a newbie so I am looking for help, not flaming.
Thanks in advance.

I have written a few Perl programs, and I enjoy it. I like it more than
doing stuff in PHP. I don't want to start the whole PHP - Perl thing,
but I like the power and ease of Perl, and who's faster doesn't matter
to me.

The one thing I dislike is trying to deal with website/hosts and
getting the modules installed that I need. It's a PITA.

I have Sometimes taken modules and just simplified them and used them
as an "include" instead of loading them. For some simple ones this
seems to work fine.

Um, wha? If you can do this, you can install your own copies of
those modules properly. Read up on installing modules in your
home directory.

<long series of questions about this odd workaround snipped>

My advice is to simply install the modules to your home directory
and use "use".

--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"

 

[Peter Scott]

The one thing I dislike is trying to deal with website/hosts and
getting the modules installed that I need. It's a PITA.

You don't have to get the site admin to install modules for you.
Do 'perldoc ExtUtils::MakeMaker' and see how to use PREFIX on
the 'perl Makefile.PL' step. Then do 'perldoc CPAN' to see how
to make a MyConfig.pm. Putting the two together means you can
install modules in your local filespace as simply as
'perl -MCPAN -e "install Foo::Bar"'. Then add the appropriate
'use lib' to your programs.

I have Sometimes taken modules and just simplified them and used them
as an "include" instead of loading them. For some simple ones this
seems to work fine.

Whatever you mean by "include", it is not a common Perl term.
I suspect you mean you copy a .pm file to the current directory.
This strategy will fail when dealing with a module that spans
multiple files.

1. Where I am doing this for my own specific sites, what I am wondering
is, if there are any issues I may run into?

You'll have a next to impossible time dealing with modules that
incorporate binary dependencies.

2. Would installed modules run faster than using the modules as a
simple include where possible and needed??

No.

 

[ioneabu]

I consider myself still a newbie so I am looking for help, not flaming.
Thanks in advance. [...]
3 Is there an EASY way to convert a module to a simple include, or will
I OFTEN run into issues?? Things like assigned vars, etc??

Just went through the same problem recently. Read about CPAN.pm at
cpan.org.

here is what I did:

http://groups-beta.google.com/group..._doneTitle=Back+to+Search&&d#04b1ba9d56dd12cc

 

[xhoster]

I consider myself still a newbie so I am looking for help, not flaming.
Thanks in advance.

I have written a few Perl programs, and I enjoy it. I like it more than
doing stuff in PHP. I don't want to start the whole PHP - Perl thing,
but I like the power and ease of Perl, and who's faster doesn't matter
to me.

The one thing I dislike is trying to deal with website/hosts and
getting the modules installed that I need. It's a PITA.

Do you get command line access to the hosting service, or only
the ability to upload files to your cgi directories?

I have Sometimes taken modules and just simplified them and used them
as an "include" instead of loading them. For some simple ones this
seems to work fine.

When possible, describe Perl things in Perl, not in English. There are
many ways to "include" things, and we don't know which one you are using.

1. Where I am doing this for my own specific sites, what I am wondering
is, if there are any issues I may run into?

Yes, but what they are depend on what you mean by "include".

2. Would installed modules run faster than using the modules as a
simple include where possible and needed??

No. Or at least not meaningfully faster.

I've only used some simple modules so far this way, so I am wondering
also;

3 Is there an EASY way to convert a module to a simple include, or will
I OFTEN run into issues?? Things like assigned vars, etc??

It depends on what you mean by "a simple include".

If you just copy the code from the .pm and paste it into your own
code, then you don't need to invoke "use" on the module, but (I think) that
means that you will need to explicitly call "import" for the module if the
module needs things exported.

BTW, I've done "includes" this way in the past, and I don't recommend it.
Installing the modules locally is much better if you can do it. If you
can't install them locally using CPAN and whatnot (because you don't have
CLI access), then you can still install them locally for pure perl modules
only by uploading the .pm file to the right directory and using -I in your
scripts.

Xho

 

[ChicksHateMe]

No, I'm not able to get to the shell, or a command prompt for my
server. I would actually prefer to find another way that would be
simpler, and easier for installation on generic hosting services.

Thanks for the input and direction towards installing modules in my own
directories, That sounds like the way to go for me.

It's been a while since I did much programming, but I really like Perl,
and like what I've been able to do so far. So I am looking to learn
more. My goal is to build for myself, and possibly for others, a Basic
CMS framework that has just the basics, and loads easily on any web
server without the need to deal with addional module installation if
possible.

The Idea of loading them in a local filespace is what I need.
Thanks again for your time, answers and direction!

 

[Charlton Wilbur]

CHM> I consider myself still a newbie so I am looking for help,
CHM> not flaming. Thanks in advance.

CHM> The one thing I dislike is trying to deal with website/hosts
CHM> and getting the modules installed that I need. It's a PITA.

perldoc -q 'my own module'

For that matter, you can get webspace with shell access in the
neighborhood of $30 a month. If you are at all competent at a
programmer, that's what 20 minutes of your time costs. In other
words, for every hour you spend working around stupid web hosts, you
could pay for three months of hosting at a competent web host.

Charlton

 

[Eric Bohlman]

CHM> I consider myself still a newbie so I am looking for help,
CHM> not flaming. Thanks in advance.

CHM> The one thing I dislike is trying to deal with website/hosts
CHM> and getting the modules installed that I need. It's a PITA.

perldoc -q 'my own module'

For that matter, you can get webspace with shell access in the
neighborhood of $30 a month. If you are at all competent at a
programmer, that's what 20 minutes of your time costs. In other
words, for every hour you spend working around stupid web hosts, you
could pay for three months of hosting at a competent web host.

Since he mentions hosts in the plural, I think it's a good bet that a lot
of the hosts he's complaining about aren't hosting his personal site, but
rather the sites of his clients. And that means that it's a question of
how much *they're* willing to pay, and for a recurring expense at that.
And for a service whose nature they probably don't understand, either.
So it's probably not the question of simple logic that it would seem to
be when looked at from a purely individualistic perspective, it's more a
question of a tough sales job.

 

[Charlton Wilbur]

EB> Since he mentions hosts in the plural, I think it's a good bet
EB> that a lot of the hosts he's complaining about aren't hosting
EB> his personal site, but rather the sites of his clients. And
EB> that means that it's a question of how much *they're* willing
EB> to pay, and for a recurring expense at that. And for a
EB> service whose nature they probably don't understand, either.
EB> So it's probably not the question of simple logic that it
EB> would seem to be when looked at from a purely individualistic
EB> perspective, it's more a question of a tough sales job.

Perhaps. But the math still works: if he's at all competent as a
programmer/web designer, he's getting $50-$60 an hour, and probably
more. Are his clients *really* willing to pay him that rate to
reimplement common modules when one hour of his time pays for three
months of hosting?

This is basic technical sales. "You need to host this site at a host
that allows Perl module installations. They generally run $30 a
month, which *is* more than the cut-rate web host you want to use.
However, if the host doesn't allow module installations, and the
cut-rate web host you want to use doesn't, then I need to rewrite a
lot of code instead of using standard well-tested modules, and that
will add between 8 and 12 hours to the development time for this
script. I'm happy to go either way, but the requirement that I not
use any external modules will add between $480 and $720 to the
estimate I gave you, and will save only $240 a year. The decision is
up to you." Doesn't seem like a tough sales job to me, especially as
it's one I've made several times quite successfully.

For that matter, if he's willing to re-sell web hosting, the math
changes - it turns into a cost to him of $30 for the first account
plus $5 for each additional domain, which he can probably charge $15 a
month for and still have his clients think it's a good deal.

Charlton

 

[Peter Scott]

No, I'm not able to get to the shell, or a command prompt for my
server. I would actually prefer to find another way that would be
simpler, and easier for installation on generic hosting services.

It's easy to write a CGI that'll let you enter arbitrary shell
commands from a browser. Just secure it so no one else can
use it

Never done one that could deal with interactive programs, although
it doesn't sound hard if you know what the questions are going to
be.

 

[Eric Bohlman]

This is basic technical sales. "You need to host this site at a host
that allows Perl module installations. They generally run $30 a
month, which *is* more than the cut-rate web host you want to use.
However, if the host doesn't allow module installations, and the
cut-rate web host you want to use doesn't, then I need to rewrite a
lot of code instead of using standard well-tested modules, and that
will add between 8 and 12 hours to the development time for this
script. I'm happy to go either way, but the requirement that I not
use any external modules will add between $480 and $720 to the
estimate I gave you, and will save only $240 a year. The decision is
up to you." Doesn't seem like a tough sales job to me, especially as
it's one I've made several times quite successfully.

That argument presumes that the decision of which host to use is in the
same hands as the decision to contract with a programmer. If it is, then
there are no flaws to your argument, but in even a fairly small company
the two decisions may be in different hands; in a larger company the two
decision-makers may even be under different VPs. Under such
circumstances, office politics dictate that Joe isn't going to be very
willing to spend extra money so that Jack can spend less money, even when
the money Jack saves is more than Joe spends and so results in a net cost
reduction to the company as a whole. Joe's performance evaluation is
going to depend on whether or not he cuts *his* department's costs, *not*
on whether or not he cuts *the company's* costs.

So it's not really a tough sales job *if* you're making the sale to
someone sufficiently high up in the client, but in many cases you don't
have access to someone that high up.

Once again, this isn't to say that your economics don't make sense; they
do. But businesses often act in particularly irrational ways.

 

[Charlton Wilbur]

EB> That argument presumes that the decision of which host to use
EB> is in the same hands as the decision to contract with a
EB> programmer. If it is, then there are no flaws to your
EB> argument, but in even a fairly small company the two decisions
EB> may be in different hands; in a larger company the two
EB> decision-makers may even be under different VPs.

In a company large enough to have two VPs, the sort of quibbling over
resources that you're positing will probably cost more than both sets
of resources combined. This is not to say that the quibbling won't
happen, but that if it does, the difference between $10/month and
$30/month is not the point -- the comparative status of the people
doing the quibbling is, and the goal of the quibbling is not to save
$20/month but to establish the pecking order in the company. And if
that's the case, making any sort of rational argument is pointless.

EB> So it's not really a tough sales job *if* you're making the
EB> sale to someone sufficiently high up in the client, but in
EB> many cases you don't have access to someone that high up.

If you aren't making the pitch directly to someone who can say yes or
no without consulting his boss -- and thus having to pitch it to him
second-hand -- you're wasting your time. (Another basic principple of
technical sales.)

EB> Once again, this isn't to say that your economics don't make
EB> sense; they do. But businesses often act in particularly
EB> irrational ways.

Yes, they do; but there's no reason to support that particular flavor
of idiocy, or to not point it out when it happens.

Charlton

 

[xhoster]

EB> So it's not really a tough sales job *if* you're making the
EB> sale to someone sufficiently high up in the client, but in
EB> many cases you don't have access to someone that high up.

If you aren't making the pitch directly to someone who can say yes or
no without consulting his boss -- and thus having to pitch it to him
second-hand -- you're wasting your time. (Another basic principple of
technical sales.)

What if you are making a pitch to someone who can say "no" without
consulting the boss, but can't say "yes" without consulting the boss?

From where I sit, it seems like that is the most common scenario.

Xho

 

[Charlton Wilbur]

EB> So it's not really a tough sales job *if* you're making the
EB> sale to someone sufficiently high up in the client, but in
EB> many cases you don't have access to someone that high up.

xho> What if you are making a pitch to someone who can say "no"
xho> without consulting the boss, but can't say "yes" without
xho> consulting the boss?

xho> From where I sit, it seems like that is the most common
xho> scenario.

Then you should be pitching it to his boss.

The basic principle is that you don't want the real decisionmaker to
have to hear your pitch second- or third-hand. You want to pitch
directly to the person who can say yes. If you're trying to sell to
people who don't have the power to say yes, then the best they can do
is relay the pitch, and they won't have the same knowledge of what
you're offering as you do, let alone the same flexibility in
negotiation on rates and schedule that you can offer if you're there
in person.

This really sucks when the person who is the real decisionmaker is a
pointy-haired boss type who doesn't know Perl from Peru, but even then
you're still better off talking directly to him because you can
impress him with your conviction and charm rather than your technical
knowledge.

Charlton

 

[xhoster]

xho> What if you are making a pitch to someone who can say "no"
xho> without consulting the boss, but can't say "yes" without
xho> consulting the boss?

xho> From where I sit, it seems like that is the most common
xho> scenario.

Then you should be pitching it to his boss.

The basic principle is that you don't want the real decisionmaker to
have to hear your pitch second- or third-hand. You want to pitch
directly to the person who can say yes. If you're trying to sell to
people who don't have the power to say yes, then the best they can do
is relay the pitch, and they won't have the same knowledge of what
you're offering as you do,

Ah, but you won't have the same knowledge of what is needed as the
intermediate does.

let alone the same flexibility in
negotiation on rates and schedule that you can offer if you're there
in person.

This really sucks when the person who is the real decisionmaker is a
pointy-haired boss type who doesn't know Perl from Peru, but even then
you're still better off talking directly to him because you can
impress him with your conviction and charm rather than your technical
knowledge.

This is why I do the opposite of your advice at every turn.

As the pitcher, I have the technical knowledge but not the charm,
so I prefer to not to pitch to the person who can say "yes" but doesn't
know what he saying yes to, other than conviction and charm. As the Boss,
I want somehow who can take the time to see through the sales pitch and
tell me what I really need to know in a more or less objective manner,
which means someone from my organization who knows our needs and jargon
best and is not "on commission".

And as the Boss's delegate, the last thing I want is for you to have direct
access to the boss so you can charm him into making a bad decision. So
when someone says they want to talk directly to the decision maker, I tell
them that I am the decision maker and the decision is "no".

Xho

 

[Guest]

I consider myself still a newbie so I am looking for help, not flaming.
Thanks in advance.

I have written a few Perl programs, and I enjoy it. I like it more than
doing stuff in PHP. I don't want to start the whole PHP - Perl thing,
but I like the power and ease of Perl, and who's faster doesn't matter
to me.

Perl is more creative, I'll have to agree. (I use both)

1. Where I am doing this for my own specific sites, what I am wondering
is, if there are any issues I may run into?

Yes. As someone pointed out, binary dependancies will be a nightmare.

You might also run into problems with the import() method that is called
automatically by 'use'

use lib qw(/your/module/path);

Is probably what you want.



Write a throw-away CGI/shell script:

#!/bin/sh
echo "Content-Type: text/plain"
echo ""

perl Makefile.PL 2>&1
make 2>&1
make install 2>&1

# set parameters and such for make, password protect directory first! (Or
# at least remove the temp cgi when done)

2. Would installed modules run faster than using the modules as a
simple include where possible and needed??

It depends.. in NON mod_perl CGI environments, the thing to keep in mind
is that only a small portion of your program will ever be run in the same
request. AUTOLOAD can really speed this up, (But become a HUGE nightmare
when you get into OO perl)

Either way, the strategy is to only load the portions of your program
via 'require' when they are actually needed. Literally including perl
code in one monolithic program can slow down a program considerably
in this environment.

In mod_perl environments, it's almost exactly the opposite.

3 Is there an EASY way to convert a module to a simple include, or will
I OFTEN run into issues?? Things like assigned vars, etc??

use lib qw(/path) can really go a long way here. (Or in some other
way modify @INC before any other 'use' statements are evaluated, a hack
when lib isn't available/won't work is to wrap @INC in a BEGIN { ... }
block, but don't do that unless 'use lib' won't work... it's ugly.)

Again, the reason I ask, Is I LOVE perl and want to learn more, but in
some cases it is REALLY difficult to get the hosts to load Perl
modules, packages, bundles, etc... So, in that way, it's hard to
actually run some software on sites ( i.e. pre-written CMS packages).
I Think this is a MAJOR reason why PHP based CMS's are far more
popular and supported than Perl Based ones.

Yea, PHP has sort of taken over, Used to be the other way around. There
are a lot of reasons for this. mod_perl is still quite popular in
larger scale operations. (With mod_perl, most everything you learn
about CGI optimization needs to be turned upside-down.)


Jamie