widgetti / solara

A Pure Python, React-style Framework for Scaling Your Jupyter and Web Apps
https://solara.dev
MIT License
1.9k stars 140 forks source link

Less dependencies #207

Open maartenbreddels opened 1 year ago

maartenbreddels commented 1 year ago

Not even recovered from the pydantic nightmare, I think we should see if we can trim down our dependencies. The risk of a package breaking in the future, not providing a backward and/or forward compatibility or not removing the changing the minimal Python version required has bitten us too many times in the Python ecosystem.

I hope the whole ecosystem becomes more aware of that, but to reduce risk I propose we try to reduce our dependencies. I'm ok with having optional dependencies and having that tested in CI, but lets try to get rid of some in solara (core).

We currently have:

dependencies = [
    "reacton>=1.7.1",  # core dependency
    "ipywidgets",  # core dependency
    "cachetools", 
    "filelock",  
    "markdown",
    "pygments",  # we are using this for syntax highlighting, if we do this in the frontend, we can get rid of this
    "pymdown-extensions",  # we might be able to remove this
    "humanize",  # we could vendor this
    "ipyvuetify>=1.8.10",
    "ipyvue>=1.9.0",
    "numpy",  # should be stable, but increases size, we could do without maybe
    "pillow",  # we could make this optional
    "jinja2",  # org has a history or breaking things I think, maybe we can do something lighter (mustache) and vendor it
    "MarkupSafe",  # I think a subdep of jinja, not sure why we have it
    "click>=7.1.0",  # maybe use python argparse
    "rich_click",  # same
    "uvicorn",  # core dependency (only for server)
    "watchgod",  # we have both this and watchdog, we should maybe move to watchfiles (which anywidget uses)
    "websockets",  # core dependency (only for server)
    "starlette",  # core dependency (only for server)
    "jupyter_server",  # easy, we only use 1 function
    "jupyter_client>=7.0.0",  # only used for the Session/serialization part, maybe we can get rid of this
    "watchdog",  # see watchgod
    "requests",  # small and stable
    "pygments==2.10; python_version < '3.7'",  # see pygments above
    "nbformat",  # we only read notebooks, which are json, so no need for it, but small and low risk
    "ipykernel",  # difficult to remove, deeply integrated
]
Jhsmit commented 1 year ago

watchdog/watchgod might be possible to move to a 'dev-minimal' or 'watch' optional dependency as its only required for people who develop solara apps and not for end users.

maartenbreddels commented 1 year ago

Yes, in fact, there are three roles:

That last roles indeed does not need it, but the middle one does. I'm afraid that if pip install solara does not give hot reloading out of the box, many people will not find this feature.

dhirschfeld commented 1 year ago

Having both watchdog/watchgod strikes me as a bit unusual. IIUC watchgod is the replacement for watchdog - is there a reason both need to be installed at the same time?


Edit: I mis-remembered. It seems watchfiles is the replacement for watchgod:

image

dhirschfeld commented 1 year ago

In other news, I thought I'd open a PR to get solara on conda-forge: https://github.com/conda-forge/staged-recipes/pull/23413

@maartenbreddels, if you'd like to be added as a maintainer of the conda-forge package, just let me know and I can add you there.

maartenbreddels commented 1 year ago

Might be good to move solara and ipyvuetify to watchfiles together.

maartenbreddels commented 1 year ago

Size decrease for the next release is ~130mb :) due to https://github.com/widgetti/solara/commit/463f6dde8eff1a4054d2278b15818bd7d86d2609

290M    /Users/maartenbreddels/venvs/solara-size1
164M    /Users/maartenbreddels/venvs/solara-size5
dhirschfeld commented 1 year ago

in a perfect world, we have solara-ui, solara-server and solara-assets and a meta package solara which pins solara-ui and solara-server

Hi @maartenbreddels, I'm looking into packaging solara-assets so was wondering what the other (ui/server) packages are - they don't seem to exist as separate packages?

dhirschfeld commented 1 year ago

Is the existing solara package a combination of ui/server and they haven't (yet) been broken out into separate packages?

maartenbreddels commented 1 year ago

Yes, solara-server is not split off yet. The current idea is that if we split it off, we want to rename solara to solara-ui (basically all components, hooks, and utils) and have solara be a meta package that will install solara-ui and solara-server.