moderated, AGAIN: how can I install modules if I'm not root?

by **Ilya Zakharevich** » Sat, 01 Apr 2006 08:09:27 GMT

Is this question finally resolved:

How can I install modules if I'm not root?

The standard answer for the Makefile.PL arguments:

LIB=~/perl/lib INSTALLMAN1DIR=~/perl/man/man1 INSTALLMAN3DIR=~/perl/man/man3

is, of course, useless in any non-trivial situation:

a) LIB= handles architecture-specific builds, but does not handle
perl-version-specific builds (at least according to 5.8.2 docs);

b) where do the scripts go?

c) Many modules disable installation of scripts if they see
LIB=... on the command line;

d) It is not documented how to change environment to transparently
load the modules installed as above.

So: is there any improvement?

Puzzled,
Ilya

by **Big and Blue** » Sun, 02 Apr 2006 07:55:17 GMT

First wrong assumption - that Perl itself is installed as root.

What you really mean is "How can I install modules if I'm not running
under the original install account?"

So use LIB=~/perl-{version}/lib (or similar?).

If you want them to go somewhere specific, set INSTALLSCRIPT (IIRC)

Then provide a patch and send it to the authors of such modules.

Change the script, not the environment.

All you need is "use lib qw( {LIB} );

Compared to what?

Likewise, so am I. Puzzled by people who think that software should
somehow read the mind of the user to figure out what it needs to do. We
don't (yet) have psychic processors!

Mind you - there is one bug in the way MakeMaker installs things - it
writes to an architecture-specific perllocal.pod even for a Pure Perl install.

--
Just because I've written it doesn't mean that
either you or I have to believe it.

by **Ilya Zakharevich** » Tue, 04 Apr 2006 06:27:43 GMT

[A complimentary Cc of this posting was sent to
Big and Blue
< XXXX@XXXXX.COM >], who wrote in article < XXXX@XXXXX.COM >:

I agree that the initial question is not well posed. But I do not
think this correction of yours has any merits in it. First of all,
the question I asked is taken literally from 2 different FAQs. ;-)

Second, Perl (more or less) supports 3-layer organization of the
module tree: it is convenient to call the layers vendor/site/user.
The intent is that the installation/maintainance of modules in
different layers may be "responsibility" of different people.

So even if I AM running under the original install account, I may want
to install THESE particular modules into a different layer.

How do I do it in CPAN.pm config file? How do I set PERL5INC so that
it works transparently with this setup?

What is the alternative to "somewhere specific"?

Thanks. Now how would I find these modules?

I do not think this has any meaning. First of all, what script?
Second, installed modules MUST be visible transparently. Why, you
think, this "strategy" of yours is not applied to just ALL the perl modules?

Compared to pitiful state of "as documented today by the FAQ answers".

This just means that you did not see any good piece of software. This
just means that you did not see how things were with Perl 12 years ago
- comparing to how they are now.

Should I read it as you suggesting that ability to set up automatic
transparent installation of modules requires psychic processors?

Puzzled: should I read it as you thinking that MakeMaker has one bug only?

Thanks anyway,
Ilya

by **Yitzchak Scott-Thoennes** » Tue, 04 Apr 2006 22:20:28 GMT

No. The new INSTALL_BASE parameter isn't even documented yet AFAICT.

Yes, there's been improvement over the MakeMaker that shipped with
5.8.2 over two years ago.

FWIW, the perl faq now says:

which would seem to cover d).

I'm almost certain issues with scripts still needing root are resolved
(at least with the incantation now in the faq), so for b) see the
current doc at http://search.cpan.org/perldoc/ExtUtils ::MakeMaker and
http://search.cpan.org/dist/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/FAQ.pod
and for c), pester the appropriate module authors to make such code
dependent on MM version. (Looking further into it, I think this
should work even with the makemaker shipped with 5.8.2.)

Your point a) I didn't understand. Do you want a way to specify a
PARAM= that automatically gets qualified by perl version? I'm not
sure there's much demand for that.

by **Big and Blue** » Wed, 05 Apr 2006 07:57:15 GMT

lya Zakharevich wrote:

It mentions root. I have Perl installs which are done by an account
which is not me, and is not a normal user either.

I have an installation with 5 different layers (which doesn't have any
vendor component).

Could be done.

Pass - I'm behind an authenticating firewall and prefer to download
modules as needed. I found CPAN.pm more of a complication (but am quite
prepared to accept others find otherwise). I have multiple architectures to
build and test on too.

Is PERL5INC something to do with CPAN.pm, or did you mean PERL5LIB. If
the latter, then using environment variables (global) to handle
application-specific tasks (which this is) is fraught with problems and best
avoided.

Write a simple startup module (installed in base perl) to set the
relevant @INC (and setup an editor routine for Config.pm at the same time)
and run it through an interlude which execs that base perl with
-MMyInitModule. By providing parameters to this module you can make it
appear in as many guises over the base perl as you wish (the only difference
between the interludes is this import parameter, so the code base is the same).

Sorry -I assumed you wanted to direct them to a known location. Do you
want them to go to a random one? You can set this in the Config.pm editor
mentioned above.

They're the ones which haven't installed the scripts you expect and
hence are looking for. And if you aren't looking for them it doesn't really
matter whether they are installed.

Actually I did. I'd say things are better.

You appear to think that it should all happen without you having to
think about it at all. I don't mind giving it the odd bit of help, such as
where to install things for differing Perls.

But I expect our situations are very different.

I expect it has others, but that's the only one which I notice.

--
Just because I've written it doesn't mean that
either you or I have to believe it.

by **Ilya Zakharevich** » Thu, 06 Apr 2006 05:28:36 GMT

A complimentary Cc of this posting was sent to
Big and Blue
< XXXX@XXXXX.COM >], who wrote in article < XXXX@XXXXX.COM >:

If you do manual ./Configure (or edit config.sh), you can make as
complicated (static) @INC as you want. But this is not what we
discuss here: @INC should be made user-specific (thus dynamic, thus
rely on PERL5LIB), and Perl installation is not assumed to be tuned
for any particular setup.

BTW, do these layers have some particular "tags" to explain their
meaning to you (like vendor/site/user)?

The question is not about whether "I can do it" (I remind that this is
quote from an engineer vs physisis vs mathematician story), but how to
make it EASY to make user-installed modules to work TRANSPARENTLY.

In many situations this is out of the question. My current "minimal"
install to make things useful is about 150 distributions.

Apologies for a misprint...

Sorry, but I find this general sentiment absolutely irrelevant to the
discussion. Given that there is no other way to TRANSPARENTLY inform
Perl about present modules, your feelings towards environment
variables do not matter much...

There is no way for a user in the context to install anything in base perl.

-Mwhatever is not transparent.

I have no expectation. Imagine this: one distribution lists some
other twos as prereqs; bundles may list hundreds. I have no idea what
these things do. CPAN.pm installs them - but they "do not work". Now
what?

For me, "things are better" would mean that there is a FAQ which gives
a WORKING answer to my question. Can you quote one?

Or, at least, there is an answer which covers at least SOME of the
questions I raised (and maybe not in any FAQ yet). Is there one?

Hmm... Do you realize that a significant part of Perl module install
framework is written by me? But the computer environment (and modes
of its deployment) change, and what we thought is enough 10 years ago
is pathetic and inadequate now...

And, yes, I DO THINK that there MUST be an answer which allows users to
install Perl modules without examining theirs intellectual potential
in the process. There SHOULD be a FAQ answer which JUST WORKS (and
not just in a handful of situations, as in the current ones I saw).

Hope this helps,
Ilya

by **Ilya Zakharevich** » Thu, 06 Apr 2006 06:45:46 GMT

[A complimentary Cc of this posting was sent to
Yitzchak Scott-Thoennes
< XXXX@XXXXX.COM >], who wrote in article < XXXX@XXXXX.COM >:

I do not think this changed in the last 10-or-about years. This does
not even cover the MAN*DIR settings, not to mention the shortcomings I
gave (or whether one can use ~ in these settings...).

When I initially added support for PREFIX, I thought that most Perl
installation would be done with prefix= argument to ./Configure. If
the latter assumption holds, THEN most of my questions have a
satisfying answer:

one does not need LIB, only PREFIX, so Makefile.PL checking for LIB=
does not matter;

all of manpath, scriptpath etc are set to reasonable values;

there would be no conflict of different Perl versions and
architectures;

the "magic" handling of PERL5INC may (?) take care of dependence on
directories on architecture and versions; so there is a chance that
setting some environment variables will make such installations
transparent.

Unfortunately, it turned out that most perl installation do not have
pure prefix=SOMETHING structure, so the PREFIX parameter is not
enough. Thus first the LIB= hack was included, then all the current
mess of the situation appeared - since this hack was not complete
enough...

Do not think so; there is neither edit of PATH documented; nor for MANPATH.

You install some modules. Then Perl version is upgraded, and all the
XSUB modules just return some garbage. Is this a satisfactory
situation, in your opinion?

Thanks,
Ilya

by **Big and Blue** » Sat, 08 Apr 2006 07:56:33 GMT

lya Zakharevich wrote:

Relying on environment variables is bad practice. These things are
*global* they affect all versions of perl, so if you set it and run one
version of perl, and and that code (or you, later) runs a different version
of perl you are probably in trouble. I've had to deal with juts set a
situation - it's not pretty.

If you want a particular @INC (or other internal perl setting) in place
for a particular perl then you really need to get that particular perl to
set it up *not* get your OS to set the same thing for all perls.

dev, test and prod. With 3 different executables.

My user-installed modules do you mean:

1) modules installed by a user for use by just that user
2) modules installed by a user for use by anyone using that user's view of
perl (but allowing different users to have create different perl setups from
the same base, each making these usable by all other users of the system).
3) modules installed by one user such that all users on that system see all
of them
4) like 3) but allowing multiple users to install to the same single perl.

Similar to mine then. I don't use CPAN.pm. I do have 4 architectures.

They do when using them causes trouble, which it does. Proposing, or
looking for, a general solution that involves them is not viable.

OK - 1 more arg created in the interlude and we can insert -I before -M.

Transparent to what? Seems to work well enough for me.

Then thank you very much. Oddly - I seem to find it more satisfactory
than you. Or perhaps it's not that odd - it's all to easy to expect
perfection in your own code while letting oddities in other's go unnoticed.

OK - but please expand on "user installs" (see the 4 element LIST above).

--
Just because I've written it doesn't mean that
either you or I have to believe it.

by **Ilya Zakharevich** » Sat, 08 Apr 2006 16:58:55 GMT

A complimentary Cc of this posting was sent to
Big and Blue
< XXXX@XXXXX.COM >], who wrote in article < XXXX@XXXXX.COM >:

Who cares? Perl relies on them, and provides NO OTHER MEAN for
customization. So this feeling of yours is simply not relevant. (I
also consider it questionable, but this is OT.)

This is what I want. I want to install modules SAME WAY as the
"natively installed" modules are installed: they go into the same
tree, and are available for the versions of Perl which are compatible
with them.

As I said in another message, if Perl was initially build with
prefix=... set, this is achieved by setting PREFIX in MakeMaker.

This is a part of my initial question: part (a). With correctly set
install directory, this would be avoided; BUT the standard answer to
the FAQ question gives an advice which leads to the results you see.

These are not layers. These are PARALLEL installations. What I mean
by layers is different locations for modules which are visible to the
SAME version of Perl. One example (not very clear, sorry, and it does
not mention that yet another hierarchy, user's, should be present too):

perldoc Config
/installstyle

For simplicity, let us cover this variant only. (Although I have no
clue what difference the variants you list make - except permissions,
which are, I think, an orthogonal question.)

My condolences. And my advice: use CPAN.pm + my patches + local mirror.

Sorry, I cannot agree less with this feeling of you. I have no doubt
that the problem we discuss is extremely trivial as technical problems
go. Basically, one needs a way to do what PREFIX= does - even if
initial Perl was not compiled with prefix= setting.

My question was about whether this problem is ALREADY solved, not
whether it is solvable.

Which arg, which interlude? I was asking about setting which make ALL
THE STUFF work TRANSPARENTLY the same way as when modules are
installed by root into the main Perl directory.

"transparent" above means that with a few global changes (and/or
installed modules) things work EXACTLY the same as with root-install
WITHOUT ANY MODIFICATION.

Well, if I did find it satisfactory "then", then (I'm almost sure) you
won't find it so satisfactory "now". ;-)

So far, this exchange looks like you are in the "high bug tolerance"
crowd: you claim that you see a lot of problems, AND you find this
"satisfactory". Maybe you think that the problems you see are caused
by not the bugs in the (design of the) installer, and not by our
(=designers) lack of time and/or stupidity, but by some bad position
of planets etc? ;-)

Very true too - but quite often I find myself more observant to
bugs/limitations of other software as well...

Hope this helps,
Ilya

by **Randy W. Sims** » Sun, 09 Apr 2006 11:39:30 GMT

It doesn't help you now, but a new feature added in Perl 5.9.3 (?) is
the 'sitecustomize.pl' which is installed in the sitelib directory, and
it lets YOU, the sysadmin, configure @INC to your liking, using perl
code (-Dusesitecustomize when running Configure, I think).

I think ActiveState's 5.8.x includes this feature, but I can't verify at
the moment.

Search p5p or p5changes for 'sitecustomize'.

Randy.

by **Ilya Zakharevich** » Sun, 09 Apr 2006 12:13:20 GMT

I'm asking about NON-ROOT customization. So I do not understand how
this can help in this regard...

Thanks,
Ilya

by **Big and Blue** » Wed, 12 Apr 2006 04:16:24 GMT

lya Zakharevich wrote:

Anyone who is writing coe for use by others.

Odd, then, tht I have achieved it *without* USIN environment variables
Indeed, I specifically *remove* PERL5LIB and LD_LIBRARY_PATH from the
environment as both cause problems when values set for one case end up being
usued in another due to their global impact.

Read that qualifier - "which are compatible with them. And by setting a
*global* variable you have just screwed up any other perl on the system.
(The same is true with LD_LIBRARY_PATH settings, but that can screw up more
than just perl)

OK - I have that as well, since dev contains test and prod (and, in
fact, contains a location for core modules, site-installed CPAN modules and
site-installed site-written modules).

Permissions may come into it, but there is a big, obvious difference
between by-user for-user and by-user for-anyone. In the former @INC would
effectively need to include a per-user location while in the latter it would
not.

I'm talking from experience. The experience of a company merger in
which one Perl installation relied upon environment variables. You couldn't
use that unless you had it specific PERL5LIB *and* LD_LIBRARY_PATH set, at
which point you couldn't use any other Perl.

No - I'm not. But I am of the "Can I see a workaround" crowd.

Well, I either missed or have forgotten where this started. ould I be
right in assuming that what you want is a "standard" Perl install that let
any user run (directly or indirectly):

perl Makefile.PL
make
make test
make instlall

and that the result would be an installed module (just) for them?

--
Just because I've written it doesn't mean that
either you or I have to believe it.

by **Ilya Zakharevich** » Wed, 12 Apr 2006 05:36:38 GMT

[A complimentary Cc of this posting was sent to
Big and Blue
< XXXX@XXXXX.COM >], who wrote in article < XXXX@XXXXX.COM >:

I have a feeling that this dialog does not lead to anywhere. You
claim that environment variables are bad, and there is some wonderful
solution which is better. I *KNOW* that there is no other solution
than using environment variables ;-), thus until I SEE this solution
of yours, I will not believe your "just take my word for it".

Please read my initial posting, part "a". What I asked was exactly
THIS. One MUST set an environment variable, so it must be one which
won't screw one if one has multiple versions of Perl. (Please note
that in my questions I do not care about multiple builds of the SAME
version of perl - ordinary users do not need this, and power users
will take care of such things themselves.)

Sorry, but IMO such problems are absolutely trivial to deal with. You
have the root permission; so just replace the Perl executable by a
8-line C wrapper which sets the needed environment, and exec()s the
particular perl executable.

"Ordinary" users do not have permissions for such liberties...

Well, for MY problem I did not see a workaround yet...

Nope. This is too restrictive. I allow for a need for arguments on
Makefile.PL command line. Likewise on make and make install command
line. Likewise for a need for modifications in .profile and/or
.cshrc.

But AFTER these modifications, the installed module should be usable
THE SAME WAY as if it went into main Perl "sitelib" directory;
including behaviour switching architectures and/or Perl version. No
additional modification of scripts using this module and/or scripts
using the installed scripts must be needed.

Thanks,
Ilya

by **Big and Blue** » Wed, 12 Apr 2006 09:41:38 GMT

It seems you are looking for an existing solution which requires no
changes, while I'm thinking about what (small) changes/additions could be
made to provide a solution.

I'm claiming that using a global variable for a local solution leads to
problems. It's (part of the reason) why programming standards promote local
variables usage, not global.

As I've pointed out - there is *no* such global setting.

Basically, yes (but there can be a little more to it). So why not
provide a similar ability to perl in general? I see someone has posted that
5.9.3 has a custom startup script. Perhaps suitable *generic* code in there
would do it?

OK - I wasn't suggesting that they be stopped, just that the "standard"
install would work for a user by installing to a personal directory for them.

No - you're thinking about global settings for a local problem here.
This lead to problems.....

Well, that's what I've got (but it uses a front-end C program to run a
non-standard (written-by-me) module to set the internal @INC and edit
Config.pm settings to do it. So it doesn't count according to your rules.

--
Just because I've written it doesn't mean that
either you or I have to believe it.

by **Ilya Zakharevich** » Wed, 12 Apr 2006 14:24:58 GMT

[A complimentary Cc of this posting was sent to
Big and Blue
< XXXX@XXXXX.COM >], who wrote in article < XXXX@XXXXX.COM >:

Sure, if it CAN be done without any change to existing source base,
such a solution would be available much sooner than otherwise.

Only two effects are needed:

a) an environment variable for setting @INC which behaves as -Mlib
(so will include version-specific subdirectories too, see `perl
-V:inc_version_list'). (I do not know whether plain PERL5LIB
already has an analogues automagic.)

b) A parameter for MakeMaker which behaves as PREFIX=DIR, but does not
require `-D prefix=...' during Perl configure. It should install
architecture-specific modules into versioned architecture-specific
subdirectory of DIR. It would be much better if it would also
autoinitialize MAN*PATH and SCRIPTPATH as well.

Again, I do not know whether such a setting is available already.

I'm not convinced.

I do in my OS/2 port. L<perlos2/"Making executables with a custom
search path">.

Yes.

It should not.

Right. I'm looking for a solution which will not intimidate a (brave
enough to edit .tcshrc) Joe user.

Hope this helps,
Ilya

moderated, AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?

moderated >> AGAIN: how can I install modules if I'm not root?