refactor: rework Entry, Request and Response classes

[betaboon]

I'm sorry, this went a "little" overboard 🙈

So I am opening this PR as a draft, to discuss with you what you think.

I refactored the entry, request and response classes to be ABCs and went from there.

This gets us to almost fully typed, introduces new apis, but keeps all old apis available and cleanly marked as backwards-compat.

I have no good idea to split this up in multiple sensible commits.
I split this PR intro (hopefully) easy to follow, individually working commits.

[coveralls]

coverage: 97.727% (-1.0%) from 98.68%
when pulling a69d07e on betaboon:refactor-entry
into 9cfad4c on mindflayer:main.

[coveralls]

coverage: 97.385% (-1.3%) from 98.68%
when pulling 218eb32 on betaboon:refactor-entry
into 9cfad4c on mindflayer:main.

[sonarqubecloud]

Quality Gate failed

Failed conditions
2 Security Hotspots
E Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[betaboon]

fyi i have another branch that builds on top of this that gets us to fully typed.

[mindflayer]

I'm sorry for not answering before, first I've been sick, then very busy at work. I'll look at both soon.

[betaboon]

Nothing to be sorry. feel better and take your time :)

[mindflayer]

I am not sure I like the concept of mocket.core, in the end it gets most of the code, not very different from having it under mocket.
If you want to make it tidier, maybe something like mocket.decorators for decorators, etc.

[mindflayer]

MocketBytesResponse can be created with bytes/str/bool? Isn't it confusing?

[mindflayer]

I've read the code a bunch of times already, and I have the feeling that Mocket APIs got more complicated than they were before, instead of being simpler and cleaner.
Correct me if I am wrong, maybe I just missed the point here.
It would have been easier if you started from documenting the ideas behind it.

[betaboon]

heya, sorry for the radio silence, I've just been to busy.

again, I'm sorry for a PR this big and drastic, i got carried away 🙈

I'll try to explain my thought process behind this PR.

• mocket.core - contains all the modules that are not directly user-facing
• mocket.compat - contains interfaces that are backwards-compatible
• mocket.bytes, mocket.http, mocket.redis contain new, fully-typed, fully-consistent interfaces
• mocket.mockhttp, mocket.mockredis etc are there only to keep old import-paths working

my thinking is, that the old interfaces could eventually get deprecated and removed, thus they are already well isolated.

could you elaborate on where you feel like the apis got more complicated instead of simpler and cleaner?

[mindflayer]

I am also quite busy these days, no worries.

I think there is still a complete - or at least partial - misunderstanding of what Mocket is and what is shipped with its package.
At least that's what I get from reading your words.

Mocket was designed to be a low-level framework for developing mocks of any kind of server implementing socket protocols. To prove that it does its job, it ships a complete HTTP mock (similar to HTTPretty) and a non-complete Redis one.
These two products are not supposed to go anywhere, and many users pip install Mocket to use the first one, just because it works way better than HTTPretty.
Those two mocks may be moved to a mocket.mocks module, but there is no reason they should disappear from Mocket.

[mindflayer]

my thinking is, that the old interfaces could eventually get deprecated and removed, thus they are already well isolated.

In other words, they are not OLD interfaces, they are products made with Mocket's core.

[betaboon]

let's identify the things in this PR that you like, so that we can find a path forward, and remove the things you don't like :)

[mindflayer]

let's identify the things in this PR that you like, so that we can find a path forward, and remove the things you don't like :)

We could apply the first two points: moving core's code to core and the one for backward compatibility to compat.