Currently, we release kobo to PyPI as a single egg containing all kobo components. This doesn't make much sense since kobo consists of at least the following components:
- hub
- worker
- client
- utility classes
These are generally deployed to different environments and it doesn't make sense to have them all packaged together as one "all or nothing" egg.
It means that we're discouraged from defining any requirements in the kobo egg, since anyone using that may be forced to pull in a lot more dependencies than they need. For example, somebody using some of the kobo utility classes shouldn't have to install Django; and it should not be necessary to install Django to (for example) create a container image for a kobo worker via pip.
We should instead be shipping separate eggs, probably at least 4 (plus one for backwards-compat), and these should define their dependencies correctly.
For example, we could release eggs:
- kobo-hub
- kobo-worker
- kobo-client
- kobo-utils
- kobo (deprecated egg which simply depends on the other eggs)
Currently, we release kobo to PyPI as a single egg containing all kobo components. This doesn't make much sense since kobo consists of at least the following components:
These are generally deployed to different environments and it doesn't make sense to have them all packaged together as one "all or nothing" egg.
It means that we're discouraged from defining any requirements in the kobo egg, since anyone using that may be forced to pull in a lot more dependencies than they need. For example, somebody using some of the kobo utility classes shouldn't have to install Django; and it should not be necessary to install Django to (for example) create a container image for a kobo worker via pip.
We should instead be shipping separate eggs, probably at least 4 (plus one for backwards-compat), and these should define their dependencies correctly.
For example, we could release eggs: