[Padre-dev] Distribution and upgrade of Padre

[Gabor Szabo]

On Mon, Sep 1, 2008 at 12:53 PM, Steffen Mueller <smueller at cpan.org> wrote:
>
> Hi Gabor,
>
> Gabor Szabo wrote:
>>> I need your help in thinking over how we'll be able to distribute
>>> and upgrade Padre easily on the various OS-es.
>
> not an easy task. For the record, I think it's a very good idea to think
> about getting this right.
>
>>> Currently one of the biggest obstacles of Padre adoption - besides
>>> the fact that it is still lacking lots of cool features - is the
>>> difficulty to install WxWidgets and WxPerl.
>
> I can tell. I spent a couple of hours with IRC help to get it to work on
> my linux. (Turned out I had broken my system by configuration.)
>
>>> 1) I have created a binary package for linux using PAR and
>>> including everything. This seems to be ok, but it is 9 MB after
>>> bzip2 and people who use this version are not able to hack on
>>> Padre. It also means every new version will force people to
>>> download a large file.
>
> It's a reasonable stop-gap measure for getting new users to use it. Just
> remember that you'll need to provide a binary per platform.
> In particular on Linux, if you build with a recent libc, the PAR loader
> might not work on ancient libcs. Shouldn't be much of an issue, but it
> cropped up in the past.
>
> [...]
>
>>> So I thought we should provide upgrades of Padre using a par file.
>>>
>>> In either case 1 or case 2 above, after one has installed Padre she
>>> will be able to download a .par file which includes an updated
>>> version of Padre with all its new dependencies.
>>>
>>> The file will have to be placed in .padre/upgrades or some other
>>> place similar to the new plugin mechanizm. Actually Padre should be
>>> able to detect new versions
>>> and download by itself.
>>>
>>> When launching Padre it should first change @INC to include the
>>> latest .par file from the .padre directory.
>
> This might be a fun challenge, but there's probably trouble.
>
> That scheme sounds nice enough in theory, but maybe it is more difficult
> to get right than you think. I'll do some brain-storming with no
> particular order:
>
> 1) Replacing files in use
> I guess it would be acceptable that the user has to restart the program
> after an upgrade. While not necessarily one of the hardest, one of the
> ugliest problems is going to be that on Windows, you can't replace files
> that are in use. So self-upgrading stuff is totally icky. CPAN must have
> solved it, of course.
>
> 2) Download size
> Since you'd rather not have the user download those 10MB every time, the
> upgrades would have to be possible component-wise. Another complication,
> but most certainly doable.
>
> 3) Installing into a custom directory
> It's possible. You can do it with PAR::Dist::install_par. The amount of
> work is slightly more than the PAR plugin system I put in place.
>
> 4) @INC, finding code on the computer
> I'm really not sure whether this'll turn out to be a killer or not:
> If padre is installed into the system, either as an OS package or via
> CPAN, and executed. What happens is this:
> - The user runs "padre"
> - "padre" does a "use Padre".
> - Padre.pm uses its internal companion modules.
> - Padre.pm and its siblings use all sorts of modules.
> At which point can you decide to load from the user .padre/lib directory
> where you installed all your upgrades? You'll have to load enough of
> Padre to be able to determine that directory, so you need at least
> Padre::Config and Padre::PluginManager. Then, those things may set up
> the ~/.padre/lib as part of @INC to load the rest from there. But how
> are you going to upgrade Padre.pm, Padre::PluginManager, Padre::Config
> and all the CPAN modules those things require? They'll still always be
> loaded from the system. So potentially, you even end up with some parts
> old, some parts new. Yuck.
> No good solution for that from me. Except that one would have to have a
> very stable piece of code for determining the padre user directory and
> setting up @INC. That thing would be the first code to load and only
> thereafter, the main editor could be run. What if you - against all odds
> - need to upgrade that code? That'd need an entire re-install of Padre.
>
> 5) Versioning
> Which upgrade is compatible with which version of Padre?
> In the light of 4), this becomes a bit of a tough cookie. Maybe using a
> PAR::Repository and a customized subclass of a PAR::Repository::Client
> would ease the pain a bit. I'm not sure.
>
> Best regards,
> Steffen

Based on this and the chat I had with Adam Kennedy I think I
put this idea in a drawer. Somewhere deep.

So the remaining strategies are
1) Get the downstream distro maintainers to include Padre.
     This will make it easy to install it and people will get some
     "stable" albeit old version. If Padre is successful then there
    will be people creating packages of newer versions of Padre
    for older systems.

   Hopefully the parts that are difficult to install will be relatively
   stable so once those (mostly WxPerl) are installed it is going
   to be easy to install Padre using CPAN shell.

2) We'll continuoue to create the stand-alone downloadable
    versions.

Gabor