Get Iplayer for Windows
dinkypumpkin at gmail.com
Wed Aug 17 21:01:30 EDT 2011
On 15/08/2011 17:58, Jon Davies wrote:
>> On Sun, 2011-08-14 at 17:41 +0100, Jon Davies wrote:
> Ah, there are two aspects to this:
> 1. why not distribute the whole of strawberry perl? for which the
> answer is that a minimal subset is smaller and can be built such that
> it includes non-standard packages, which is useful, and to support
> dinkypumpkin's new tagging stuff necessary. (though by the time you
> add the extra packages from CPAN to support tagging and some other
> features that have recently crept into versions of get_iplayer, it's
> not hugely smaller.)
The tagging-related modules don't add that much, and PAR::Packer adds
all the core libraries anyway, so nothing we do will have a huge effect.
Moving to Perl 5.12 will bulk things up quite a bit just by dint of
more stuff being in core. Even so, David's 10-1 ratio still roughly
holds if you compare the disk usage of the get_iplayer Perl package to
the MSI install of Strawberry Perl. I would hazard a guess that most
people who want get_iplayer on Windows aren't necessarily interested in
taking the full Perl plunge.
I can see how it might be nice to just download and run the Strawberry
Perl installer and not need to manage Perl as a dependency. Having the
ability to add extra modules is nice, but I wonder how useful that will
be. So far, the only modules not already provided by Strawberry Perl
5.12 are the 3 needed for MP3 tagging. We could cover that tagging
functionality, albeit not as well, by providing a windows build of id3v2
for download, or embedded in the installer (this is what I was doing in
I'm playing a bit of the devil's advocate here. I expect there would
be potential headaches with relying on an external Perl. If there
really were new features that needed extra modules, we couldn't control
the update process, and users might find themselves at the mercy of
broken installations, etc. On balance, I think it's worth continuing to
own the Perl used for get_iplayer. Now that I've automated the process
of producing the Perl component and installer, it shouldn't be too
difficult to do so.
> 2. why not make the packaged version of perl a downloadable component?
> if we're making the other dependencies updatable components, then it
> would make sense to make the perl distribution an updatable component
> as well, which would allow us to update perl without building an
> entire installer. By extension, the windows scripts should be a
> downloadable component too, so that they too can be updated in the
> same way. But this doesn't have to be done in one go.
That wouldn't be difficult if somebody wants to host the Perl component.
The zip extractor plugin is already in the installer. My earlier
installer versions included the Perl bits as a zip file (one less step
during the build), and it's easy enough to extract it as needed, just
like the helper apps. I've reverted that for public use since the zip
archive really bulks up the installer (archive doesn't compress much).
Still, it would be simple enough to treat the Perl components and
scripts just as helper apps. That said, those aren't particularly
volatile components. Since the installer can already find new versions
of itself, it is probably just as easy to distribute Perl in that form.
>>> I have an objection in principle to install/update functionality that
>>> depends on the server behaving in a particular way because it ties you
>>> to servers that can be specifically configured, which rules out many
>>> hosting services - so using server-side redirects somewhat irks me.
>> I'm not sure that's a consideration. We're pointing it at our *own*
>> service which *is* under our control.
In general, I came around to the viewpoint David expressed. However, I
wouldn't mind simplifying things a bit in order to minimise the reliance
on a specific backend configuration and to future-proof the installer a
bit. My thought is that we would incorporate all the installer
configuration data - component versions, download URLs, etc. - into a
simple INI file (easy to handle in NSIS script). Whenever the installer
fires up, instead of doing the online version check it does now, it
would pull down the file, check for changes, and act appropriately. We
could reduce the number of online update resources from 8 to 1, and a
simple file could be hosted anywhere. We might even bake in a backup
source like a Google Code site or similar. I'm happy to do that or
something similar, but I'm not sure it's worth making such a big change
now. I reckon a new release of get_iplayer plus installer with the
current CGI redirect setup will hold people for a while.
>> I can even put the get_iplayer.cgi
>> script from http://www.infradead.org/cgi-bin/get_iplayer.cgi into the
>> git repository.
> since it's now an integral part of the installer/updater, this would make sense.
I second that. I could possibly save you a bit of typing by making
updates for the new release.
More information about the get_iplayer