Tortoise-orm: Wow, this looks nice

[grigi]

Hi

I have been looking for a sane async python orm, and this is the first one that I found that ticks my boxes ito design.
Clearly this is a work in progress, but as it is it actually is workable for simpler projects :+1:

Could you please share your goals of this project, and how can I help?

[abondar]

Hi

I am really glad to hear that I am not the only one that finds it odd that currently out there is no other good async ORMs :)

Faraway goal of this project is to make ORM that could be used for most of sql usecases, keeping django ORM as reference to keep it simple for new developers.
The best thing you could do is use tortoise in your projects, give feedback and help with implementing features that are required for you. If you already know of any features like this - feel free to create issues or PR.

Also if you are part of any community it would be great to spread a word about tortoise, because I clearly have no idea how to promote it at the moment :)

[grigi]

I will start with a bunch of PRs to work on docs and the like. (I noticed several issues re docs)

Also, is there a reason you are supporting Py3.5 on this project? Py3.6 has some lovely features:
1) f-strings
2) variable-type annotations

And since it is a new project, it may be useful to go all in with the new py3.6 features, and type annotations.

Then there is a lack of CI, there is a lack of tests, but I can help there too.
Do you have a CI preference or can I just set up Travis to get started on?

[abondar]

Initially I made this project on 3.6, but I thought that it would be a pity if people with 3.5 (and there is quite big amount of them, because it is default version in many debian distributives) could not use it because went for 3.6 only for syntactic sugar and not core features.

I think Travis is great for open source, so it would be great if you could do it.

Regarding tests I still haven't came up with any good idea how to implement them and at the moment I just run all examples before releases :)
You can write your ideas regarding test infrastucture in the https://github.com/Zeliboba5/tortoise-orm/issues/2 - and may be we will come up with something

[grigi]

Ok, I'll keep 3.5.3 as the minimum.

[grigi]

A style-guide question.
I'm assuming you are planning to stick to a relaxed PEP8?
The big question is what is the line-lengths you want to limit the project at?

I tend to put the limit to 100 characters (up from the too short 79 default), but I see several lines that are approaching 120 characters.

What line limit do you want? is 100 OK, or you have a different standard you are aiming for?

[abondar]

In my own project I tend to stick with 120, but it is right thing to switch to 100, because this is opensource project. I am going to fix it soon along with replacing assertions with meaningful exceptions

[grigi]

no, I'm busy with the style check infrastructure for my first PR. I'll change it to 100

[grigi]

Also, what are your policies re code formatters?
Is there any you prefer?

The only one I normally use is isort, which only neatens up the imports.

[abondar]

I tend to use default fromatters from PyCharm, but they are quite timid and don't enforce anything really special. I think at the moment we can stick with it as it is.

[grigi]

ok, so formatting is maintained manually only.

I also see that we may acually have to provide a pylint plugin for people that use it, as it doesn't execute the metaclass mutations, so fails to resolve .add .events .id ._meta

This is bigger change than I expected.
I'll start with very relaxed settings, and tighten them up over time to minimise impact.

[grigi]

I'm planning to help this project mature enough for advertisement.

The things I plan to do is:

• [x] Set up static analysis to monitor code quality (simple)
• [x] Documentation cleanup (simple)
• [x] use your examples as reference to start on some tests
• [x] get it to work in tox locally
• [x] set up travis (I'll probably need your assistance as the project owner)
• [x] Write a pylint plugin and re-enable pylint.
• [ ] Expand docs (use as much tooling to automate it as possible)
• [x] Enhance Tortoise.init() to take db_url as a parameter.
• [x] generic JSONField
• [ ] Annotate some of the code so we can get better static analysis/code completion.

Bonus targets:

• [ ] Benchmarks to get an idea of where we are ITO performance.
• [x] App management
• [ ] hypothesis strategy builder.

None of this will touch the core functionality. After this I plan to send it out, because you will get much better response if the project is better presented. Then we take it from there.
It would be useful to have a rough roadmap plan by that time, so that people can help with it.

e.g. MySQL, Migrations, ability to define own fields, model inheritance, etc?

[grigi]

Re the docs, The default "alabaster" theme I always find confusing to navigate.
The themes I tend to like to use are RTD: https://sphinx-rtd-theme.readthedocs.io/ and Cloud: https://cloud-sptheme.readthedocs.io/
Both are easier for me to navigate, and both render great on both mobile and desktop.

Do you have a preference for any theme?

[abondar]

Cloud theme looks nice, I think we can go with it.

I will create issue with roadmap today. I think implementing MySQL will be one of first targets, because it's relatively easy to do.
Implementing migrations is something I am really looking forward to making after that, but it seems it will one of a tough task.
Creating own fields might be completed along with migrations, because making them will require expanding good amount of logic to field objects, so I think about making some kind of interface for them to make it easy to override some parts of fields.

[grigi]

Cool, I was busy with docs, so that should be next.

So I started with making mypy stricter so that we have better type checking, and half the issues was around Model._meta, so I changed the metaclass like so: https://github.com/grigi/tortoise-orm/commit/889deb6699d0473a7c8ef0f646de69d5d82103ca so that MyPy can introspect easier (update attrs directly, not through a new Type) and this change made me uncomfortable, in that I'm not confident doing any such changes until we have a reasonable test suite. So I'm going to shelve that for now.
Was hoping that we can get some of the benefit of a test suite by using better static analysis, ah well.

I'll finish the docs work I have now, and then start with tests.

[Marlysson]

I agree totally with @grigi , this looks very nice.. I'm anxious to the roadmap announced to today..

I'll look in something to contribute in it

[grigi]

Welcome @Marlysson :-)

I feel we should consider doing hypothesis integration for testing. This will serve two purposes:
1) Make it easier for users to test their own logic
2) Allow better error coverage by getting edge-case data test coverage for all our ORM work. Could even allow a standard test suite you could run against every DB driver.

In nearly every project I used it against, I was swearing at the stupid mistakes it uncovered, and it works particularly well for data transforms (which is what an ORM is at core). It's an awesome tool.