Framework agnostic about merchant

[tuxcanfly]

Hi Theju,

+1 on the approach you're taking, I think it's in the right direction.

• What do you think about structuring the framework-specific stuff as merchant/contrib/django and merchant/contrib/flask? I'm looking at raven-python which has a similar layout /bikeshedding
• What do you think about having a base class which transmits the signals since it's common to all the gateways? https://github.com/theju/merchant/blob/framework-agnostic/django-merchant/billing/gateways/stripe_gateway.py
• Just a point to note - if we have m gateways and n frameworks, we'll need to support mxn cases. Sounds unavoidable.

I'll be taking a closer look later this week.

Thanks.

[theju]

What do you think about structuring the framework-specific stuff as merchant/contrib/django and merchant/contrib/flask? I'm looking at raven-python which has a similar layout /bikeshedding

So when merchant is installed, the contrib backends also get installed?

What do you think about having a base class which transmits the signals since it's common to all the gateways? https://github.com/theju/merchant/blob/framework-agnostic/django-merchant/billing/gateways/stripe_gateway.py

Good idea.

Just a point to note - if we have m gateways and n frameworks, we'll need to support mxn cases. Sounds unavoidable.

Can't really help it.

[tuxcanfly]

Building on @theju 's work, restructured the project, fixed stripe gateway.

https://github.com/tuxcanfly/merchant/tree/framework-agnostic

[tuxcanfly]

https://travis-ci.org/tuxcanfly/merchant/builds/7428915

We had ~100 tests earlier, 38 passing in the above branch - so we're 38% there... ✋

[tuxcanfly]

Hit a roadblock with paypal pro gateway because we're currently using django-paypal for it.

paypal-python looks more more equally well maintained and is pure python so maybe we should use this.

https://github.com/duointeractive/paypal-python

[tuxcanfly]

Done migrating all gateways except paypal:

https://travis-ci.org/tuxcanfly/merchant/builds/7495359

Need to think how we're going to handle integrations, since they are more dependant on django.

[theju]

You may want to check the links below:
https://github.com/theju/merchant/blob/framework-agnostic/django-merchant/billing/integrations/stripe_integration.py
https://github.com/theju/merchant/blob/framework-agnostic/flask-merchant/flask_merchant/integrations/stripe_integration.py

[tuxcanfly]

OK, seen that, but still not convinced if we need a base class like this:

https://github.com/theju/merchant/blob/framework-agnostic/merchant/merchant/integration.py#L13

[tuxcanfly]

I think we need better abstraction around the integration classes. We're trying to fit too much (urls, views) in the integration class, and this is leading to choices like logic in the urls, or monkey-patching urlpatterns. We should probably move the urls out of the integration class and make it easier to construct a class based view / route handler.

https://github.com/agiliq/merchant/blob/master/example/app/urls.py#L6

https://github.com/tuxcanfly/merchant-django-demo/blob/master/example/app/views.py#L75

A better abstraction is also required to keep payment logic in the base class and framework logic (urls, views, templates) in the contrib implementations.

[tarkatronic]

I'm curious, is there an ETA on this? I have a major project which will be launching within the next couple of months using merchant and django-paypal. But if things are going to shift toward paypal-python soon, I would rather try to test and launch with that if possible.

[tuxcanfly]

We're almost there, there's a few design decisions pending on how to handle integrations in a cross-framework way. No ETA at the moment, but I'll try to work on it over the next weekend.