Hynek Schlawacktfw you’ve created something that excites you like nothing in years but it feels like you have to write a book first to lay the context to make wide appreciation even possible
Look y’all, it’s all public on my GitHub. I just don’t know how to go the path of testability → loose coupling → hexagonal architecture → service locator without losing 95% of the audience at step two by the latest. I’ve extracted something I’ve used successfully for years and applying it to other work projects was always a HUGE improvement but you only get one chance to make a first impression.
ossronny@hynek I like what I see, can it layer contexts/disposal/dependency?
We have a little monster in pytest for managing fixture's
@hynek I have at least 15 projects where I want such a things,but it's hard in python and the pattern is so often despised
@ossronny everybody has and I’ve decided I don’t care anymore after having projects with ~10 resources and 100s of lines of boilerplate. The main reason I’m holding it back is that… I just don’t know how to promote it such that people “get it”.
@hynek the thing is that for full features set you need a layered resources Manager, a service locators and a dependency injector working together and that's choke sized instead of bite sized thing
@ossronny Maybe the fact that everybody is trying to do all of that is the whole problem? At this point I’m happy to admit I have a 95% solution, but it has made all my services across all frameworks (so far: Flask, Pyramid, AIOHTTP) more readable, more concise, and easier to test. I feel like once you need more, off-the-shelf isn’t gonna cut it anymore anyways.
@hynek all of the frameworks model their needs as they grow, the results are molded by fate
I'd like to get to a place where collaboration gets us out of that trap
@hynek I believe a key is the interaction of the components, so many concepts are very similar but wired up ever so slightly different
@ossronny I’ve been using this for years, so this is not a first attempt to solve a problem, it’s _my_ trade-off at comprehensibility vs functionality.
It always depends what you compare it to. I compare it to the boilerplatey get_x (Flask) and add_request_method (Pyramid) patterns. Got it working with FastAPI too, which gets super verbose with its own DI once you have more than 2 dependencies.
@hynek I absolutely agree with that perspective
@ossronny the question for me is really how to promote it because I really don’t know. you need so much context both in experience (many services) and knowledge/pain (hex arch, loose coupling, etc) and from structlog I know that the amount of people who have both is very slim
Tin Tvrtković@tintvrtkovic @ossronny yes, and i’m unhappy but i didn’t want to make up my own nomenclature
@tintvrtkovic @hynek everything around that topic currently got me into a state where i want my inner SpongeBob SquarePants to come up with the names, not Sure if therapy can help
Jannis Leidel
Blake Naccarato 
I think if the present audience is really that small, it's okay to let the package speak for itself for now. You will continue to extract value from it personally until the audience grows large enough for it to be worth proper thorough communication.
If the target audience is growing, you'll get many more chances at first impressions even a year down the road than today, and maybe the API will have hardened a bit by then and it'll also be easier to communicate.
@blakeNaccarato @ossronny One of the things is that I’d love to get qualified feedback before freezing the API. It’s super nice to just iterate and push out releases https://github.com/hynek/svcs/blob/main/CHANGELOG.md
@hynek @blakeNaccarato one thing i recommend is to have inner plumbing in Terms of Python primitives like context managers, it's a key pain point for making a load of things in pytest testable, and it's hell to replumb
@ossronny @blakeNaccarato It totally is? What am I missing?