Breaks with Dancer 2
racke opened this issue · 8 comments
PERL_DL_NONLAZY=1 /home/racke/perl5/perlbrew/perls/perl-5.17.6/bin/perl5.17.6 "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
Subroutine Dancer::Plugin::Auth::Extensible::import redefined at /home/racke/perl5/perlbrew/perls/perl-5.17.6/lib/5.17.6/Exporter.pm line 33, <DATA> line 16.
# Testing Dancer::Plugin::Auth::Extensible 0.03, Perl 5.017006, /home/racke/perl5/perlbrew/perls/perl-5.17.6/bin/perl5.17.6
t/00-load.t ...... ok
Subroutine Dancer::Plugin::Auth::Extensible::import redefined at /home/racke/perl5/perlbrew/perls/perl-5.17.6/lib/5.17.6/Exporter.pm line 33.
Invalid CODE attribute: RequireLogin at t/lib/TestApp.pm line 20.
BEGIN failed--compilation aborted at t/lib/TestApp.pm line 20.
Compilation failed in require at t/01-basic.t line 5.
BEGIN failed--compilation aborted at t/01-basic.t line 5.
t/01-basic.t .....
Dubious, test returned 255 (wstat 65280, 0xff00)
Hi,
Are there any plans to migrate Dancer::Plugin::Auth::Extensible to Dancer2?
I'm happy to start trying to hack it myself (although I'd probably need a pointer or two), but wanted to check about any upcoming plans first.
Thanks,
Andy
D2 support is planned, but I've no idea when I'll have any time. If you're willing to contribute to the effort, that would be great :)
I imagine we'd need to take a similar approach to Dancer::Plugin::Database, which was split into a shared "core" where all the actual work is done, and Dancer1 & Dancer2 plugin modules to make use of it.
Okay, I've made a start. Do you have time to answer questions? If so, here's the first:
I see that in Plugin::Database you perform all the registration of the plugin functions and hooks in the specific Dancer1/Dancer2 files. Is this the only way to do it? The reason I ask is that there are a lot of functions to register for Auth::Extensible, and that will mean a lot of code repeated between the two sets of files.
Ideally I would register them in one of the core files, but that doesn't work without useing Dancer::Plugin or Dancer2::Plugin (and I don't see any way of knowing which one to include?).
Thanks,
Andy
Hmmm, I'm beginning to think that it might actually be better to have 2 completely separate modules. Almost all the functions in Extensible.pm rely on Dancer/Dancer2 functions, and a couple of the providers do as well (Database and LDAP). Therefore, unless there is a better way of doing it, there is going to be a lot of duplication of code, which will probably over-complicate things more than it is worth it.
Thoughts?
Hmm, off the top of my head, there's no reason that Provider modules need to be using Dancer functions, so ideally there'd be a shared core that calls the Provider module(s) in a uniform way regardless of the Dancer version in use.
I'd much rather it be possible for someone to write a Provider class which will Just Work on both versions of Dancer.
I need to find time to sit down and think about this in more detail, but unfortunately I'm back at work today.
In terms of core Dancer functions, it's actually only the logging calls that are used by LDAP and Database (which I'm sure could be changed).
The problem is that Provider::Database uses all the various Plugin::Database functions, and then you're into the same problems as above.
I'm happy doing the donkey work for this migration; I just need a pointer in the right direction! Thanks.
+1 for making it work under Dancer2. Also willing to contribute. Create a Dancer2::Plugin::Auth::Extensible like other plugins?
Not an issue for Dancer::Plugin::Auth::Extensible any more.