Comments (1)
I'm the guy that did a similar thing to
svcs
(https://github.com/elfjes/gimme-that). At EuroPython you asked for some feedback, so here we go :)
Thanks for getting back to me with thoughtful feedback no less!
However, the
register_value
method seems to break this pattern. Now an instance is present at the registry-level instead of the container level. What if there'd be aContainter.add
method that adds an instance (and aContainer.remove
to remove/forget an instance) (perhaps implement__getitem__
,__setitem__
and__delitem__
) Seems to me that'd make it more clean. During testing you can then also just create a new container (fixture) for every test and don't need to mess with the registry itself.
I'm not sure I follow. For me the main difference between Registries and Containers is their lifecycle. A value has the same lifetime as a Registry; so it makes sense to me to let it live in the Registry?
Factories currently do not accept parameters. However, they can ask for other services through the 'Quality of Life' module. Would it make sense to you to allow a factory to take an (optional)
container
argument that can be used to get other services to reduce the dependency on a global object. This would also be beneficial for dealing with some locality issues, such as when using threadlocal data orContextVar
. You could make it a truly optional argument by inspecting the factory function to check if it requires an argument and only then supply it.
That makes a lot of sense; I never quite realized that recursive resources only work with Flask's threadlocal approach, because I didn't need it elsewhere until now (full disclosure: I currently only use svcs with Flask and AIOHTTP whose integration I'm close to merging).
The health check support seems nice, although it seems to me it pollutes both the registry and the container with something that is really specific. However, I currently do not have a better idea on how to implement it.
I understand your concern, but I'm not going for purity but to get rid of common boilerplate. :)
I guess there could be a more general approach that employs some kind of metadata and filtering on that, but I think I can live with the current solution for now.
There also seems to be some overlap with the
on_registry_close
functionality in that it allows for associating a factory with some callback. Maybe there is something there to make it cleaner?
Does it? You mean like a general callback system on certain lifecycle stages? I mean that sounds interesting, but I suspect it's better to watch adoption/feedback to get a better idea of what's used/needed. 🤔
Speaking of health checks. Would it make sense to allow
ServicePing.ping
to return a value? It would allow for more detailed health checks.
It would! I'm just trying to keep the API envelope as narrow as possible for now to avoid painting myself into a corner.
Finally, if you'd be open to it, we could combine our efforts and merge functionality of our two packages into one.
That's at least currently not possible for me, because I'm iterating too fast (including the occasional git push -f
) 😱. svcs as it stands is currently an internal package that I'm trying to make publicly consumable but I can't agree to anything that might slow my iteration down.
I'm currently thinking of the following
- you said you liked the name
gimme-that
. We can keep that if you want
I do like it, but is it a good name for mass-adoption? 😅 I actually literally don't know; I'm not famous for great package-naming.
- I like your approach and simplicity. I do think that I added some unnecessary complexity into my design
- I do like having a package-global registry+container+api. Like a 'Quality of Life' module, but builtin.
I wonder what it would take to make gimme-that
a convienience-wrapper around svcs?
What would you consider a good mechanic for QoL? I was thinking contextvars.
- I would also like to have (optional) type hint support for defining dependencies / DI like approach. I'm thinking of an
inject
-factory function (name pending) that could be used like the following:registry.register_factory( MyService, factory=inject(MyService) )the
inject
function would return a callable that looks at the signature/type hints and request those services from the container (requires a suppliedContainer
as an argument)
Could you elaborate a bit more please?
Assuming MyService(x: int, y: float)
, you'd expect inject create a factory that does lambda container: MyService(x=container.get(int), y=container.get(float)
?
Except for the container argument, would there be anything stopping you from implementing it yourself? 🤔 ← this is generally my litmus test for good APIs: build it in a way such that people can help themselves 99% of the time
Thanks again and keep the feedback coming! I'm getting increasingly excited about this project, even if it's gonna have only two users. ;)
from svcs.
Related Issues (14)
- Allow factories to receive a container argument
- Allow pings to return a value
- Make caching optional? HOT 4
- Cyclic dependencies HOT 3
- get_many()? HOT 2
- using Container.get on async factories leads to confusing behaviour HOT 1
- Should None be an allowed factory return value? HOT 7
- Document & test multiple deps per type using Annotated
- `get_type_hints` fails on any of the `svcs` types HOT 10
- container is not passed to the factory when using stringified annotations HOT 3
- Flask: Use app.extension instead of app.config HOT 1
- FastAPI: The server does not support "state" in the lifespan scope HOT 5
- Pinging locally defined services
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from svcs.