Small project I've been developing. It's designed to make configuration easier, after many frustrations with omegaconf and hydra in the past.
The idea is quite simple: you create clean objects in pure python, but the glue between them can be expressed declaratively (also in python, or maybe a ini/toml/json/yaml config file).
I know there are some challenges with this approach, such as IDE support and auto-complete. However, tab-completing agents are quite good at working with apywire config files, and I've been quite comfortable maintaining object specs without a dedicated extension.
The code you pointed to in apywire is related to circular dependencies in constant scalar types. Like a printf that is meant to replace %s with its whole output (therefore, impossible).
However, apywire also throws CircularWiringError if you make objects that have circular dependencies as well (we do not solve it).
The paper seems like a worth read. I skimmed over it, and it seems like an interesting solution: proxy-like objects that only allow construction-type interaction but no method calls or property access until the container fully realizes the instance.
Our overall syntax allows for that implementation in the future, and python in theory is flexible enough to allow us to go for that route.
It does seem like a lot of work, but I might try to do it (for objects, for the scalars it's impossible). I was looking for a nice feature to make the project more distinct!
It is around where CircularWiringError is thrown from the implementation of topological sort. If the instantiation of the objects was not lazy, the topological sort would have been applied to the entire dependency graph. As it is lazy, with objects being created when they are accessed CircularWiringError can be thrown upon access. I think this should never happen as it should be checked for in the Wiring constructor though the application of the topological sort.
4 comments
[ 3.7 ms ] story [ 18.7 ms ] threadThe idea is quite simple: you create clean objects in pure python, but the glue between them can be expressed declaratively (also in python, or maybe a ini/toml/json/yaml config file).
I know there are some challenges with this approach, such as IDE support and auto-complete. However, tab-completing agents are quite good at working with apywire config files, and I've been quite comfortable maintaining object specs without a dedicated extension.
Would love to hear feedback!
Apywire reports it can't handle circular dependency: https://github.com/alganet/apywire/blob/1c9a39df36a9385d8b34...
However, apywire also throws CircularWiringError if you make objects that have circular dependencies as well (we do not solve it).
The paper seems like a worth read. I skimmed over it, and it seems like an interesting solution: proxy-like objects that only allow construction-type interaction but no method calls or property access until the container fully realizes the instance.
Our overall syntax allows for that implementation in the future, and python in theory is flexible enough to allow us to go for that route.
It does seem like a lot of work, but I might try to do it (for objects, for the scalars it's impossible). I was looking for a nice feature to make the project more distinct!
Thanks for your feedback!