The installer has its own
TWiki::Configure::UI::getUrl()
utility to dowload packages from twiki.org using a socket. This code is not aware of the proxy settings of TWiki.
I think it would be better to use the existing
TWiki::Net::getUrl()
instead, it is aware of the proxy settings.
(Although
TWiki::Net::getUrl()
is trying to use LWP, it falls back to its internal socket based code.)
--
PTh
TWiki stores proxy information in TWiki preferences. Access to those preferences requires a fully configured twiki, which may not be available during
configure
. So a prerequisite would be to remove any dependency from Net on those preferences.
Besides, I really don't want to add dependencies from the
configure
code on twiki core code, as it would be too easy for a minor core change to mysteriously wreck
configure
. It's a chicken and egg situation; configure has to be able to run with a badly broken twiki, so every dependency is a risk.
It might be easier to simply make
TWiki::Configure::UI::getUrl
use the proxy settings from
$TWiki::cfg
.
Set to Actioning, as the analysis and solution are clear.
CC
I think we can distinguish between first time install and maintenance mode.
During first time install, settings are off, and as Crawford noticed, we should not introduce a dependency on the core (for example lib path could be incorrect.)
During maintenance mode one can assume that TWiki is running. In this mode, extensions are installed. Therefore, I find it helpful (and not an issue) that the extension installer is aware of the proxy settings.
--
PTh
Well, I put in support; however I have no way to test it, as I don't have any proxies. However it certainly doesn't
break anything, so I think it's safe to release; it's modelled on TWiki::Net.
CC