[Padre-dev] Distribution and upgrade of Padre

[Steffen Mueller]

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