dtbase, as a Python package, is monolithic. When you install it, you get everything: Backend, frontend, models, all that. This keeps it simple, but causes lots of unnecessary code, and unnecessary dependencies to be installed in many situations, such as when building Docker containers or using BaseService on a remote machine that talks to DTBase.
Options:
- Keep everything as is. No choice here is perfect, so this might still be the best balance.
- Have granular specification of dependencies. Maybe
pip install .[frontend] to e.g. install stuff that only the frontend needs. Can we make pip install . behave like pip install .[all], so that by default everything works?
- Break the repo into subpackages. Either
3a) one package for each part, such as frontend, backend, etc.
3b) just a couple of packages, such as models, ingress, and everything else.
- Break the repo into many repos. Maybe have a master repo that includes the others as git submodules. Just kidding, I'm not insane.
dtbase, as a Python package, is monolithic. When you install it, you get everything: Backend, frontend, models, all that. This keeps it simple, but causes lots of unnecessary code, and unnecessary dependencies to be installed in many situations, such as when building Docker containers or usingBaseServiceon a remote machine that talks to DTBase.Options:
pip install .[frontend]to e.g. install stuff that only the frontend needs. Can we makepip install .behave likepip install .[all], so that by default everything works?3a) one package for each part, such as frontend, backend, etc.
3b) just a couple of packages, such as models, ingress, and everything else.