The installer has its own
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
instead, it is aware of the proxy settings.
is trying to use LWP, it falls back to its internal socket based code.)
TWiki stores proxy information in TWiki preferences. Access to those preferences requires a fully configured twiki, which may not be available during
. 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
code on twiki core code, as it would be too easy for a minor core change to mysteriously wreck
. 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
use the proxy settings from
Set to Actioning, as the analysis and solution are clear.
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.
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.