-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename to coglet
plus reorg
#5
Conversation
so that: - `python -m coglet` is the main entrypoint - `cog` compatibility imports are a thin wrapper around `coglet.api` and are only available for import once `coglet/_compat` is put into `sys.path`, thus greatly reducing the likelihood of import collisions. - `cog/internal/` directory collapsed up a level to `coglet/` since the above import collision problem is fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, mostly question w.r.t. the assumption of this being runtime only.
category=ImportWarning, | ||
stacklevel=2, | ||
) | ||
sys.path.insert(0, str(pathlib.Path(__file__).absolute().parent / '_compat')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is also assuming coglet
is only injected at runtime right? I was hoping that, down the road, this would replace vanilla in development, i.e. cog build
, so we can fast fail if user does something funny. This means we'll have to install both coggo
& coglet
in user image and:
- validate schema with the
inspector
- check prediction works through
coggo
->coglet.file_runner
- check user code imports only
cog.*
and nothing internal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds like what I have in mind, yes. I'd want to maintain this repository as cog-runtime
, which includes a coggo
/cog-server
and coglet
as a separate project from Cog, then inject them at image build time for typical development use, or via Monobase for fast push. This would mean that we'd be able to have a transition period where we can decide to install either the legacy Cog runtime wheel or this project's Go binary and wheel, and eventually remove all of the ./python
tree from Cog.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. And we can drop the _compat
alias once there's only 1 impl.
Do we want to use coggo
/coglet
in fast push cog build
time? Ideally yes if we always use them at runtime, so that we can detect breakage before user pushing. But that also depends how much feature parity we get before releasing fast push.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to introduce a way to inject coggo
/coglet
via the fast push cog build
soon, yes 👍🏼 Exactly your point about detecting breakage before user push.
and rename test func to not shadow submodule name.
so that:
python -m coglet
is the main entrypointcog
compatibility imports are a thin wrapper aroundcoglet.api
and are only available for import oncecoglet/_compat
is put intosys.path
thus greatly reducing the likelihood of import collisions.cog/internal/
directory collapsed up a level tocoglet/
the above import collision problem is fixed.