Oscar Ecommerce with David Winterbottom and Michael van Tellingen

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.

I would like to thank everyone who supports us on Patreon. Your contributions help to make the show sustainable.

When you're ready to launch your next project, you'll need somewhere to deploy it, so you should check out linode at www.podcastinit.com/linode

and get a $20 credit to try out their fast and reliable Linux virtual servers for running your app or experimenting with something that you hear about on the show.

You can visit the site at www.podcastinnit.com

to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch. To help other people find the show, please leave a review on Itunes or Google Play Music, tell your friends and coworkers, and share it on social media.

Before we start the show, I have a couple of announcements to make. First, I started a new Slack channel for guests and listeners of the show, which you can find at www.podcastinit.com/slack,

where you can join in the conversation.

2nd, if you are interested in how open source powers innovations in data, then you should check out the Open Source Data Science Conference. It's coming to Boston, Massachusetts on March 3rd through 5th, so don't miss out on your chance to level up and meet some new friends.

Your host as usual is Tobias Macy. And today, I'm interviewing David Winterbottom and Michael Van Tylengen about the Oscar framework for building ecommerce applications in Django. So could you please introduce yourselves?

David, how about you go first?

Sure. So I'm David Wintersbottom.

I've,

I've been a software engineer for about 10 years or something like that. So I work for a a UK energy supply at the moment called Optus Energy. I work for various other start ups and agencies in London over the last 10 years.

I mainly work in Python.

I guess I'm a small amount of coal miner these days.

And,

Yeah. And, Michael, how about you? Okay. Hi. I'm Mike.

So I live in the Netherlands. I'm a software engineer now for, well, professionally for also something like 10 years, I believe.

Python

also.

Started with Pro

really long time ago and doing Python now for, like, more than 10 years or so. And I'm freelancing now since 2 years, I believe.

And, David, do you remember how you first got introduced to Python?

Mainly working in PHP. I I mean, there's a lot of people do when we first get into kind of web programming. And,

I kind of learned a little bit of Python from going to conferences

and following things on what's it called, avenues and that kind of thing. I know that the big point was, I was working for an agency, and we were doing PHP projects. But we, we merged or acquired another agency who

use Django exclusively for all their projects. So I can remember being

increasingly

jealous of the of kind of Django and Python's kind of functionality and what I kind

of cleaner and,

nicer language it was in PHP.

And so I think that's how I got into it. That's when I realized that I personally wanted to switch from primarily doing PHP to Python, but also I want the company I was working for to switch from primarily using PHP to using Python.

So that's the journey I went through. I think it's quite a common 1. Now that I recruit people for Python, a lot of people I speak to have been on the same trajectory when we started in a in PHP, but moved over to Python once they, got more exposure to it. And, Michael, how about you?

So I started

Python, I think, 14, 15 years ago or something like. I was, I used to do PAP,

or Perl, actually, mostly.

Then I switched from company, and they, like, forced me to use Python. Mhmm. So there was a big switch from Perl to Python. Yeah. I love it ever doing it ever since, and it's still my favorite language,

mostly because, yeah, you can just express what you want to do.

So,

yeah. Long time.

So can you guys describe what Oscar is and the problem that you're trying to solve when it was first created?

Sure.

I think so to be clear, I mean, I

started OSCO in around 2010. But since I've changed jobs a few times, I haven't been that active with the project probably for getting over 2 years now or something like that. So let let let me talk about the start. So we're working in 1 of these agencies in London where we do lots of ecommerce projects of various clients of different sizes. And we were writing remote those projects in PHP using a kind of home rolled framework, like, an ecommerce framework and a

kind of HTTP framework.

And then, yeah, we acquired this agency doing Jango and see what a great,

kind of process you could go through for doing a kind of relatively small scale client project using Django. So Django lets you think about your data structures upfront, so your models in in Django terminology.

And if you get those right and you can talk to your clients and that and the things that kind of, iterate on them to, make her core data structures right, then so many things come out really nicely from that.

You know, Django will give you great support

on building forms and all that kind of thing and dashboards and list views and detail views and

And so

what I wanted to do was to kind of transport

our ecommerce experience

into Django to take advantage of this kind of, the the framework effects and all the things you've got with it.

And so so that's where hospice started to follow. It was really important of an internal,

actionable town shop. So it took a while to kind of detail shop everything, for Oscar as over the years. So the problem, I guess, returning to the current question, the problem we're trying to solve with that was to write a

framework for Django

that was quite agnostic about what kind of ecommerce story we're building. Because, you know, in my day job, you know, we start off building

kind of large scale book sites, whether it be several million products.

And you would have certain problems to solve in terms of handling all the stock updates and eventually updates from various kind of suppliers,

digesting feeds, and that kind of thing. So that was something you did 1 day, but the next day, you might want them to go bespoke ecommerce sites for,

let's see some kind of luxury products manufacturer. We work for some people doing kind of car stereos and fancy speakers and this kind of thing where the company might only actually sell 10 products in total, but every kind of product detail page is highly bespoke with kind of video content and all kinds of metadata around the product.

And it's quite challenging to write a framework that solves both those problems at the same time.

And we also have challenges around working in different countries and different kind of shipping rules and,

and tax rules, especially.

And so,

you know, the core of Oscar was to write something which is agnostic

about all these kind of decisions of the particular domain,

but let you customize it in a kind of a wise in an elegant way

to, to model the the domain you were trying to write a store for.

And to some extent, there's the question of, you know, in in some cases, wouldn't it have been easier to just write the different scales of ecommerce front ends,

at the time that they were needed rather than trying to encompass the entirety of ecommerce in a single framework. But I'm wondering

what the benefits are from having that degree of flexibility that allows you to encompass it all in that 1 project so that you do have the core primitives available for each project that you're working on.

Yeah. So you mean I think I mean, in the kind of agency environment that we're working in, there's obviously strong passion to deliver things very quickly

and having everyone across your development teams, you know, familiar with the same code base, the same approach. So there's advantages in having a kind of favored in house framework, but everyone knows how the the cart works, how delivery works, how you manage inventory,

and understands the kind of mechanisms for customizing it. So,

yeah, you're right. In some sense,

it would be

perhaps advantageous

to have a more,

start a bit more of a blank slate, I guess, with these projects and, just kind of pulling some components. But

given the kind of tight deadlines and the needs behind good quickly, it made a lot of sense to us to have a framework that kind of try and try and aim to solve, each or at least respectful enough to solve all of these problems. And it did build a lot for us. We did build lots of different very disparate

ecommerce laws based off,

this, you know, based on Oscar. And we managed, you know, we were successfully

kind of bending Oscar to model each of those moments even though they were quite different.

And you said that it was largely a port of an existing framework. I'm curious

if the prior frameworks started out as a conscious attempt to build that core building block,

or was it something that was just extracted from a number of different projects?

Yeah. No. No. That 1 was built just I mean, to start, it was built just to solve the problem

of a big UK bookstore, you know, with millions of products. And it, you know, had it is quite tight. Couple to the domain of bookstores, so it had kind of first class entities, kind of authors and publishers,

and and the kind of things that you see in that domain.

So when we have when we're trying to convert it to loss, so we have to kind of take a step back and say, actually, you know, it doesn't make sense for someone selling,

you know, something totally different, like tickets for events to have these things called authors and publishers knocking around in their systems.

So that's what I mean when we have to kind of divorce,

when we when we're inviting us, we have to kind of separate out what was specific to Telstra in these previous domains and what was truly

core to,

you know, most econ stores.

And when you were doing that port to writing rewriting it with Django, was it done with the intent of open sourcing it? Or was that something that was done after the fact after you had already gotten it fairly functional?

It kind of happened by accidents in a way. I think so I I kind of just wanted to do it because I want to learn Django a lot better. And I wanted

you know, I was frustrated with this PHP framework we're using. There's so many things I knew would write. So I kinda just for my own pleasure in a sense why it's a writer better framework in Django. So I did it on in my spare time, it wasn't sponsored by my company at that point, just in the very early days.

And, you know, at that point, the you know, if you wanted to put a post project on GitHub,

you have to pay for private ones, but it didn't for open source project ones. And so I did feel I paid for it. So I just,

I tried to open source from day 1, and that just kinda made sense. And then and when I kind of got to the point of convincing my agency to use it, you know, it was fairly easy to make the case for having it as an as

an open source framework. I mean, that was sometimes

a tricky challenge. It's something that got completely unfamiliar with the world of open source. We'll often kind of say, why are we giving this away for free? Why aren't we charging for, you know, like, a Moscow license or something like that? But, but that was

a a kind of argument we were able to win because they're natural benefits of the open source, create the outweigh whatever we could, the benefits that would have come to us in closed off approach.

And briefly, where does the name come from?

Well, I think I mean, Oscar was 1 of 1 of my first kind of,

projects in Django. I learned the impression at the time that all Django projects were named after jazz musicians.

So it really comes up to Oscar Peterson.

I then later realized that there was only, like, 3 out of several 100, Jenga packages that followed that convention. But, you know, it's actually quite nice. And then you also it's quite short and succinct.

It's worked well for us.

So

at face value, the idea of ecommerce seems fairly straightforward because you're just,

you know, you have a product and you want people to pay for it and then need to deliver it. But behind that, there's lurking a lot of incidental complexity

and domain specific considerations

for each particular company and how they manage selling their various products. So I'm wondering

what are some of the most challenging aspects of building and managing a web store and a framework to power it?

Definitely, the difficulty is right in the framework that handles all the different kind of,

stores you might wanna build. I think this is brought sharply into focus for us and that tangent agency. That is what my boss,

and we started doing kind of b to b stores

where they were kind of site stats were run by companies who are kind of selling,

let's

see, kind of products to other businesses.

And so the things like, tax, some have become a lot more complicated then,

and pricing. We had a lot of various problems like the store wants to show a totally different price to to different customers depending on what type of customer they were and then I'm getting some kind of criteria.

And then how much tax they would pay would depend on all kinds of different things. Like, obviously, what they bought, whether we're shipping to, what type of customer they were. Sometimes they would be paying with some kind of internal gift card credit system. And the idea was if you ever paid for products with that money, then, technically, the money never it wasn't proper taxable transactions. You wouldn't pay tax on half the order

and kind of all kinds of complicated situations by that.

And that's where some of the design we lost, it comes from, which fine. Have a very we have to have this kind of layer where we, to work out the price of a product, but it's the price you show a secret customer. You can feed all different variables into that kind of layer about who the person is, what the product is, when where they're trying to ship to, that kind of thing.

I think that's an example of the kind of where things can get complicated quite quickly,

in terms of, ecommerce stores.

You'll back there. If you just take 1 particular instance of a store, it's

generally not that,

complicated. You know, you just have to work out how are we gonna manage inventory in stock, how are we gonna,

pay for things, how are we gonna fulfill and ship things and manage the pipeline,

once something's been shipped in terms of returns and refunds?

But, yeah, the more interesting problem is trying to write a framework that handles every possible fulfillment pipeline.

If that makes sense.

So if I can comment on also on that. Well, the first projects I did was for a big liquor store in the Netherlands.

They had, like, a 1, 000 shops,

just regular,

stores, and they wanted to sell the

it's online. So we had to incorporate the new Oscar environment within an existing landscape. So,

you have like,

stock, but the stock can also be used by other shops. So we have to reserve stock. You have partial payments. You have, customers with loyalty cards. We get discounts.

So Oscar was a perfect fit for those kind of situations for us,

because ecommerce is actually 1 of the most

more complex

applications you can build, I believe.

Oh, it's absolutely nice. Just reminding me, another reason why we kind of picked Django, to build,

Oscar is is because she got all these other great packages, which aren't anything to do with, colors,

excuse me, that you can mix into your Django project. So if you want a CMS and and basically every

every store I I worked on does need some kind of CMS.

I didn't be able to have to build too much CMS functionality into Oscar because it's not 1 of its core reason for being. But now, you know, these days, you can start a new junket project. You can install OSCAR, then you can install Wagtail or Django CMS or some other of these kind of,

of these good CMSs. And you get all this functionality which plays nicely together straight away.

So that was sort of a great advantage for us for having it as a kind of an an open source Django,

package.

And, actually, the only other thing was, as Michael said, often people start with their CMS,

Django sites, and then realize they want to bring in some ecommerce functionality. They wanna start selling things. And Oscar gives them a natural kind of pathway to do that. They don't want to throw away the whole junket site. They can kinda just bring in Oscar as a

as a new package. And, you know, it should play nicely with, your existing jungle sites. Because at the end of the day, it's just like,

you know, Wagtail and all all these other Django apps that you can install. It's not fundamentally that different.

1 of the main issues you would probably have trying to marry several different

general applications is just who controls the kind of user object, if you know what I mean. The the kind of main user that's used for authentication and logging in. Because often our CMS and us will have some idea of why user is and what they value as well.

Yeah. That makes sense. Yeah. Definitely. That's 1 of the,

recurring themes that comes up a lot when talking about various,

Python projects is that the power that the ecosystem brings is 1 of the main reasons for initially starting a project in Python or using 1 of the Python frameworks like Django

because of the fact that you don't have to write everything. You can just focus on the core differentiator that you need to deal with, and then you can rely on the great work that so many other contributors have made before you.

Yeah. Absolutely.

And 1 of the other sort of main ecommerce

libraries or frameworks that I'm familiar with is, SpreeCommerce in Rails. I'm wondering if you're familiar with it, and if so, if you can give a brief comparison between Spree and,

Oscar.

I'm I'm I'm aware of it, but I'm really not that familiar with it enough to give a a comparison of that. I don't know if you are, Michael.

No. No. I know, when I started using Oscar, there was a consideration between Magento and

and Oscar and, of course, the more

commercial offerings like Hubelis and, and stuff like that. But I never yeah. Oscar was actually my first ecommerce project,

framework.

Not really familiar, but it's it's pretty

I know there are a lot of new Django frameworks coming up, these days. I believe cellular was is pretty active also.

Just

But they take another approach than, Oscar, I believe. Oh, I think Xelior is not really trying to be a framework, but more like,

you just fork it and you and you customize it or something like that. That's right. Saleo is actually written by some people that, I used to work with on a lot of projects. So that is written by an agency, in parliament called Miri,

and they came to work with us at Tangent on some of our big and we did some big ecommerce stores in India,

1 year, and they came and worked with us on those. So they worked on that. Oscar was only kind of version of 0.1, 0.2 then.

So they,

Patrick and some of the other people that are over there committed quite a lot to Oscar.

But then, of course, they weren't they were doing their own ecommerce,

platform at the same time, which, as you say, takes a slightly different approach to to also just

And is there a particular

size or scale

of ecommerce site that would make sense to bring in Oscar, or do you think that it fits equally well from the small to the large scale?

Well, I think for very straightforward

ecommerce,

where there's nothing particular nothing unusual about it.

I mean, my knowledge is a little bit stale, and I'm talking about how many things 2 years ago then,

Shopify was always a good,

fit for that kind of problem. If you're just trying to sell some t shirts as a side as just a side thing, it's good, you know, alongside your main business,

then something straightforward that Shopify worked quite well. That's not really the aim end of the market that Oscar was trying to make sure that. So Oscar was all was trying to find this

part of the market where people had, you know, not obvious or

or complicated things within their domain that they wanted to model elegantly,

not just accurately even.

And so as soon as you, you know, you had some kind of subtlety around shipping or tax or inventory management, you know, it doesn't take long to break out of what you can do within something like,

Shopify. Like, you know, you don't get to change the source code,

and, Oscar was a it's a good fit for that kind of part of the market.

As an agency, we've spoken a little bit in terms of winning pitches for the real high end of the market, where people have got multimillion pound budgets.

Just against kind of more established proprietary software,

like, hybrids, I think was 1,

and maybe some of the SAP,

sponsored product. Actually, I think maybe Hybris did become part of SAP.

But that's not really

an objective comparison between that's more about kind of business and support and enterprise and looking for.

Oh, I'm yeah. And I to add to this, I I believe Oscar's really strength is

that most ecommerce environments I built actually don't use the the product information system in Oscar but import it from another system. And the other others are handled by another system.

So Oscar is more like the front end for an existing infrastructure

landscape. And I think Oscar really fits well there because it's so, pluggable in other,

solutions already.

And I think if you have a a small shop, then you do your product management, do your in in the ecommerce framework or the the order handling, you do also in the same framework. But for the bigger shops, it's just all separate entities, who do that stuff.

So I think that's the real strength of Oscar.

1 of the main points that's illustrated in the documentation is the fact that Oscar

has a domain driven approach to building ecommerce applications.

Could you guys explain a bit what that means and how it's manifested in the project?

Sure. I think I probably wrote most of those, phrase in the docs. You fill that 1. So

my background

for,

software engineers in kind of, mathematics, and I was works a lot of mathematical modeling. So 1 thing I was always keen on in software, what it's enjoyed was the aspects of accurately modeling a particular domain

and mapping it into software. And this means kind of getting your data structures right and your kind of and your layers and how information flows between them. That's always a bit of software engineering that I enjoyed.

And so that's and at the time, I was reading lots of programming books. 1 1 1 of the books that stuck with with me a lot was Eric Evans'

domain driven design.

Now

in Austin, what I mean when I say

domain driven is that because it's very flexible and it lets you

change the core data structures. You know, if you have orders that need, you know, particular fields that, you know, map to your domain, you know, like in the book world, like publishers and authors and,

bindings and that kind of thing, then you you can actually change your models to have fields that accurately capture,

you know, act accurately model the domain you're talking about. Now this is in contrast to other frameworks, which

don't let you kind of change the core models, which means changing the data schema effectively. They kind of use a,

I think it's called the entity attribute value pattern, which is kind of bundling lots of key value pairs of metadata

against your kind of call objects like, orders and that kind of thing.

And that's a well known kind of pattern. It works okay, but listen, you're not really capturing the domain properly. You're just kind of bolting on your metadata to try and get it into the database.

And it leads to quite openly,

SQL queries, poor performance characteristics, and it's generally quite tricky to work with. And when you've got a store which might be long lived, you might be developing it for years years, this is ultimately gonna cause you to slow down,

force pain and sadness and other things like that. So

Oscar tries to move away from that world by letting you bake your

model your, domain accurately within your data structures.

When you get your data structures right, I think this has been picked up by kind of and other people about when you when you get getting the data structures, right, it's really important because they're at the foundations of your building. They let you build, you know, on top of them and kind of natural and

it's my way of saying it. It means other features and extensions come up kind of easily and naturally. You're not kind of fighting your own data structures in the logins.

And that's something I've come across before,

maybe in this PHP framework that preceded,

Oscar, where, you know, you're trying to model a new domain, but you just find that the core data strips. Core data structures don't really capture it properly, and then you're constantly kinda having to put kind of hacks and bolt ons and workarounds on top of it just to try to shoehorn in the,

the way your domain works into the software. So I mean, by domain driven, I'm not it doesn't really follow everything that's in Eric Evans' book, but it's more about just making sure,

in models or it's flexible enough to let you model the your domain accurately.

Is an example of the idea of having the right data he

sort

he sort of chanced upon the right data structure and data format early on when he was developing the project so that he hasn't actually had to modify the core building block of it as it's continued to evolve and add a lot of new functionality. So I can definitely concur that having the right

structure and format and semantics of your data from the start can be a huge benefit to the project overall because it means you don't have to go then go back and refactor some of the original building blocks and try to figure

out how that propagates back out through the rest of the project. Yeah. That's absolutely right.

So what does the internal design and architecture of Oscar look like? And for somebody who wanted to get started with building a site with it or integrate it into an existing Django application, what would that process look like?

Michael, join.

Yeah. Sure.

So basically, what I always tell people is OSCAR is is just a collection of Django applications.

So you have the baskets, the catalog, offers,

you name it, voucher.

So,

if you're just starting, you just run Oscar, of course. You integrate the Django project. And then

when you need to add functionality, you fork 1 of those apps. So the Oscar access out of, I think, I believe, around 10 apps. So if you want to add customize your checkout flow, which is, common, I believe, then,

you will fork that app with, the management command, though. And you just have a jungle view with models which you can edit.

So, basically, that's it. I I think people believe

it's more difficult than it is actually is. Yeah. I don't know if it's actually here because it's, yeah, it's just Python,

just jungle

models. There is some some stuff like dynamic swappable models, which confuse people sometimes,

with the get underscore model and get underscore classes.

So that may

be the most important

differentiator between regular general apps. So if you understand that, then you can just, go ahead, I believe.

I'm not sure if the app apps,

David has more.

No. It does make sense. I think 1 of the ways that Oscar was designed is that,

it has this kind of dynamic,

loading or importing of other classes.

So, you know, just make the Python if you want to go and load some class. Let's say it's a class that generates, all the numbers or something. You just become some from some module import, you know, the custom for all the number

generator. But because OSCAR wants to let you customize

the all the number generator, just a little bit example,

It's not gonna just use a regular Python kind of from some way or this,

statement. Instead, it's going to be used to kind of we put a layer in front of it, actually, a kind of dynamic loading layer,

which kind of says, yeah, I want to load something called the order number generator.

I'm not gonna tell you explicitly

where that is.

And so,

the dynamic loading can then go look and settle different places to go and find, you know, the specific class. And if if you haven't customized it, it will just find the core 1 and also but also let you put your own 1, you know, inside your project, and it will find that 1 first.

And that's the kind of trick that lets you kind of override and customize a subclass.

Actually, any kind of components within,

the Mimioska code base.

It's it's really not that different to kind of standard, like, include path

loading tricks you can do. You know, even just in bash bash, you can put a new folder at the front of your,

like, your path of going available, and, you know, bash will find things there first before you go and find them in more conventional places. It's really just an analog of that.

That is perhaps 1 of the most core decisions in our scale, important

pieces of design. It lets

you override things.

Yeah. When I was reading through the documentation

for the project, and I came across that aspect of it, it sort of reminded me a little bit of maybe a lightweight dependency injection or inversion of control approach.

Yeah. That is kind of true. We didn't really want

yeah. You could have switched it where the start of the project you have to configure or create some configuration

file that says specifically where do I get all of these

different things from. I guess,

didn't get that number just because they ran an awful lot of these things.

Let's say and and you're in any more particular story, you you really wanted to override and customize kind of 10 times percent of them. So it kinda made more sense to kind

of use the kind of what's the right way to say that? Kind of opt in approach. You just want to be expressed about the ones you did want to override as opposed to having to

As we briefly discussed before, there can be a benefit to having an opinionated approach when building a framework because of the fact that it simplifies a lot of the implementation

and design choices for the end

user. So I'm wondering if you can expand a bit more on the reasoning for choosing to expose

the internal complexity

of the problem domain in the OSCAR framework.

Well, I think for me, we're trying to solve it with a necessity, really. You know, we had clients that said offers have to work this way, you know, that's how that's how we want to do the whole that's how our back end systems do them. And we didn't really have the option of saying, actually, you know, we'd like to consolidate on this unconventional approach, and it's gonna work for a lot of clients. You know, that would be brilliant, but,

it wasn't something that was gonna work. So we had to kind of

allow everything to be,

to be kind of customizable. And a lot of the kind of evolution of Oscar in the early days is we'd write an implementation of a feature. You're driven by a particular client's requirements,

and I haven't make it into the framework. And then another client will come along and say, oh, no. We don't want offers to work that way. We have to work in this totally other way. And then we'd always have to do this, and our excitement taking a step back and say, okay. What's core between these 2 ways that these different client quality offers?

Let's get that in Oscar and provide the whole point to reach them to then go and customize it.

And in many ways, you know, Oscar

is, the product of going through that iteration 100 of times of trying to marry requirements in different clients, see what's core, and see how you can then take a core thing and customize it in 2 different directions.

That's quite a good exercise around flexible software.

1 of the problems I get on the what problems 1 of the downsides, I suppose, of

effectively allows allowing anything within any class or function or within the that's a code base that it customizes, provides this enormous

surface area, which is kind of like your API that you're you're giving to, you know, your Google's or community or your develop side using Oscar, they can legitimately come and say,

you know, how does this how does this customer work? You know, how do I use these methods? I have customized it in Oscar, you know, version x, but a nice change in version y. You know, how do I migrate between the 2?

It's,

enormous

scope for getting kind of issues in contrast to cover an awful you know, a lot of the service side of the project.

I find that in

it's kinda in the other, like, open source side of the slide. You know, you can be a very explicit about what the

public API is or kind of clients of your of your package of the module.

The ask is quite different to that because,

you know, developers can just reach in anywhere and, and start changing things within Oscar.

Definitely makes it quite complicated.

I found that since I've I don't I don't get to work at Oscar in my day job,

you know, I have a fairly full on day job now at Octopus. And

a lot of stuff.

And, oh, maybe I'll maybe I'll look at some Octopus stuff tonight, but then I opened my laptop at kind of 10 PM and and this kind of 3 I mean, I used to kind of read every email on the on the main list. But this thing, it used to be kind of 300 of the emails and hundreds of GitHub issues and podcasts on all kinds of topics within the ecommerce thing. I find it quite overwhelming these days. I really

struggle. I mean, this is probably a common journey, but I struggle to kind of get the headspace almost to,

to think about this enormous surface area of the the Oscar ads.

I feel quite guilty about that. I'd like to kind of do more. I'm actually just doing a bit of, prep for this, podcast. I was familiar refamiliarizing

myself with,

the state of play and how things are. Reminded me what what fun, you know, what how much I enjoyed working in the Oscar, whether spent

time in the day all the time. I wasn't exhausted, frankly.

To work on the road. I actually quite like to get back into it.

Customized,

it creates this enormous certain area. But it was a necessity for the the problems of the day that it was on.

Playing on the on your point there about the amount of service area that it exposes for the end user,

I imagine that it also creates maintenance challenges in terms of determining

what features to accept and which ones to reject as far as pull requests from the community to make sure that you don't end up with too much feature bloat within the core framework that would not necessarily apply to the broadest set of use cases and is more specific to 1 person's

particular requirements that they wanna have embedded into the framework so that they don't necessarily have to reimplement it on their own?

I believe

it's 1 of the downsides of Oscar. I believe our downsides big word, but,

because it's

really flexible,

you know, most functionality you require, you can build yourself. I hear a lot of people are using it. A lot of companies are using it, but they don't really need to contribute it back because they can just plug it in themselves.

But and a good example is for example is the the promotions application in,

in, in Oscar,

which is not really that good.

It tries to be a CMS,

but it isn't. So

the best way is to remove that and just say, okay. Please use Wagtail, which is what I'm a fan of, of course,

or use general CMS.

But it's difficult to just remove that because then you need to go, a lot of companies are using it, actually. So,

that's what you mean. Right? So

Promotion is actually 1 of the things from Telstra, actually. That's when,

in retrospect. Now, actually, it shouldn't have been ported as a cross, as you say. But sometimes once things have come in and they get and they stick and people are using it to hard to get rid of them,

that that's 1 of the,

yeah, the Telstra features from the book world, which as you say, now that we have white tag and all these other great features,

the need for it to be lost again, you know, isn't

is not passing anymore.

But there there are so,

I'm thinking about

a little bit about, us creating an Oscar 2.0,

like, okay, we can just remove some stuff and say, hey, it's a big new major version.

1 of the things I want to do is, like, example,

remove jang ho a stack and just say, okay, we just support

Elasticsearch.

You know that there's a lot

of people will be, of course,

don't like it because they are

using

a Woosh or a Solarg.

But I believe to be more powerful in in, for example, the searching or vesting on the e commerce front, you just need to make a choice. Are we going to use Haystack or are we going to use Elasticsearch?

And then that those are some things I'm I'm thinking about, new design for the dashboards, which had a lot of impact,

because a lot of people already created custom views in the dashboards of Oscar, with their custom applications.

So that's difficult because,

it's pretty it's it's used a lot, Oscar, I noticed. Yeah. Yeah. Yeah.

It's difficult when you're trying to make

so many different people happy at the same time and

being more opinionated and saying that we're only supporting a 1 particular search back end or whatever is whatever is is very appealing. I I agree that probably it's the way to go. Because hospitals let you you know, if if you don't want Elasticsearch, you can always just write your own

search module, do your own thing. There's nothing stopping you. It's not like a binge burning thing for, like, for other projects.

Trying to walk that tight rope between, you know,

providing the flexibility for most people, but they're not going crazy trying to make absolutely everybody happy. And it is it is definitely a tricky 1.

I used to say,

we would often have an internal discussions about this kind of thing that,

with great, flexibility comes great confusion.

Contribution, have you considered

having a sort of community plugin

site where people can go and see different

extension modules that other people have written for specific problem domains that they could then pull into their own projects?

Michael, do you want to Yeah. I'm not sure what you mean actually. Sorry.

So for instance,

I don't know if you're familiar with the Kivy project, but it's a GUI framework. And they've started a, part of their site called the Kivy Garden where

people have created their own modules that other people can then pull into their projects. So if there's a particular

button widget that somebody wants to use but doesn't necessarily

want to or know how to implement, they can just pull in something that somebody else has already done. So for

Oscar, for instance, if somebody has created a particular

implementation

of coupons

and they want to provide that for other people to use,

basically exposing a way for them to have somewhere where they can list that so that other people can find it and pull it into their projects?

Yeah. So,

in the weird me, there are a couple of, projects like, okay. Look at this project, but it's not really maintained that well. For example, in the Reactail community, you have the I'm not sure if you're familiar with that, but you have the the awesome Wagtail Wiki

where people just place their modules on, with the description, categorized a bit.

But we don't really have that something like that. Perhaps django packages,

..com

might be usable for that, but, no, not really. So 1 of the things I did do was, we used to be,

to get community a bit more active again because it slowed down a bit. I started the Slack channel, and I invited people who committed frequently to Slack channel, giving commit access to people again. So you see a small uptick in the contributions again,

which is, I think, the the most recent big change is the Slack channel, which I think works better than, you say already.

But that's the, yeah, that's the only thing we did recently for community. Not sure if David has any other, remarks on this.

Not really. I think back back when I was active in Oscar,

we kind of, if someone told us about an extension, we kind of put it in the readme of Oscar itself, and I think then we moved, Oscar on to its own kind of GitHub organization. So I guess the next step would have been to bring it into this kind of umbrella organization.

But we didn't have anything more than that, I don't think,

in terms of kind of providing a community and a kind of discoverable place for

for Oscar extensions.

Yeah. A couple other approaches I've seen for curating that kind of list is, for instance, with SaltStack, they've got a separate organization for SaltStack formulas. And so users

can request

to have their repositories forked into that organization.

Or

with

Pelican. They've just got a repository that has a bunch of git submodules for each of the different available extensions.

I think building a community is is a lot of work. You need people that are good in it and enjoy that a lot. Yeah. Absolutely. Personally, I'm not I'm not if I invest time in Oscar, I try to do it with goats instead of, answering questions on the mailing list or or stuff like that. So you need some people who in your community will will like it and we would, man, would would like that.

Well, perhaps somebody listening to the show will decide to take up that mantle and, help grow the community with you. What are some of the most interesting and unexpected uses

of OSCAR that you've seen built?

I can't unless I think of it before, I can't think of anything as amazingly surprising.

We used to actually, I'm not sure if we still do, have a I kind of track a pixel,

that would let us discover

domains of people running on Oscar sites. So this is all public news and the doctors are very explicit about it. And every now and again,

see go and have a look through all the different Oscar sites out there. And it just the just the range of disc different ecommerce stores is always interesting. It's everything from,

you know, your book sites, people selling

makeup or DVDs or m p threes or underwear or plants. You know, anything you can think of as an online store for someone at an Oscar store for it somewhere.

That's also quite interesting.

1 thing I we would I want I guess, when I was working on a tangent, 1 direction we're thinking of taking Oscar in as we're doing lots of I'm talking to lots of clients and lots to do ticketing

and kind of booking,

like, a a tour by a museum between, you know, between 9:30 and 10:30 in a particular day. So it's kind of concept of tying products

to, kind of the dates and datetimes and that kind of thing. And,

never came to be in the end, but that was an interesting direction,

that Oscar could quite naturally move towards. It wouldn't be that hard to,

to modify,

to take an Oscar project and make it work with events and tickets and time slots and that kind of thing. I know a company is already using it for hotel bookings, which says and stuff like that.

They mostly use it with, the Django Django Oscar API with the with the REST framework

layer.

And so but also right now a couple of sites are using it, behind the Sitecore environment,

also using the API.

So then OSCAR is more used as a back end engine, ecommerce engine than, the front end. So that's

also something that Oscar is, of course, pretty good in, I think. That, reminds me of another question that I had thought of a little while ago is

for somebody who is just starting a brand new Oscar site. Is there a an easy sort of 1 shot command that has a bare bones site visible, or is it largely up to the user to build their own templates?

Well, you can, I think the sandbox is is the starting point, and you can just start it from the from the git checkout? So if you clone the Django OSCAR repository,

it's basically just make sandbox, and, you're good to go.

Yeah. Because I know that sometimes for somebody who just wants to experiment with a project, not having something that they could start up and have something to look at, it can be somewhat discouraging

and increases the barrier to entry enough that they decide to just move on to something else that does have something pretty that they can look at when they first launch it.

Yeah. Oscar does ship with a a set of templates. I think they're bootstrap based, and

you can I think there is a command stop project or something which will,

which will just create the scans and structure you need so you can start a little server and browse, you know, the the default very vanilla looking shop?

So I think we do I think we do address that particular barrier issue. I think someone can actually go from 0 to browsing some product pages and just a a minute also.

As Michael says, we also have to have some example

Oscar shops in the VP, which were a bit more opinionated and will defined some products and defined on tax works and shipping and other things. You can see, you know, what your project might be like after, you know, a few days work by kind of browsing around the sandbox and then

seeing a a a more concrete example of Oscar where some customization has already taken place.

From your perspective,

has the sort of domain of ecommerce

changed or evolved since Oscar was first created, given that it started a few years ago and purchasing things online has become more and more ubiquitous?

And if so, how has that impacted the evolution of Oscar itself?

From my point of view, well, 1 of my knowledge is as of end of 2014,

really, it hadn't changed

a great deal. You know, we constantly try to

roll with the punches as we're building all these different client projects. But nothing fundamental

in the kind of nature of ecommerce had really

come about other than, as you say, just being becoming increasingly popular.

And so

I don't have anything profound to say on that particular point. I don't know if you do, Michael.

No. Me neither. I think,

well,

Oscar hasn't changed much, I think of the last 2 years. It's modestly, just upgrading it so that it supports the new,

jungle versions.

But, no, I don't think ecommerce has changed much. And I think,

perhaps, but I'm not it I that may be country specific,

but things

like, payments are are a lot easier these days, because you have a lot of payments providers, of course.

We just we just say, okay. This needs to be paid, and you forward the client to a payment environment, and they just do their thing. And

you don't don't really care how's the implementer.

I think that's,

natural trajectory, Fosco. You know, its future isn't

adds loads more features into the core framework. You know, the way it changes is to

is to make it more flexible. And that often means, as we've touched on before, this kind of promotions component, but it is sometimes stripping things out. So, like, removing the bits on that flexible or have been replaced by better alternatives.

I'm just, you know,

you know, turning off into this kind of lump of clay that can be molded into any shape. You know, often the the work is often just kind of tweaking internally to make things more flexible.

Evolve. You know, in terms of new features and support in Bitcoin and all points, other things from the general ecommerce ecosystem. That would come in its plugins and extensions, like extra things you can mix together with Oscar quickly, you know, together, our projects up and running,

small amount of time.

And I think 1 of the big changes for for me developing

Oscar is these days is is combining it with Reactil.

Both use the same underlying

technology

in using 3 birds as

the base for the models

that combines really well. And, we created a package for it for a client, to integrate it.

And, yeah, clients like it a lot because you can just select products in Wagtail and do checkout in, in Oscar.

And I think that is if you want to CMS,

use it in combination with

with Oscar, then, yeah, just look at Wagtail.

Yeah. Wagtail is definitely a pretty well put together CMS, and it's 1 that we're actually using at my job. And for listeners who are interested, there is an interview that I did with, 1 of the creators of Wagtail.

So I'll link that in the show notes as well. So are there any topics

of conversation that we didn't cover that you think we should have?

I can't think of how it feels to do with Osgood specifically.

No. Me neither. Yeah. We're always looking for,

contributors,

pull requests, and people who want to review the pull request. I think a lot of people are using it but don't contribute it back yet.

So

I hope that can be improved. That's good.

Alright. Well, for anybody who wants to follow either of you and get in touch, I'll have you guys, send me your contact information. I'll put that in the show notes.

And with that, I'll bring us to the picks. I'll pass it to you, David. What do you have for picks?

Okay. So 1 thing that has really changed the way I

program I've only picked up in the last 6 months or so is I mean, I'm I'm keen to be the advocate and try and whack things that way all the time. But I recently subscribed to Gary Bernhardt's Destroy All Software,

Screencast. I don't know if that's gonna pick before, but I'm highly, highly recommend those in terms of

turnst kind of 10 minutes screen cast on some lot on many aspects. But a lot of things that I would things I'm interested in, like

running tests, structuring code, software design,

units, git, these kind of things. And actually, the thing I wanted to call out, which I a practice I picked up for watching those

is using your editor,

to map some keyboard shortcut that immediately runs the test that the cursor isn't on on at the moment.

And so I'm a good user. So I'm not kind of leader t, which is comma t in my,

in my preferences to,

to run a particular unit test that the cursor is under, and then it remembers that test. And whenever you go and change your application code, you can do comedy again.

And,

and it moves that same test again. And that tiny keyboard shortcut thing doesn't sound that close to control. It's actually having an enormous difference because it lets

you

do get that cycle of that activity cycle from kind of running failing the test and fixing it or rerunning the test

to really a really small amount of time of fractions of a second.

I used to do this extremely labor intensive process where I'd like to command pound and switch to another terminal window, and then do control p to set up a few use command. I've done that. And but, you know, this is like an order magnitude faster than that, and it makes a huge

difference. Sometimes these small changes in in making something slightly faster can have a really,

surprisingly larger folks.

The idea of keeping your tools sharp is 1 that's definitely

important,

in any discipline, but particularly in software engineering as well because of the compounding factors that it can bring into play in terms of increased efficiency and increased satisfaction.

Yeah. I know. I'm an absolute geek for that kind of stuff, point 30

and improvements

and fiddling with your bash RC and your weed line config. And I I I used to joke that on my funeral. I just want my VINRC veterans.

That's not really a joke.

Michael, what do you have for pics?

So,

well, I can continue with that a bit. For my my current journey is actually switching from PIM to PyTorch. So which is

and the same as that as in David. I'm just trying to be more productive,

when I'm working. So switching PyCharm, I'm not sure yet if I will continue continue using it,

because I miss the miss Vim, sometimes.

But,

it's a great editor, especially with the latest version. Furthermore,

I did a last year, a lot of my open source work actually went to other projects in,

Oscar.

I created the soap library because

that's what's something I wanted to do for years because I was always frustrated when I was required to use a soap service.

So,

so that might be interesting for people to look at. It's called, the Zape,

project.

I think it's great, of course. How do you spell that, sorry, Michael?

Zape,

z e e p. Oh, yes. We're using that, OXFUS. It's not a home place.

So that's

I worked at on that the the last year, and it's actually really fun to work on because it's not web development. It's

it's purely making something that's compatible with a lot of old incompatible software.

So,

you get a lot of weird bug reports, of course, because, hey. Why don't why why doesn't this work with my, soap server

from 10 years ago?

But that makes it fun to do, actually, a bit of puzzling.

So that's 1 of the other things I was working on.

Yeah. That's good to know about because a lot of the other SOAP libraries that are available for Python have been sort of unmaintained and are starting to show their age.

So it's, interesting to see a new entrant to that area, particularly given the fact

that soap is so widely reviled and yet still

fairly widely used particularly for,

older or larger companies?

Yeah. Especially in dot net, it's, of course, really simple to just create a SOAP endpoint for an existing application. It's like 2 clicks and you have it running. So,

in Europe, it's still used a lot.

Well, I appreciate the both of you taking time out of your day to join me and talk to some more about Oscar. Definitely sounds like a very interesting project and 1 that I hope to have a use case for in the future. And, hopefully,

this will give you some exposure and get some more contributors. So I appreciate that. And I hope you enjoy the rest of your days. Appreciate it. Thanks. You too.

The Python Podcast.init

Summary

Preface

Interview

Contact

Picks

Links

The Python Podcast.__init__