Kavorka requires Perl >= 5.014

[srchulo]

I can't install Net::Stripe on any of my machines because Kavorka requires Perl >= 5.014. Since you're just using it for method signatures, is there any other method signatures model that would suffice?

[rustyconover]

Well, all the other signature methods really slow down parsing and running code.

We were using MooseX::Method::Signatures but it's implementation causes the startup time to be at least two seconds when running my tests because it uses a source filter.

It is impossible to upgrade? 5.20 was released today.

Rusty

[NacreData]

Hm, yeah, my system is running 5.12. Long-term stability has been one of the strengths of perl for me.

[srchulo]

If it's really the best one to use, I completely understand. I could try upgrading, just a little hesitant because it's on my production machines and I've tried upgrading perl before and broken some things :)

I'm using this in a persistent environment, so Moose wouldn't really be a problem for me. Maybe I'll just use an older version of Net::Stripe.

[rustyconover]

The functionality is mostly equal between the modules, except for the startup time difference.

There doesn’t appear to be a cute way to fall back between the modules.  I’d be all for that.

Rusty

--  Rusty Conover Lucky Dinosaur, LLC.

On May 27, 2014 at 11:50:36 AM, Adam Hopkins ([email protected]) wrote:

If it's really the best one to use, I completely understand. I could try upgrading, just a little hesitant because it's on my production machines and I've tried upgrading perl before and broken some things :)

I'm using this in a persistent environment, so Moose wouldn't really be a problem for me. Maybe I'll just use an older version of Net::Stripe.

— Reply to this email directly or view it on GitHub.

[srchulo]

I think that maybe moving to a module that requires 5.14 might be a little too soon. Most systems still come with < 5.14, and it's often dangerous to mess with the system perl. I'm running the newest CentOS version (6.5), and it only comes with version 5.10.1. I've tried upgrading perl before, but it tends to break a lot of stuff since perl is used so widely/deep in the system. It's made my machines unusable and I've had to revert back to an older image of that machine. I think that for a lot of people requiring perl 5.14 might make this module unusable. Also, the author of Kavorka says that it is potentially very buggy, and he might change the syntax in the future: "Kavorka is still at a very early stage of development; there are likely to be many bugs that still need to be shaken out. Certain syntax features are a little odd and may need to be changed in incompatible ways." MooseX::Method::Signatures will cause a slower load time, but it might be overall more stable and allow more people to use the module.

I know you've already switched to Kavorka and been using it for 3 versions, and if you think still using Kavorka is the right call, then that's fine with me! I just wanted to make my case :)

[andrewsolomon]

Hi Adam, regarding the upgrade to system Perl my principle is: don't touch it!:) Whenever I'm putting my own app on a server, I use perlbrew http://perlbrew.pl/ to install a Perl used only by the app. This way I can install whatever I want without affecting the host system. For even more control of the exact module versions you can then use Pinto (see http://perlmaven.com/pinto-tutorial ) or even easier - Stratopan https://stratopan.com/

[NacreData]

So using an app-specefic Perl version is one answer. Probably pretty heavy-weight, and problematic in some environments such as some mod_perl installs where you don't want the bulk of perl available inside a jail/chroot once the long-running process is up and going.

Other solutions might be to start a fork using MooseX::Method::Signatures (and maybe try to look into making that faster) or perhaps looking into Kavorka to isolate out what we are actually using and what actually needs 5.14 to see if we can use a fork of some part of Kavorka which is more backward compatible. I also run many systems with older version of Perl, so I'll be willing to contribute to and help maintain a fork of this project if that seems wise. Would love to see as much consensus on the approach to take as possible before heading off in that direction.

devin

contact info: http://nacredata.com/devin gpg public key: http://www.nacredata.com/public_key.txt Use a Strong Password! https://www.nacredata.com/password.php

[srchulo]

I would also be willing to help contribute to a fork if we couldn't find another way around it. perlbrew might be a good solution, but I would definitely prefer to just be able to use my system perl.

[tobyink]

@NacreData, you wrote:

looking into Kavorka to isolate out what we are actually using and what actually needs 5.14 to see if we can use a fork of some part of Kavorka which is more backward compatible.

I'm the primary author of Kavorka. If there were any sensible way to support older versions of Perl in Kavorka, believe me, I would! I've gained somewhat of a reputation as a crazy antiquarian by continuing to support Perl 5.6.x for several of my modules.

Kavorka uses the Perl keyword API, which was only introduced in Perl 5.14. It could not easily be backported to any earlier version of Perl.

There are modules providing method signatures for earlier Perl versions - these use either source filters or Devel::Declare (which is more reliable than a source filter, but less reliable than the keyword API). If you wanted to use one of these, I'd recommend Method::Signatures. It benchmarks relatively close to Kavorka in terms of performance, and has a mostly similar syntax.

[rustyconover]

Since I was the one that put Kavorka in Net::Stripe. I had three primary reasons:

1. Writing type checking code is boring, and repetitive and prone to error. My doing everything in the method declaration is much simpler.
2. Dealing with payments, we don't want to have someone misspell a parameter name and just silently drop that parameter. Kavorka's parameter checking is great for this.
3. Using a source filter on a Dancer app that uses Net::Stripe with a lot of code is really really slow to parse and start, and running many test units becomes a real drag because a lot of the time will be starting and stopping the app.

In Amazon::DynamoDB, I've fully used Type::Tiny to really leverage these checks so I plan to revisit Net::Stripe to be a bit stricter now about typing and optional parameters to the methods. I really want Net::Stripe to be bulletproof, since we are dealing with money and credit cards.

[NacreData]

That is tremendously useful information, @tobyink -- thank-you.

The things you say are worth-while, Rusty, and there clearly should be a version of this code that uses the latest tools to deliver the best possible product. But I think it remains unrealistic to think every person needing to use Stripe payments will have Perl 5.14 or newer. It's simply not the case.

So I guess the question comes down to just how similar the syntax is with Method::Signatures, and how much work it will be to maintain branches for each. Probably need to just try.

[tobyink]

There is a very large overlap in syntax. (This is intentional.)

Buddy Burden (one of the maintainers of Method::Signatures) and I did discuss the possibility of some kind of Any::Signatures module which loads Kavorka on Perl 5.14+ and Method::Signatures on older Perls. Of course if people wanted to use that, it would be their own responsibility to ensure they stuck to that subset of signature syntax that overlaps.

[yahermann]

+1 on removing the Kavorka dependency, if possible. At least for now, until Kavorka matures a bit more.

1. From the author's website: "Kavorka is not especially stable". Not reassuring words as relates to a payment system.
2. Kavorka has way too many non-core dependencies. They appear to be early versions, many have to be installed manually, and one has been deprecated. Makes installation by a novice impossible, which makes use of Net::Stripe by a novice impossible. Also all of those non-core dependencies add a serious layer of potential instability in a production system.

I'm using Perl 5.18.2. Somewhere between novice and advanced.

[rustyconover]

@yahermann thanks for your comment, but refer to my previous discussion regarding why I'm going to keep Kavorka. It has saved me hundreds of hours by now in my projects. I'm not going to fall into the trap of "stop energy" regarding forward progress. Feel free to send a PR with an optional switch to not use Kavorka.

1. It has been stable for me, and I've been using it for about a year in all of my projects. And Toby has been very quick to reply to any problems.
2. It's so easy to install cpanm Kavorka. I'd make it easier if it wasn't already a one liner. If you install Net::Stripe via CPAN it handles everything for you.

[yahermann]

@rustyconover thanks for your response.

I did try installing Net::Stripe using CPAN, and ran into all sorts of problems related to its dependency to Kavorka, requiring manual installation of several Kavorka dependencies. Hence the urge to post my comment.

I totally understand your sentiment, I was just pointing out that this particular dependency and all the installation problems I experienced, make Net::Stripe less accessible to novices and less stable in a production environment involving payments (or at least inspires less confidence, notwithstanding your earlier comments about better stability which do make sense to me) .

FWIW, I think Kavorka is a great idea, an amazing time-saver as you pointed out, and I hope it eventually matures into core. And just to be clear, I haven't lost sight of the fact that Net::Stripe exists, thanks to you.

[resynthesize]

Just a +1 that my company also cannot use Net::Stripe due to the kavorka 5.14 dependency. We're on CentOS 6 w/ 5.10. Offering a fallback option for older perls would be great.

[daveaiello]

I agree with resynthesize. We had a site set up that used Net::Stripte before the Kavorka dependency crept in. We can't rebuild the entire site on a new version of CentOS just to get to a version of Perl that's compatible with Kavorka.

[NacreData]

I am successfully using Stripe::Perl on several systems with old Perl using http://perlbrew.pl

It looks to me like removing this dependency would be a significant fork of the project. It's on my opensource/volunteer to-do list. If i get around to it, I would probably strip out a ton of other dependencies which are not strictly necessary. But things can linger on my unpaid to-do list for a rather long time, so I'd certainly encourage using a non-system Perl or devoting resources from your company to begin such a fork if needed.

[dmaglinte]

I'm using perlbrew perl-5.14.4. I was able to install perl, Net::Stripe and all dependencies fine but I get this error when running the stripe test (live.t):

Use of uninitialized value $e in die at ../lib/Net/Stripe.pm line 1541. malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "LWP will support htt...") at ../lib/Net/Stripe.pm line 1529. ...propagated at ../lib/Net/Stripe.pm line 1541.

When I run the same code on my local machine using active perl, I get no errors. Any ideas? When I comment out the affected lines, It gets in further JSON errors.

[NacreData]

That sounds like the when you are missing some of the SSL/TOS dependencies. There is one which does not cleanly the install, I noticed just the other day. I have not had enough chance to really documented well but my searching around seemed to indicate that it had to do with a test suite which was failing because of missing certificates or certificates which had the wrong bit length, and I was able to do a force install on the needed modules to make it work

devin

contact info: http://nacredata.com/devin

On Apr 14, 2015, at 19:03, dmaglinte [email protected] wrote:

I'm using perlbrew perl-5.14.4. I was able to install perl, Net::Stripe and all dependencies fine but I get this error when running the stripe test (live.t):

Use of uninitialized value $e in die at ../lib/Net/Stripe.pm line 1541. malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "LWP will support htt...") at ../lib/Net/Stripe.pm line 1529. ...propagated at ../lib/Net/Stripe.pm line 1541.

When I run the same code on my local machine using active perl, I get no errors. Any ideas? When I comment out the affected lines, It gets in further JSON errors.

— Reply to this email directly or view it on GitHub.

[dmaglinte]

Thanks Devin. Do you recommend that I just re-install Net::Stripe and dependencies and force the output a file to be able to identify the culprit?

[NacreData]

That could work if you could search through the output for SSL crypt or whatever it is that is not installing properly

devin

contact info: http://nacredata.com/devin

On Apr 14, 2015, at 19:26, dmaglinte [email protected] wrote:

Thanks Devin. Do you recommend that I just re-install Net::Stripe and dependencies and force the output a file to be able to identify the culprit?

— Reply to this email directly or view it on GitHub.

[dmaglinte]

For others on this thread running into issues installing Net::Stripe and opting to use perlbrew to install an older version of perl > 5.14 (to conform to Kavorka prerequisites), cpan does not install a dependency. Installing LWP::Protocol::https should fix the problem. This is a dependency of LWP::Request. Running lwp-request https://google.com/ in the command line should confirm this.

[youradds]

This is bonkers. I've just setup a who new server, just so I can use this module (as I was only on 5.10, which wasn't new enough for Kavorka. Anyway, EVERYTHING else works, apart from this module! I can't install Kavorka , as I get an error when compiling:

Running make test PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/.t t/01basic.t .................... ok t/02named-functions.t .......... Can't locate object method "_set_declared_name" via package "Kavorka::Sub::Fun" at /root/.cpan/build/Kavorka-0.037-ICCO4K/blib/lib/Kavorka/Sub.pm line 182. t/02named-functions.t .......... Dubious, test returned 255 (wstat 65280, 0xff00) No subtests run t/03anon-functions.t ........... Can't locate object method "declared_name" via package "Kavorka::Sub::Fun" at /root/.cpan/build/Kavorka-0.037-ICCO4K/blib/lib/Kavorka/Sub.pm line 48. t/03anon-functions.t ........... Dubious, test returned 255 (wstat 65280, 0xff00)

etc etc. After some digging, it seems like there is a bug with another module that Kavorka requires, that doesn't work with > 5.21.x . PLEASE tell me someone has created a version of Net::Stripe that doesn't require that module? This is doing my nut in!

Thanks

Andy

[srchulo]

Hey Andy,

I don't think there is another module. I don't know if this is an option for you or not, but I used perlbrew on my server and that allowed me to use this module with perl 5.22 and no issues.

[youradds]

Thanks. I ended up getting some help on PerlMonks with regards to patching Devel::CallParser, which in turn was stopping Kavorka from installing, and in turn stopping Net::Stripe from being installed. Here is the link, in case anyone else needs a pointer in the future:

http://perlmonks.org/?node_id=1186217

[strangelittlemonkey]

I'm getting hit by this trying to install with Perl 5.24.3

[yahermann]

I was just reviewing the source code, with an eye toward removing the Kavorka dependency.

Wouldn't this, for example:

    method post_charge(Int :$amount,
                       Str :$currency,
                       Net::Stripe::Customer|HashRef|Str :$customer?,
                       Net::Stripe::Card|Net::Stripe::Token|Str|HashRef :$card?,
                       Str :$description?,
                       HashRef :$metadata?,
                       Bool :$capture?,
                       Str :$statement_description?,
                       Int :$application_fee?
                     ) {
        my $charge = Net::Stripe::Charge->new(amount => $amount,
                                              currency => $currency,
                                              customer => $customer,
                                              card => $card,
                                              description => $description,
                                              metadata => $metadata,
                                              capture => $capture,
                                              statement_description => $statement_description,
                                              application_fee => $application_fee
                                          );
        return $self->_post('charges', $charge);
     }

Simply be a matter of changing to:

    sub post_charge {
       my ($self, $amount, $currency, $customer, $card, $description, $metadata, $capture, $statement_description, $application_fee) = @_;
       my $charge = Net::Stripe::Charge->new(amount => $amount,
                                              currency => $currency,
                                              customer => $customer,
                                              card => $card,
                                              description => $description,
                                              metadata => $metadata,
                                              capture => $capture,
                                              statement_description => $statement_description,
                                              application_fee => $application_fee
                                          );
       return $self->_post('charges', $charge);
    }

and then leaning on Moose's type constraints?

[sherrardb]

@yahermann, i may be missing something obvious here, but within the provided snippet, how would one "convert" the current Kavorka signatures into Moose type constraints?

[sherrardb]

@yahermann, indeed i was missing something obvious. after getting back to doing some coding, i see that the Moose type constraints are already in place, essentially mirroring the Kavorka signatures.

but i believe that your suggested approach still falls victim to the problems i highlighted in #80, namely that using a role-based architecture means that you cannot reliably pull in 'has' constraints without also adding a significant abstraction layer for object creation. please have a look at my comments from late October and early November 2017.