Repository navigation
Generate public API layer #32
Description
Strawman:
Generate a top-level module within fastly_compute for each of the interfaces in wit_world.imports. Import the whole contents of the latter in the former, and the former becomes our public API.
If we want to expose the componentize-py-generated stuff directly to the public, we can. If we change our minds in a backward-compatible way, we can replace an item in, say, fastly_compute.acl with a nicer one of the same name, hiding the wit_world one behind it. Even class comparisons using isinstance() should continue to work, since all the customer ever got ahold of as a comparand was the public import path.
The machinery made for #30 can handle the generation fairly easily.
But: how ergonomic is the straight wit_world stuff? Are we going to want to paper over all of it anyway? I have not yet looked it over with that in mind.
Activity
erikrose commentedon Jan 28, 2026
Perhaps a
sys.pathhack would suffice for unmodified interfaces, but could an IDE follow it? Are LSPs using static analysis or loading up Python and actually importing things?erikrose commentedon Jan 30, 2026
I don't think it's necessary to do this before public release—or perhaps at all.
posborne commentedon Apr 10, 2026
With #84 I took the approach of generating a layer of code to replace monkeypatching and which solves a few issues and chooses (pending discussion) to daylight this
_bindingslayer as a public API surface.While remaining at alpha/beta support level and potentially long-term, I think have this level of abstraction available (with a few exceptions) provides more value than harm and gives us a fairly consistent way to override/add/remove methods as needed. I think having slightly less ergonomic but usable interfaces that target a stable ABI is probably fine, even if we will likely choose to break some of these APIs with future updates (or provide 2nd-level abstractions in addition).