Trying for the first time to use the new "Find More Extensions" feature in Configure.
In a Centos 4.4 (latest) equivalent to latest Redhat Enterprice pressing this new magic button gives this error:
Find TWiki Extensions
Could not load EXTENSIONS UI. Error was: Can't locate Archive/Tar.pm in @INC
(@INC contains: /var/www/t41b1/lib/CPAN/lib//arch /var/www/t41b1/lib/CPAN/lib//lti....
BEGIN failed--compilation aborted at /var/www/t41b1/lib/TWiki/Configure/UIs/EXTENSIONS.pm line 28, line 1.
Compilation failed in require at (eval 45) line 1, line 1.
BEGIN failed--compilation aborted at (eval 45) line 1, line 1.
You may be able to correct this error by installing the missing Archive/Tar.pm module.
This cryptic error may be easy to resolve for a skilled perl hacker but a normal admin will end up on Support web or #twiki with this one.
If this is a new dependency then
- Is it really necessary?
- It is required for the extensions installer, yes. it is used to unpack downloaded packages.
- Is is really really necessary? We really should not start adding more CPAN dependencies just for running configure.
- You can happily run configure without using the exensions installer piece.
- Can we add this to the TWiki distribution if it is really needed?
- I would advise against this. Archive::Tar requires compiled code
- And if we really do end up adding yet another requirement for the admin to install non-standard CPAN libs, then at least..
- Make sure Configure up front lists the missing dependency in the CGI setup -> Perl modules part of configure
- This is the first feedback I have received on the extensions installer (apart from a few throwaway remarks) so I could hardly claim it is thoroughly tested.
- Make sure the dependency is added to the INSTALL.html
- Make sure the error message specifies to install the CPAN lib Archive::Tar and not the cryptic "Archive/Tar.pm" message that non-perl-experts have no clue what means.
- The message is generated by perl, and not
configure. There is no standard policy for testing CPAN modules for availability, except through
I would recommend that you add
(and any other dependencies shown up that way) to
, with the message
Optional, required for the online extensions installer
. Arguably the extensions installer button should not be shown unless
gives the all-clear for required modules, though that is rather more code.
Note that a documentation update is required somewhere as well, to highlight the fact that the webserver user requires write access to the codebase to install extensions.
All changes above applied. Closed.
I do not agree that configure should need the TWiki installer to add new CPAN dependencies. Then we may as well drop the whole idea of the installer script.
I opened a new bug report on the missing doc update - but really this silly dependency on a CPAN lib for unpacking tgz files is the problem that should be fixed. See also http://koala.ilog.fr/twikiirc/bin/irclogger_log/twiki?date=2006-11-16,Thu&sel=73#l69
Note how Peter and I discuss this issue and at the same time some poor guy comes by and has problems installing a CPAN lib on a shared host without command line access or root access. We really put people in a difficult situation. Not all knows how to install CPAN libs. Not all have the access rights to do it. And in this case we should be able to fall back to using simple command line
I am with Kenneth, the best installation program does not help if the user cannot/does not know how to install additional CPAN modules. Unpacking archives needs to be resolved with a pure Perl module we can ship in
Also, the standard file type for TWiki extensions has always been .zip files. Not all packages have a .tgz, but all do have a .zip file. I recommend therefore to look for a pure Perl unzip library we can ship with the TWiki package. (See Item3156
Same goes for downloading files over http. What is used to get the files?
IMHO ignoring the huge background of work in CPAN, and trying to constantly reinvent the wheel, is madness. Solve the problem of allowing end users to install CPAN modules, instead of trying to replace them. Note that the installer already invokes CPAN to install required CPAN modules. Build on the standard Will introduced (lib/CPAN) and install there if permissions deny a system install.
I quite agree about provision of a fallback; indeed, the BuildContrib
is able to fall back to command-line tar/zip if the requisite CPAN libs are not available. However the small amount of feedback during development of the installer didn't include this point, and now I am not prepared to add it. You are very welcome to treat my work as a proof of concept and refine it, including adding support for .zip and downloading without LWP. That's what OSS is all about, after all.....
I love the auto-installer ... even if it is not perfect.
Any attempt in that direction is very welcome by customers.
, keep up the good work.
, please be a bit more open and pro-dev.
Don't be at loggerheads with each other just because of
Be more professional, please.
Or risk to discourage the rest of the TWiki contributors as well.
... which you can't afford.
If I may direct this back to debating the actual issue....
Here are the same arguments already given but spelled out more.
- Many Linux admins have no clue how to install a CPAN library. Many hardly know what CPAN is. If you sit behind a corporate firewall with an authenticated proxy it is pretty hard to setup CPAN to install libraries. I know. I have tried it. And I gave up. I could not make it work. Fortunately I found out that a guy called Dag makes rpms for RedHat which I could manually download and manually install with rpm.
- If you are at a shared host - and many use TWiki this way - your admin knowledge is usually even lower and you have no root access. Then you are depending on the shared host admin's willingness to install these extra CPAN libraries. And we recently had an example that a user could not even get them to install a vital and very necessary component like CGI::Session. Quite many users will not get their host provider to install libraries such as
Archive::Tar. So many users installing on shared hosts will not be able to use the auto installer unless we improve the dependency issue.
- Many admins on large corporations do not have root access to their machines either and they have similar problems as above. I often get phone calls from colleagues at other sites where they have problems installing TWiki because they do not have root access. And I have no clue how to help them.
- The dependency is not even necessary. All this lib does is the same as
tar -zxf. Most unix'es have tar installed. It is a natural thing to fall back on using what is extremely common.
Also note that I am not against using CPAN libs as such. On the contrary. It is smart to reuse what other people have worked hard on making work.
- If the installer program can install the dependencies in the local TWiki CPAN then there are no worries.
- If the dependency is per default in the TWiki distribution then it is no issue either.
- It is not the use of CPAN libs that is the issue here. The issue is that we replace the hassle if manual installation of plugins to an even bigger hassle of getting CPAN libs installed to enable running the auto-installer.
- The whole idea of the installers is that they install the plugins and any dependencies. And then we should try to do our best not to make it even more difficult to install the installer.
The auto-installer does look very promissing and as already said - is excellent work! But as also CC says it is almost untested software. And it with some nags that needs to get resolved before we release a TWiki version with this feature activated. It is only a week ago I built a beta 1 where the feature did not run at all.
With common effort - the OSS way - we will make a great configure auto-installer - for all our admin users.
Forgot to say: The Linuxes I have tried all had
installed so I believe this is pretty standard.
That may be the case for Linux machines.
perl -e 'use LWP::UserAgent;'
on Solaris returns
Can't locate LWP/UserAgent.pm in @INC
. Meaning, we need a fallback; which could be
turned into a module.
Another poor user with CPAN problems.
This time with an installer and the problem is Archive::Tar. Read the log. Listen to the customer. This guy is just like most new admins. Listen to the customer.
We have these questions all the time. And if we release 4.1 with configure working like now there will be even more of them.
The extension installer no longer crashes configure on missing dependencies, it simply refuses to load, so I am closing this. The wider debate - to CPAN or not to CPAN - is one for TWiki:Codev.ToCPANOrNotToCPAN
I realised when going through code that configure does not use LWP to get packages, it has its own download method.