headers
Eric Wilhelm | 2 Dec 2009 19:42
Picon

Plugins (was: AUTHOR_TESTING and xt?)

# from David Golden
# on Thursday 26 November 2009 05:10:

>How about this:
>
>(1) We add a "testrelease" action that sets RELEASE_TESTING and calls
>a list of other testing actions
>
>(2) We add a 'testxt' action that runs tests in xt/; this is common
>enough now that we might as well make it easy
>
>(3) We add a 'release_test_actions' parameter to set the list.  This
>would default to qw/test testxt testpod distcheck disttest/ but could
>be overridden in arguments to new()
>
>...Build release' would be easy to do...

This has triggered my semi-biyearly ponderance of plugins.  I 
think "tools for authors" should be doable outside of M::B.  And/or 
more easily customized than via subclassing, plus more easily shared 
between distributions than via copy+paste.

What is mentioned above covers most of what CPDK::Publish does, but I 
guess having it inside the build system would work just as well.  In 
any case, I want to be able to drive it via layered config files so 
that machine+user+project settings are manageable.

For general thoughts about plugins:  We've discussed before/after hooks 
and I think that's the way to go (maybe just a hash of arrays of 
subrefs -- maybe run by _call_action() or even something installed in
(Continue reading)

Permalink | Reply | 8 comments |
headers
John Peacock | 2 Dec 2009 20:05

Re: Plugins

Eric Wilhelm wrote:
> Note that we can't use a more typical "plugin configures itself" 
> approach (e.g. call the plugin's init() method after loading) because 
> M::B needs to run on installation targets where a dev plugin might not 
> be available and in other cases we need to have enough info to 
> automatically declare dependencies or perhaps even handle bundling.  
> But the plugins probably need to still declare something about what 
> they provide so the loader can double-check against what is in 
> Build.PL.

Sounds like you need something like a metafile for each plugin (a mini 
manifest) which M::B can use to resolve which plugin is needed at that 
point.  Would those meta files be included in the M::B bundle or be 
available at a well-known location (e.g. CPAN)?  The former requires a 
lot more cooperation if multiple authors are generating plugins.  The 
latter requires net access during the install (which probably should not 
be considered to be an absolute blocker in this day and age).

We do something like this at $WORK so that the config system can resolve 
which library to load.  It only needs to be enough to get to the point 
of knowing what package to load, then allow the plugin itself to 
register options, etc, and continue from there.  So by having these two 
stages, you can go back to "plugin configures itself" after M::B decides 
whether to load it at all...

John
Permalink | Reply | 3 comments |
headers
ron | 2 Dec 2009 23:34
Picon
Favicon
Gravatar

Re: Plugins

Hi John

Quoting "John Peacock" <john.peacock <at> havurah-software.org>:

> Eric Wilhelm wrote:
> Sounds like you need something like a metafile for each plugin (a  
> mini manifest) which M::B can use to resolve which plugin is needed  
> at that point.  Would those meta files be included in the M::B  
> bundle or be available at a well-known location (e.g. CPAN)?  The  
> former requires a lot more cooperation if multiple authors are  
> generating plugins.  The latter requires net access during the  
> install (which probably should not be considered to be an absolute  
> blocker in this day and age).

I've just left a job after 3 years, where there was no possibility of  
net access during installs.

It's not an unusual situation, e.g. at my new job we use Debian  
packages to install modules. How would they be linked to plugins?
Permalink | Reply | 1 comment |
headers
David Golden | 2 Dec 2009 23:59
Picon
Gravatar

Re: Plugins (was: AUTHOR_TESTING and xt?)

On Wed, Dec 2, 2009 at 1:42 PM, Eric Wilhelm <enobacon <at> gmail.com> wrote:
> This has triggered my semi-biyearly ponderance of plugins.  I
> think "tools for authors" should be doable outside of M::B.  And/or
> more easily customized than via subclassing, plus more easily shared
> between distributions than via copy+paste.

I'm working somewhat half-heartedly in my dead time in airports and
what not on what I'm calling Acme::Module::Build::Tiny -- a
minimalistic implementation of the "Build.PL protocol".  I'm using it
as a thought experiment to formalize and write up the protocol -- what
CPAN/CPAN should expect to happen and be supported.

It's kind of fun -- it's about 130 SLOC and is almost at the point
where it's fully capable of installing itself.  The .pm file is a
modulino that gets copied to become Build.  Plus it auto-bundles
itself in inc/.  And Build.PL is just "use lib 'inc'; use
Acme::Module::Build::Tiny".

Anyway, when that's done, I think I'll have a clearer sense of what in
M::B is really "core" and what is "author support".  That said,
plugins are probably not on my radar in the next year.  But maybe my
definition of a standard protocol for Build.PL will help you.

David
Permalink | Reply | 3 comments |
headers
Eric Wilhelm | 3 Dec 2009 00:00
Picon

Re: Plugins

# from John Peacock
# on Wednesday 02 December 2009 11:05:

>Sounds like you need something like a metafile for each plugin (a mini
>manifest) which M::B can use to resolve which plugin is needed at that
>point.

Perhaps, but I was saying that this info should be provided as part of 
the Build.PL contents (or analogous to that -- or otherwise benignly 
supplied during new()) so that what plugins we need at any given stage 
is declared by the module author.  As I see it, this only needs to be 
super-thoroughly checked at `Build dist` time -- where we ensure that 
plugins on the "big 3" actions are in the dependency list.  The rest of 
the errors could be handled well enough with runtime messages.

>Would those meta files be included in the M::B bundle or be 
>available at a well-known location (e.g. CPAN)?  The former requires a
>lot more cooperation if multiple authors are generating plugins.  The
>latter requires net access during the install

If by "the M::B bundle" you mean the developer's distribution tarball 
and not the Module-Build distribution, then yes.  But otherwise, no I 
wouldn't try to maintain a central source of this stuff because then 
we're back to playing gatekeeper not to mention more stuff to maintain.  
I don't think plugins need to be heavily managed -- they just need to 
give the module developer enough hooks to do the right thing.  Trying 
to do the right thing on the developer's behalf is going to tend to get 
in the way more than it's worth.

>...at $WORK ...resolve which library to load.  It only needs to be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Wilhelm | 3 Dec 2009 00:17
Picon

Re: Plugins (was: AUTHOR_TESTING and xt?)

# from David Golden
# on Wednesday 02 December 2009 14:59:

>Anyway, when that's done, I think I'll have a clearer sense of what in
>M::B is really "core" and what is "author support".  That said,
>plugins are probably not on my radar in the next year.

We can't really draw a line between "core" and "author support" -- only 
between "core" and "not core" (because what was once in "core" is 
expected to always be in "core".)  Without plugins, there is not really 
such a thing as "not core", which means nothing can depend on anything 
and we have to program with twigs and string instead of Perl and the 
CPAN.  It would be convenient for many people if we added feature X and 
Y to core, but we usually end up with something limited because of the 
twigs and string, then you get even more mess when someone starts 
copy+pasting subclass code with large swaths of M::B innards into 
multiple dists.

So, of course the loading of plugins would maybe need to be core -- but 
Module::Build::Plugins with configure_requires is probably feasible 
(maybe even without monkey patching) given a bit of cooperation (or 
just a bit of communication and not purposefully breaking the API.)

>Plus it auto-bundles itself in inc/.  And Build.PL is just "use
>lib 'inc'; use Acme::Module::Build::Tiny".

I'm looking forward to seeing that without the bundling.  This would 
demonstrate that configure_requires and the "Build.PL command-line API" 
is maturely supported in the toolchain.
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Golden | 3 Dec 2009 01:37
Picon
Gravatar

Re: Plugins (was: AUTHOR_TESTING and xt?)

On Wed, Dec 2, 2009 at 6:17 PM, Eric Wilhelm <enobacon <at> gmail.com> wrote:
> # from David Golden
> # on Wednesday 02 December 2009 14:59:
>
>>Anyway, when that's done, I think I'll have a clearer sense of what in
>>M::B is really "core" and what is "author support".  That said,
>>plugins are probably not on my radar in the next year.
>
> We can't really draw a line between "core" and "author support" -- only
> between "core" and "not core" (because what was once in "core" is

Sorry.  I was imprecise.  I was not saying "core" to mean "Perl core".
 Just what is *essential* for configure/build/test/install and what is
extra to support authors.  Much of the ACTION_* proliferation is just
author support.  Most of the feature bloat of M::B is either author
support or configuration proliferation.

More on this when I've written up the protocol more formally.

> twigs and string, then you get even more mess when someone starts
> copy+pasting subclass code with large swaths of M::B innards into
> multiple dists.

Too much of M::B is "public" interface in my opinion and it makes the
whole thing brittle.

>>Plus it auto-bundles itself in inc/.  And Build.PL is just "use
>>lib 'inc'; use Acme::Module::Build::Tiny".
>
> I'm looking forward to seeing that without the bundling.  This would
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Wilhelm | 3 Dec 2009 01:50
Picon

Re: Plugins (was: AUTHOR_TESTING and xt?)

# from David Golden
# on Wednesday 02 December 2009 16:37:

>> We can't really draw a line between "core" and "author support" --
>> only between "core" and "not core" (because what was once in "core"
>> is
>
>Sorry.  I was imprecise.  I was not saying "core" to mean "Perl core".
> Just what is *essential* for configure/build/test/install and what is
>extra to support authors.

I know that's what you meant.  And yet the coreness curse has probably 
already taken effect.  If you remove something, you'll find out how 
many people were relying on it in a couple years when they finally 
upgrade.

--Eric
--

-- 
We who cut mere stones must always be envisioning cathedrals.
--Quarry worker's creed
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
Permalink | Reply | 0 comments |
headers
Zefram | 3 Dec 2009 11:34

Re: Plugins

ron <at> savage.net.au wrote:
>                                    at my new job we use Debian packages 
>to install modules. How would they be linked to plugins?

Same way they're linked to any other CPAN modules.

-zefram
Permalink | Reply | 0 comments |
headers
David Golden | 7 Dec 2009 05:59
Picon
Gravatar

Re: Please test DAGOLDEN/Module-Build-0.35_13.tar.gz

On Sun, Dec 6, 2009 at 11:29 PM, Craig A. Berry <craig.a.berry <at> gmail.com> wrote:
> Thanks for the heads up.  Below is a quick build and test, which is
> not all good news, but not entirely bad news either.  This is just a
> "where we are" post and I have not even looked at the test output in
> any detail yet.

Ouch.  Well, no pain, no gain.  Thank you for the quick turnaround.

A couple quick reactions (other than that I probably need to find a VMS manual):

* the t/00compile.t tests look like a problem converting paths to
modules names given the particular ways paths are represented on VMS.
I thought I was doing something suitably portable, but clearly not.

* there are a lot of "Can't call method "eliminate_macros" on
unblessed reference" errors; I have no idea what's going on there

* the "no module_name" errors are again probably (again) an issue
translating between module and path names -- please see
_guess_module_name in Module::Build::Base.

Given how module/path translation seems to be at the root of some of
these, maybe we need to add "pm2path" and "path2pm" methods to
Module::Build::Base and overriding them in
Module::Build::Platform::VMS?  E.g. something that would let us do
this:

    File::Spec->catfile("lib",$self->pm2path("Foo::Bar"));   # lib/Foo/Bar.pm

    $self->path2pm(
(Continue reading)

Permalink | Reply | 0 comments |

Gmane