-
Notifications
You must be signed in to change notification settings - Fork 4
Automating specific microservice python dependencies #10
Comments
A similar discussion had started on
which aligns with the general meaning of microservice – ofcourse, one could argue that these are not self standing microservices but plugins. However, we have a problem: some microservices depend on satosa itself. This means that some microservices may try to install a different satosa version than the one you're running. If we don't go that way, then a I really think that this is problem that has come up due to bad separation of concerns between the satosa modules and microservices. It shouldn't be that way. The other option is to revisit the whole "microservices" concept and convert it to proper semantics. This could be plugins, or hooks, or callbacks, or signals, or a mix as needed (ie asynchronous invocation might be a valid case). |
Ok, so I tested a little and this setup seems to do the trick:
using this setup.py in base_project:
and this setup.py in overlay:
This creates the following structures (a.o.) under site-packages/ when I pip install both packages to the same venv.
All Since micro_services are loaded on-demand by plugins configuration and have an empty Only obvious problem would be the non-unique packagename of overlay, so it can't be distributed via pip? But for a local distribution repository it would suffice? |
So, I went ahead and this is what our repo now looks like |
We are contemplating extraction of our micro_services from our SATOSA fork, just like this project but I'm unsure how we would cater for microservice specific python dependencies?
I guess this repo is supposed to be copied into the SATOSA virtualenv manually, but that would break if any of the included (and used) microservices required extra dependencies. What would a setup.py for this project look like if it was to install it's microservices into an existing SATOSA venv, while adding the necessary requirements on the fly? Can packages share names, so that files land in the same site-packages dir?
The text was updated successfully, but these errors were encountered: