Conversation
whitphx
commented
Jan 19, 2024
whitphx
commented
- Upgrade Streamlit to 1.30.0
- Fix hostConfigResponse in Kernel
- Update hostConfigResponse callers
| * Note that Streamlit's iframe messaging referred to here is different from the iframe messaging mechanism implemented for the iframe embedded on stlite sharing. | ||
| */ | ||
| allowedOriginsResp?: IAllowedMessageOriginsResponse; | ||
| hostConfigResponse?: IHostConfigResponse; |
There was a problem hiding this comment.
Catch up with the change in streamlit/streamlit#7342
packages/mountable/src/options.ts
Outdated
| archives, | ||
| requirements: options.requirements || [], | ||
| allowedOriginsResp: options.allowedOriginsResp, | ||
| hostConfigResponse: options.hostConfigResponse, |
There was a problem hiding this comment.
nit: I think it is better to call this just hostConfig here when treating it as an option that is exposed to the user. We will also soon add some official documentation about host config which explains what options exist. Calling it hostConfigResponse could make this slightly more confusing / technical.
There was a problem hiding this comment.
Did it.
tbh, I haven't understood well about how the HostConfig API could be used by users and why it is separated from the existing config mechanism (config.toml or the command line arguments), so also don't know what's the best signature of this API on stlite (should it be integrated into the streamlitConfig field in the case of stlite, for example?).
Actually, currently this field is only used by the VSCode extension package internally so we can change the signature in the future anyway.
There was a problem hiding this comment.
so high level: host config is targeting host platforms while the app config (config.toml) is targeting app developers. But some aspects overlap. In a normal Streamlit setup, these mechanisms work quite differently (because we need to ensure tamper-proofness for host config). For stlite, the separation doesn't matter a lot. It probably could be merged into one. But I think it is better to keep this as two options since it later can be better connected to the dedicated pages on our documentation. Once we have something out on our docs, it might be a bit more understandable.
…just as hostConfig
|
Oh the test started to fail from today due to this date-dependent deprecation |
|
Looks like the upstream test should now be broken? |
whitphx
force-pushed
the
dev/upgrade-streamlit-1.30.0
branch
from
503afa9 to
144ab61
Compare
whitphx
changed the title
whitphx
force-pushed
the
dev/upgrade-streamlit-1.30.0
branch
from
7428167 to
8e02fdd
Compare
whitphx
changed the title
|
I'm gonna merge this. |
2 participants
