Cannot instal Dancer2-Plugin-Passphrase-v2.0.4 - No DSL object found
So I decided I'll try to migrate the code behind the Perl Maven site from Dancer to Dancer2 First thing was to install Dancer2 which went fine. The second was to install Dancer2-Plugin-Passphrase I got the following error.: Anyone with a quick suggestion how to solve this? cpanm (App::cpanminus) 1.6937 on perl 5.020001 built for darwin-thread-multi-2level Work directory is /Users/gabor/.cpanm/work/1418214682.4823 You have make /usr/bin/make You have LWP 6.08 You have /usr/bin/tar: bsdtar 2.8.3 - libarchive 2.8.3 You have /usr/bin/unzip Searching Dancer2::Plugin::Passphrase on cpanmetadb ... --> Working on Dancer2::Plugin::Passphrase Fetching http://www.cpan.org/authors/id/H/HV/HVOERS/Dancer2-Plugin-Passphrase-2.0.4.t... -> OK Unpacking Dancer2-Plugin-Passphrase-2.0.4.tar.gz Entering Dancer2-Plugin-Passphrase-2.0.4 Checking configure dependencies from META.json Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Configuring Dancer2-Plugin-Passphrase-v2.0.4 Running Makefile.PL Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for Dancer2::Plugin::Passphrase Writing MYMETA.yml and MYMETA.json -> OK Checking dependencies from MYMETA.json ... Checking if you have Digest::SHA 5.74 ... Yes (5.92) Checking if you have Module::Pluggable 5.1 ... Yes (5.1) Checking if you have Dancer2 0.153002 ... Yes (0.156001) Checking if you have Data::Entropy 0.007 ... Yes (0.007) Checking if you have Test::More 0 ... Yes (1.001002) Checking if you have Digest::Bcrypt 0 ... Yes (1.0.1) Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Building and testing Dancer2-Plugin-Passphrase-v2.0.4 cp lib/Dancer2/Plugin/Passphrase.pm blib/lib/Dancer2/Plugin/Passphrase.pm Manifying blib/man3/Dancer2::Plugin::Passphrase.3 PERL_DL_NONLAZY=1 /Users/gabor/perl5/perlbrew/perls/perl-5.20.1_WITH_THREADS/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/ar ch')" t/*.t t/001_basics.t ...................... ok t/002_pod_coverage.t ................ ok No DSL object found at /Users/gabor/.cpanm/work/1418214682.4823/Dancer2-Plugin-Passphrase-2.0.4/blib/lib/Dancer2/Plugin/Passphrase.pm line 475. # Looks like your test exited with 255 before it could output anything. t/003_default_settings.t ............ Dubious, test returned 255 (wstat 65280, 0xff00) Failed 3/3 subtests No DSL object found at /Users/gabor/.cpanm/work/1418214682.4823/Dancer2-Plugin-Passphrase-2.0.4/blib/lib/Dancer2/Plugin/Passphrase.pm line 479. # Looks like your test exited with 255 before it could output anything. t/004_all_algorithm_matching.t ...... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 26/26 subtests ......
On Wed, 10 Dec 2014, Gabor Szabo wrote:
So I decided I'll try to migrate the code behind the Perl Maven site from Dancer to Dancer2 First thing was to install Dancer2 which went fine. The second was to install Dancer2-Plugin-Passphrase
I got the following error.: Anyone with a quick suggestion how to solve this? [snip error]
Sawyer X is working on a new API. I havn't got his patches yet... -- Henk
On Wed, 10 Dec 2014, Henk van Oers wrote:
On Wed, 10 Dec 2014, Gabor Szabo wrote:
So I decided I'll try to migrate the code behind the Perl Maven site from Dancer to Dancer2 First thing was to install Dancer2 which went fine. The second was to install Dancer2-Plugin-Passphrase
I got the following error.: Anyone with a quick suggestion how to solve this? [snip error]
Sawyer X is working on a new API. I havn't got his patches yet...
Got them, merged on Github, dist to Pause. Thank you Sawyer! Let's see what the CPAN-testers have to say about v2.0.5 :-) -- Henk
On Fri, Dec 12, 2014 at 2:01 PM, Henk van Oers <hvo.pm@xs4all.nl> wrote:
Got them, merged on Github, dist to Pause.
Thank you Sawyer!
Let's see what the CPAN-testers have to say about v2.0.5 :-)
I managed to install on both OSX and Linux. thank you! Gabor
Cheers to Henk for taking over the project and pinging me to chip in. On Fri, Dec 12, 2014 at 1:04 PM, Gabor Szabo <gabor@szabgab.com> wrote:
On Fri, Dec 12, 2014 at 2:01 PM, Henk van Oers <hvo.pm@xs4all.nl> wrote:
Got them, merged on Github, dist to Pause.
Thank you Sawyer!
Let's see what the CPAN-testers have to say about v2.0.5 :-)
I managed to install on both OSX and Linux.
thank you!
Gabor
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Finally I got to the point where I was actually testing the part where Dancer2::Plugin::Passphrase is used and I think I there is a change from the API of Dancer::Plugin::Passphrase It seems that the 'generate' method of the new module return a Dancer2::Plugin::Passphrase::Hashed object and does not stringify to the rfc2307 value as happened in the case of the Dancer1 version. Looking at the documentation I see both say that I should store the ->rfc2307 value, but because of the stringification I have missed that earlier. If you decided to not include the stringification, then maybe this should be emphasized in the docs as well. Gabor
Actually, I just noticed the documentation of both modules (Dancer:: and Dancer2::) have this in their pod: "For convenience the object will automagically return the RFC 2307 representation when no method is called on it." Which means it should still stringify to the rfc2307 value. Gabor On Sun, Dec 14, 2014 at 11:26 AM, Gabor Szabo <gabor@szabgab.com> wrote:
Finally I got to the point where I was actually testing the part where Dancer2::Plugin::Passphrase is used and I think I there is a change from the API of Dancer::Plugin::Passphrase
It seems that the 'generate' method of the new module return a Dancer2::Plugin::Passphrase::Hashed object and does not stringify to the rfc2307 value as happened in the case of the Dancer1 version.
Looking at the documentation I see both say that I should store the ->rfc2307 value, but because of the stringification I have missed that earlier.
If you decided to not include the stringification, then maybe this should be emphasized in the docs as well.
Gabor
You're right. I removed the stringification when redoing the API. I didn't return it and the docs still retain that message. I'm still not sure whether it should stringify. That's always a source of trouble. We could stringify with a deprecation or just keep it. What is your opinion? (other than that the docs should be up-to-date :) On Sun, Dec 14, 2014 at 11:46 AM, Gabor Szabo <gabor@szabgab.com> wrote:
Actually, I just noticed the documentation of both modules (Dancer:: and Dancer2::) have this in their pod:
"For convenience the object will automagically return the RFC 2307 representation when no method is called on it."
Which means it should still stringify to the rfc2307 value.
Gabor
On Sun, Dec 14, 2014 at 11:26 AM, Gabor Szabo <gabor@szabgab.com> wrote:
Finally I got to the point where I was actually testing the part where Dancer2::Plugin::Passphrase is used and I think I there is a change from the API of Dancer::Plugin::Passphrase
It seems that the 'generate' method of the new module return a Dancer2::Plugin::Passphrase::Hashed object and does not stringify to the rfc2307 value as happened in the case of the Dancer1 version.
Looking at the documentation I see both say that I should store the ->rfc2307 value, but because of the stringification I have missed that earlier.
If you decided to not include the stringification, then maybe this should be emphasized in the docs as well.
Gabor
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
IMHO stop the stringification (with some warning) and remove it from the pod as well. (and add it to the Migration document as well). Gabor On Sun, Dec 14, 2014 at 2:27 PM, Sawyer X <xsawyerx@gmail.com> wrote:
You're right. I removed the stringification when redoing the API. I didn't return it and the docs still retain that message.
I'm still not sure whether it should stringify. That's always a source of trouble.
We could stringify with a deprecation or just keep it. What is your opinion? (other than that the docs should be up-to-date :)
On Sun, Dec 14, 2014 at 11:46 AM, Gabor Szabo <gabor@szabgab.com> wrote:
Actually, I just noticed the documentation of both modules (Dancer:: and Dancer2::) have this in their pod:
"For convenience the object will automagically return the RFC 2307 representation when no method is called on it."
Which means it should still stringify to the rfc2307 value.
Gabor
On Sun, Dec 14, 2014 at 11:26 AM, Gabor Szabo <gabor@szabgab.com> wrote:
Finally I got to the point where I was actually testing the part where Dancer2::Plugin::Passphrase is used and I think I there is a change from the API of Dancer::Plugin::Passphrase
It seems that the 'generate' method of the new module return a Dancer2::Plugin::Passphrase::Hashed object and does not stringify to the rfc2307 value as happened in the case of the Dancer1 version.
Looking at the documentation I see both say that I should store the ->rfc2307 value, but because of the stringification I have missed that earlier.
If you decided to not include the stringification, then maybe this should be emphasized in the docs as well.
Gabor
This shouldn't be in the migration document since it isn't Dancer core, it's just a plugin API change. The plugin should indicate it. I also support removing the stringification. If a warning is to produced, it means stringification should either be allowed with a warning, or cause a croak instead. Henk, what do you think? On Sun, Dec 14, 2014 at 1:36 PM, Gabor Szabo <gabor@szabgab.com> wrote:
IMHO stop the stringification (with some warning) and remove it from the pod as well. (and add it to the Migration document as well).
Gabor
On Sun, Dec 14, 2014 at 2:27 PM, Sawyer X <xsawyerx@gmail.com> wrote:
You're right. I removed the stringification when redoing the API. I didn't return it and the docs still retain that message.
I'm still not sure whether it should stringify. That's always a source of trouble.
We could stringify with a deprecation or just keep it. What is your opinion? (other than that the docs should be up-to-date :)
On Sun, Dec 14, 2014 at 11:46 AM, Gabor Szabo <gabor@szabgab.com> wrote:
Actually, I just noticed the documentation of both modules (Dancer:: and Dancer2::) have this in their pod:
"For convenience the object will automagically return the RFC 2307 representation when no method is called on it."
Which means it should still stringify to the rfc2307 value.
Gabor
On Sun, Dec 14, 2014 at 11:26 AM, Gabor Szabo <gabor@szabgab.com> wrote:
Finally I got to the point where I was actually testing the part where Dancer2::Plugin::Passphrase is used and I think I there is a change from the API of Dancer::Plugin::Passphrase
It seems that the 'generate' method of the new module return a Dancer2::Plugin::Passphrase::Hashed object and does not stringify to the rfc2307 value as happened in the case of the Dancer1 version.
Looking at the documentation I see both say that I should store the ->rfc2307 value, but because of the stringification I have missed that earlier.
If you decided to not include the stringification, then maybe this should be emphasized in the docs as well.
Gabor
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Sun, Dec 14, 2014 at 4:16 PM, Sawyer X <xsawyerx@gmail.com> wrote:
This shouldn't be in the migration document since it isn't Dancer core, it's just a plugin API change. The plugin should indicate it.
Ostensibly you are right, but as a user I view the whole Dancer ecosystem as a single thing and I'd certainly appreciate if I had all the information in one place when I start to upgrade. Gabor
On 12/14/2014 04:19 PM, Gabor Szabo wrote:
On Sun, Dec 14, 2014 at 4:16 PM, Sawyer X <xsawyerx@gmail.com <mailto:xsawyerx@gmail.com>> wrote:
This shouldn't be in the migration document since it isn't Dancer core, it's just a plugin API change. The plugin should indicate it.
Ostensibly you are right, but as a user I view the whole Dancer ecosystem as a single thing and I'd certainly appreciate if I had all the information in one place when I start to upgrade.
Gabor
Yeah, I agree to that. This can go into the Plugin section. At least we should include links to plugins which additional migration information. Regards Racke -- Modern Perl, Dancer and eCommerce consulting.
The problem is that it makes us accountable for every plugin, and I definitely don't want that. It's great to see Dancer as an ecosystem but we can't account for all plugins, their changes, their authors, their design, and their problems. We would need to keep our documentation up-to-date on all plugins and I'm not sure that's a good idea. I think racke's suggestion of providing a place to list plugin information (such as "we know these exist" or perhaps "the following are known to work on the latest version", etc.) but this has been proven difficult to maintain. Hell, the module we used to check whether plugins started having problems at some point too. While I understand the desire, I'm not sure it's something we can and should be doing. (not that I'm saying no, I'm simply raising the problem with it because I don't know what to do with it yet.) On Sun, Dec 14, 2014 at 4:27 PM, Stefan Hornburg (Racke) <racke@linuxia.de> wrote:
On 12/14/2014 04:19 PM, Gabor Szabo wrote:
On Sun, Dec 14, 2014 at 4:16 PM, Sawyer X <xsawyerx@gmail.com <mailto:
xsawyerx@gmail.com>> wrote:
This shouldn't be in the migration document since it isn't Dancer
core, it's just a plugin API change. The plugin should indicate it.
Ostensibly you are right, but as a user I view the whole Dancer
ecosystem as a single thing and
I'd certainly appreciate if I had all the information in one place when I start to upgrade.
Gabor
Yeah, I agree to that. This can go into the Plugin section. At least we should include links to plugins which additional migration information.
Regards Racke
-- Modern Perl, Dancer and eCommerce consulting. _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
How about requiring plugin authors to post a specially tagged compatibility notice? then a script could gather, sort and display those sections from the authors, and tell the porter which plugin to investigate himself if the author has not made the section. Niels L On Sun, 2014-12-14 at 16:46 +0100, Sawyer X wrote:
The problem is that it makes us accountable for every plugin, and I definitely don't want that.
It's great to see Dancer as an ecosystem but we can't account for all plugins, their changes, their authors, their design, and their problems. We would need to keep our documentation up-to-date on all plugins and I'm not sure that's a good idea.
I think racke's suggestion of providing a place to list plugin information (such as "we know these exist" or perhaps "the following are known to work on the latest version", etc.) but this has been proven difficult to maintain. Hell, the module we used to check whether plugins started having problems at some point too.
While I understand the desire, I'm not sure it's something we can and should be doing. (not that I'm saying no, I'm simply raising the problem with it because I don't know what to do with it yet.)
The migration document will never be "perfect". It cannot cover all the cases people have incorrectly used (mis)-features of Dancer 1 (see how I used request->referer), just as the documentation of Dancer will never be perfect. Just slap a "known issues in the migration process" at the top of the pod and when someone complains that some case was not covered, congratulate for being the first to encounter the issue ask politely for a pull request. I am sure the license already say that this software is provided "as is" without any implied liability and I don't think everything needs to be automated. Gabor
On Sun, 14 Dec 2014, Sawyer X wrote:
This shouldn't be in the migration document since it isn't Dancer core, it's just a plugin API change. The plugin should indicate it. I also support removing the stringification. If a warning is to produced, it means stringification should either be allowed with a warning, or cause a croak instead.
Henk, what do you think?
I don't know how many D1 users use the stringification. To ease the migration I would like: - allow stringification with a 'warn' call - a deprecation note in the documentation - new version 2.0.6 - remove the stringification in version 3.0.0 -- Henk
On Sun, Dec 14, 2014 at 1:36 PM, Gabor Szabo <gabor@szabgab.com> wrote: IMHO stop the stringification (with some warning) and remove it from the pod as well.(and add it to the Migration document as well). Gabor
On Sun, Dec 14, 2014 at 2:27 PM, Sawyer X <xsawyerx@gmail.com> wrote: You're right. I removed the stringification when redoing the API. I didn't return it and the docs still retain that message. I'm still not sure whether it should stringify. That's always a source of trouble.
We could stringify with a deprecation or just keep it. What is your opinion? (other than that the docs should be up-to-date :)
On Sun, Dec 14, 2014 at 11:46 AM, Gabor Szabo <gabor@szabgab.com> wrote: Actually, I just noticed the documentation of both modules (Dancer:: and Dancer2::) have this in their pod: "For convenience the object will automagically return the RFC 2307 representation when no method is called on it."
Which means it should still stringify to the rfc2307 value.
Gabor
On Sun, Dec 14, 2014 at 11:26 AM, Gabor Szabo <gabor@szabgab.com> wrote: Finally I got to the point where I was actually testing the part where Dancer2::Plugin::Passphrase is used and I think I there is a change from the API of Dancer::Plugin::Passphrase
It seems that the 'generate' method of the new module return a Dancer2::Plugin::Passphrase::Hashed object and does not stringify to the rfc2307 value as happened in the case of the Dancer1 version.
Looking at the documentation I see both say that I should store the ->rfc2307 value, but because of the stringification I have missed that earlier.
If you decided to not include the stringification, then maybe this should be emphasized in the docs as well.
Gabor
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
That sounds reasonable. If I can help please let me know. :) On Mon, Dec 15, 2014 at 10:46 AM, Henk van Oers <hvo.pm@xs4all.nl> wrote:
On Sun, 14 Dec 2014, Sawyer X wrote:
This shouldn't be in the migration document since it isn't Dancer core,
it's just a plugin API change. The plugin should indicate it. I also support removing the stringification. If a warning is to produced, it means stringification should either be allowed with a warning, or cause a croak instead.
Henk, what do you think?
I don't know how many D1 users use the stringification. To ease the migration I would like:
- allow stringification with a 'warn' call - a deprecation note in the documentation - new version 2.0.6 - remove the stringification in version 3.0.0
-- Henk
On Sun, Dec 14, 2014 at 1:36 PM, Gabor Szabo <gabor@szabgab.com> wrote:
IMHO stop the stringification (with some warning) and remove it from the pod as well.(and add it to the Migration document as well).
Gabor
On Sun, Dec 14, 2014 at 2:27 PM, Sawyer X <xsawyerx@gmail.com> wrote: You're right. I removed the stringification when redoing the API. I didn't return it and the docs still retain that message. I'm still not sure whether it should stringify. That's always a source of trouble.
We could stringify with a deprecation or just keep it. What is your opinion? (other than that the docs should be up-to-date :)
On Sun, Dec 14, 2014 at 11:46 AM, Gabor Szabo <gabor@szabgab.com> wrote: Actually, I just noticed the documentation of both modules (Dancer:: and Dancer2::) have this in their pod: "For convenience the object will automagically return the RFC 2307 representation when no method is called on it."
Which means it should still stringify to the rfc2307 value.
Gabor
On Sun, Dec 14, 2014 at 11:26 AM, Gabor Szabo <gabor@szabgab.com> wrote: Finally I got to the point where I was actually testing the part where Dancer2::Plugin::Passphrase is used and I think I there is a change from the API of Dancer::Plugin::Passphrase
It seems that the 'generate' method of the new module return a Dancer2::Plugin::Passphrase::Hashed object and does not stringify to the rfc2307 value as happened in the case of the Dancer1 version.
Looking at the documentation I see both say that I should store the ->rfc2307 value, but because of the stringification I have missed that earlier.
If you decided to not include the stringification, then maybe this should be emphasized in the docs as well.
Gabor
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________
dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
participants (5)
-
Gabor Szabo -
Henk van Oers -
Niels Larsen -
Sawyer X -
Stefan Hornburg (Racke)