orsinium-archive/djburger

Framework for safe and maintainable web-projects.

djburger's Issues

Project decisions: python versions support

I haven't seen a clear policy about python versions this project supports, so I may be wrong.

Concern

I have seen that this project uses six, so I assumed that it is currently supporting python2.
Which is not a good thing

Problems

Supporting python2 can cause project maintainers several problems:

1. Late language features support, like typing, etc
2. A lot of compat fixes, usually code that support both python version is full of compat pieces and even sub-frameworks on large code bases
3. Libraries limitation, some libraries are already python3+ (including django)

I would like to highlight the biggest problem for me: typing.
I see, that currently you do not use typing, but that's not that good.

I, as a user, want to get typing from the business logics framework for free.
And if I don't use types - by my choice - and my developer experience won't suffer.

And typing will make a lot of features even more awesome.
Like validators, schemes, etc.

End of support

django already drops python2 support, python2 eof is in 2020.

Solution

Drop python2 support.
Later it is possible to add type annotations and mypy support.

P.S. We are also working on types for django: you can join us here https://github.com/TypedDjango

Architecture decisions: plugins vs monorepo

This project seems really interesting.

But, I found some architecture decisions questionable.
I would like to ask some clarifying questions.

Monolith vs Plugins

The first thing that came to my eye is that you store all in one.
Everything is inside the core. Which is a rather bad idea in my point of view. Reasons:

0. Building the plugin system from the ground up. It is really hard to build the plugin system if it was not designed from the beginning. And I see it this software will surely have a lot of plugins/extensions
1. It is hard to version your software properly, imagine that you have to support several version of drf and several version of django and marshmallow. All in one package. This will have versioning/packaging issues
2. Hard to follow up. If someone needs to create a custom plugin, it will be hard to do so. Since it will require going deeply into the core
3. Hard to release. Releasing small peaces of software is easy. Releasing big peaces of software is hard. You have bigger tasks, bigger problems, many pending bug reports, PRs, etc

Solution

I see a clear separation between:

• validators
• adapters (drf, marshmellow, etc)
• form wrappers
• renderers and parsers
• some others

Each of these packages can be released independently. See https://github.com/dry-rb for the reference.

The only things to be very strict about is public contracts and semantic versioning.
I would also suggest to make a github organization for this task.