You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
which means "import foo.bar, and in there is something called baz which is an object Bowtie can use to talk to some implementation, possibly the one called foo.bar". This is meant to support someone writing a Bowtie harness which lives in an arbitrary place on the PYTHONPATH (e.g. me, while developing a new direct harness, or for our integration tests).
We also support shorter "named" direct connectables, which look like:
where Bowtie internally has some object suitable for talking to python-jsonschema.
While this works fine for just one implementation, if we were to support larger numbers of direct connectables (which I hope to), this will mean that installing Bowtie's python package will install lots of direct connectables, some of which may require heavy binary dependencies -- e.g. if we had one for a rust implementation, that may imply we can only run on platforms with Rust available.
We instead should look into using a namespace package (or a related plugin mechanism) in order to support these connectables.
Specifically: writing direct:python-jsonschema should attempt to import a module called bowtie.direct.python_jsonschema from a namespace package called bowtie.direct. Anyone would then be able to publish to PyPI a package which installs into this namespace, and thereby make a new direct implementation available. Bowtie itself would then not depend on all of them, and would leave up to the user to install whichever ones they wished, though we could also offer a [direct] packaging extra such that doing (uv) pip install bowtie-json-schema[direct] would install many of these dependencies automatically.
Needing resolution as part of doing this would be how to (or if we can sanely) support bowtie filter-implementations --direct as doing so would need to walk the PYTHONPATH potentially importing packages. Though hopefully there is some non-stateful way to filter the list of installed packages by whether they're the appropriate kind of namespace package.
The text was updated successfully, but these errors were encountered:
We recently added a way to directly connect to an implementation importable from Python.
Specifically, we now support:
which means "import foo.bar, and in there is something called
baz
which is an object Bowtie can use to talk to some implementation, possibly the one calledfoo.bar
". This is meant to support someone writing a Bowtie harness which lives in an arbitrary place on thePYTHONPATH
(e.g. me, while developing a new direct harness, or for our integration tests).We also support shorter "named" direct connectables, which look like:
where Bowtie internally has some object suitable for talking to
python-jsonschema
.While this works fine for just one implementation, if we were to support larger numbers of direct connectables (which I hope to), this will mean that installing Bowtie's python package will install lots of direct connectables, some of which may require heavy binary dependencies -- e.g. if we had one for a rust implementation, that may imply we can only run on platforms with Rust available.
We instead should look into using a namespace package (or a related plugin mechanism) in order to support these connectables.
Specifically: writing
direct:python-jsonschema
should attempt to import a module calledbowtie.direct.python_jsonschema
from a namespace package calledbowtie.direct
. Anyone would then be able to publish to PyPI a package which installs into this namespace, and thereby make a new direct implementation available. Bowtie itself would then not depend on all of them, and would leave up to the user to install whichever ones they wished, though we could also offer a[direct]
packaging extra such that doing(uv) pip install bowtie-json-schema[direct]
would install many of these dependencies automatically.Needing resolution as part of doing this would be how to (or if we can sanely) support
bowtie filter-implementations --direct
as doing so would need to walk the PYTHONPATH potentially importing packages. Though hopefully there is some non-stateful way to filter the list of installed packages by whether they're the appropriate kind of namespace package.The text was updated successfully, but these errors were encountered: