[Padre-dev] Padre::FirstTime::Vendor

[Adam Kennedy]

As far as naming goes, I'd prefer one exclusive package name, like
Padre::FirstTime::Vendor, which we guarantee never to be used by Padre
itself, and which exists exclusively for the user of the vendor to
overload the first time logic.

Padre would use Padre::FirstTime::Vendor if it exists, but otherwise
use the regular one.

Adam K

On 17 February 2010 07:01, Curtis Jewell
<lists.perl.padre-dev at csjewell.fastmail.us> wrote:
> On Tue, 16 Feb 2010 07:59 +0100, "Jerome Quelin" <jquelin at gmail.com>
> wrote:
>> On 10/02/16 08:48 +0200, Gabor Szabo wrote:
>> > There are two cases of first run of Padre
>> > 1) very first run
>> > 2) upgrade of Padre
>> >
>> > We might want to address both issues in the same place.
>> > We could have a module Padre::FirstTime that is loaded
>> > 1) if .padre did not exist
>> > 2) if the current version of Padre is different from version number
>> > recored in config.yml (I think it is not there yet, we will need to
>> > add it).
>> >
>> > When Padre::FirstTime is loaded it searches @INC for any module in the
>> > Padre::FirstTime::* name space. Loads them and calls one of the following
>> > methods
>> >
>> > Padre::FirstTime::*->first_time
>> > Padre::FirstTime::*->upgrade
>>
>> if you go down this train, you will need to pass $from_version and
>> $to_version to make sure that a) the module knows how to handle the new
>> version and b) the module does things differently depending on the
>> starting point.
>>
>> that being said...
>>
>> > There might be several packages under Padre::FirstTime::*, the order
>> > of calling is random thought we could actually make them be stacked on
>> > each other by makig then inherit from each other. e.g.
>> >
>> > Padre::FirstTime::Ubuntu isa Padre::FirstTime::Debian
>>
>> i'm not really that enthusiastic about this. i don't really see the
>> need. i'd rather be sure that padre has some sane defaults, that may
>> differ depending on the os platform.
>>
>> can you elaborate which problem you're trying to nail down?
>
> You aren't working on Strawberry Perl Professional, then :) - which is
> the reason I brought up the issue to Gabor and Adam :)
>
> SPP includes 3 plugins (PerlTidy, PerlCritic, and Catalyst) that I'd
> like to be able to activate the first time Padre is run, so that the
> user does not have to know to go to the plugin menu and activate them.
>
> I don't think Padre wants to go down the route of having all new plugins
> found activated upon use, but a packager including plugins with Padre
> should have a documented way of activating those plugins - minimal user
> configuration required, you know?
>
> (I'd end up including a Padre::FirstTime::StrawberryProfessional in the
> final if this is implemented.)
>
> Maybe we could sort by the names to activate each one.
>
> Padre DOES rely on Module::Pluggable, right? (apparently not...)
>
> This is a request that I'd certainly like to see fulfilled within the
> next month and a half.
>
> --Curtis
> --
> Curtis Jewell
> csjewell at cpan.org           http://csjewell.dreamwidth.org/
> perl at csjewell.fastmail.us   http://csjewell.comyr.org/perl/
>
> "Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c
>
> Strawberry Perl for Windows betas: http://strawberryperl.com/beta/
>
> _______________________________________________
> Padre-dev mailing list
> Padre-dev at perlide.org
> http://mail.perlide.org/mailman/listinfo/padre-dev
>