The direction the library is taking..

[Bluenix2]

I thought I'd make a small development announcement about some long decisions I've had to make. This dicussion will probably not get much of a use other than being linked to in the future, but if you are reading this and have an opinion feel free to voice it.

---

Summary

Wumpy will transition to a heavy modular subpackage-system so that users can selectively choose what parts of the library they want to use.

Goals and Plans

I have always envisioned the library as a very versatile, extendible and flexible tool. You use the parts you need and build upon the rest. This is how open source is supposed to be.

There's a downside to how the library is structured right now though - someone who wishes to only use one particular feature still needs to download everything about the library. The only solution is to make the library more modular. I've already somewhat accomplished this with the smaller "child-libraries" discord-gateway and discord-typings.

Namespace Packages

Although you may often complain about Python's packaging ecosystem and import system, it is very clever and is filled with useful features. There's something called "namespace packages" defined in PEP 382, PEP 402 and PEP 420. The former two rejected in favor of the latter.

Namespace packages allow you to split subpackages into multiple distributions (as in installations from pip and PyPI) - which is perfect for our use-case. Namespace packages have for example been used for the clever discord-ext-* packages for discord.py such as the ones created by @Ext-Creators.

In Wumpy this means that the whole wumpy namespace can be a namespace package and all different aspects of the API wrapper can be subpackages installed.

Repository Structure

Since each aspect of the library will be turned into its own package that means that the repository will have to make adjustments as well. Each subpackage needs its own pyproject.toml with dependencies and docstrings.

I considered splitting the repository into multiple repositories for quite long, but that leads to PRs having to be coordinated across repositories and overall harder for a new contributer to find their way around. A monorepository for the inner-most and most used subpackages poses as the best compromise.

All subpackages will be placed under a shared library/ directory, under which will be a folder for each subpackage represented as wumpy-*. All of this to make it easier to maintain and work under.

Side-effects

The big side-effect of this is that the library becomes a bit more complicated to work with even with the highest abstraction. For example, if the underlying RESTClient is used directly its return values will be the dictionary payloads as opposed to the models (unless that is decided to be a dependency - unsure so far).

Essentially, since the library can't import things everywhere and do all the work injecting state everywhere the user may take this hit. That is not a huge issue, but will be noticeable as the user will be touching a bit more directly with the Discord API.