Plugin::LogReport broken by plugin2

[SysPete]

#1078 (comment) says:

Thanks @xsawyerx - I will give some better details when I get a chance to look into it properly, but (from memory) it basically boils down to no longer being able to import functions (or pass options) when loading a plugin. Although one could argue that this is not what a plugin is for, it is nonetheless a regression from the old system. It is also very useful to be able to do so: imagine that you have a "normal" module that exports a bunch of functions, and you want a Dancer plugin variant (as is the case with LogReport). It's much nicer being able to load a plugin and get all the normal module functionality plus some special Dancer things, rather than to have to load both the core module plus the plugin.

Like I say, I'll pass more details when I get a chance, I just wanted to give an initial heads-up. Thanks.

[racke]

I understand that @abeverly wants to solve the problem with his plugin, but I don't like that this delays the next Dancer release. Also the lack of a Git repository makes it harder for us to try to
solve it on our own.

[veryrusty]

The lack of a repo isn't a showstopper. Try: https://github.com/veryrusty/MARKOV-Log-Report-1.14.git

Its an import of the Log::Report v1.14 release from CPAN, so there is no history. Should I move it to the PerlDancer org to make committing easier ?

[SysPete]

@veryrusty having repo under PerlDancer makes sense.

[veryrusty]

@SysPete Repo moved: https://github.com/PerlDancer/MARKOV-Log-Report-1.14.git

[SysPete]

@veryrusty could you please add Core team to that repo? I don't have commit bit atm.

[veryrusty]

@SysPete Done (the migration gave read-only access to core - should have been admin .. oh well)

[xsawyerx]

Going up on a flight, will investigate during!

[xsawyerx]

I think whatever happens, this weekend we should already do a developer release.

[SysPete]

@xsawyerx excellent news on both counts. Dev release will be especially good.

[racke]

Yes, please do a developer release and have a save flight!

[abeverley]

Sorry for the delay responding. I've rerun the testing on the master branch of Dancer2. The first problem is the one that I had when testing with Yanick's original branch: #1010 (comment). I can fix that by using _exporter_validate_opts instead of import, although it does seem a little hacky and I never got a response to my question in the moops IRC channel as to whether this should be done or not. It also means a concurrent release of a new plugin version alongside Dancer2, but I can live with that.

The second problem, which I can't work out how to fix, is that it's no longer possible to pass options to a plugin. I get Specific subroutines cannot be exported from plugin. Firstly it would be nice if specific subroutines could be exported, as they can with the current plugin system, but secondly it means that options can't be passed either, which is also possible with the current plugin system. Any ideas please @xsawyerx?

Thanks, Andy

[xsawyerx]

@abeverley Indeed importing options are not available. I don't remember us ever documenting this can be done, so we might fall under "well, it worked, so we did it".

What if you the import-time configuration in the settings and then introduce it on plugin import?

[abeverley]

Thanks for the reply @sawyerx

What if you the import-time configuration in the settings and then
introduce it on plugin import?

Potentially, but:

• the problem is also that functions can no longer be imported, whereas they can with the current plugin system
• I'm trying to replicate the functionality of the parent module as closely is possible, which I think would potentially be quite desirable for other modules. Let's say you have module Foo::Bar and you want a Dancer2 specific version. At the moment you can create Dancer2::Plugin::FooBar and have exactly the same functionality as the original module (functions, options etc), but with Dancer2 specifics. That's what I'm doing with Log::Report - it has quite a few functions and options, which I'd like to be able to use with the plugin exactly as can be used with the main module. Sure, I could maybe export the functions as plugin keywords (although I'm not 100% sure), but then I've got to keep a whole bunch of keywords in sync with the main module, and you also lose the ability to selectively import.

So, given that the functionality is both present in the current architecture and (IMHO) desirable, I would be grateful if it could be retained.

Thanks,

Andy

[abeverley]

Correction: I can import functions with the method detailed in the previous comment. The other comments still stand though. Thanks.