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
nwkautomaniacLook 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
@hynek but to be fair,this is also sliced bread: 😜
@hynek a key issue i presume from examples is that factorys ain't context managers
@ossronny yes, they’re much better.
The container is an `with closing(container)` context manage and the factories are pytest-style generators. MUCH more ergonomic in practice.
@hynek pytest style fixtures are a bit of an mistake in terms of concern Separation, they make a convenient api but the lack of a porcelain level that hasn't concrete language level construct's and layer's makes pinpoint Testing insanity tricky and typically sidestepped
@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 solution includes ai designed face huggers with a hexagonal payload
@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?
Theuni@hynek I am interested, but on vacation right now. Will try to remember when I am back. This is kinda my backyard with ZCA and such in the past.
@theuni you have my number ;)
@hynek - i am a huge fan of your work. I'll find your GitHub and sign into it. I've spent a career explaining complex material.
Georges@hynek if one was familiar with dependency injection, layering your business logic for testability and that sort of things, but not formally acquainted with hexagonal architecture, would you recommend any pointers?
@georges I have _just_ pushed a huge update to the glossary and I looks like you’re the perfect person to give me feedback on it: https://svcs.hynek.me/en/latest/glossary.html
@hynek ah, yes, so it appears I was familiar with the idea from my previous job, but not the name.
Let me rephrase to see if I've understood:
The term "dependency injection" is specifically about your code getting its dependency as input arguments. Service locator is a different mechanism, that shares a common goal.
Aside from that, hexagonal architecture cares more about where you draw your lines, what you call your components and interfaces.
@hynek so to put that together in a sentence:
My previous job was using a hexagonal architecture, with different components for the http views, the business logic, the database access, and the network call to other services.
All of this was tied together with dependency injection (implemented is scala as argument to classes, with the glue being one big main that instances everything in order).
Does that sound coherent with what you were explaining in the glossary?
@georges yep sounds mostly right to me! hexagonal is mostly about thinking more clearly about components and less about “layers” (each component can have arbitrary layers, too).
and the diff between injection and locator is literally just the acquisition mechanism with upsides and downsides on both side. it’s explained a bit deeper in https://svcs.hynek.me/en/latest/why.html#is-this-dependency-injection – I should probably transplant some of the text
@hynek thanks, things are now way more clear in my head than they were this morning :)
It also looks like on that topic I should resume reading Architecture Patterns with Python. (And wrap my head around how to use sqlalchemy properly in this context)