Skip to content
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

Less dependencies #207

Open
maartenbreddels opened this issue Jul 11, 2023 · 9 comments
Open

Less dependencies #207

maartenbreddels opened this issue Jul 11, 2023 · 9 comments

Comments

@maartenbreddels
Copy link
Contributor

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
Copy link
Contributor

Jhsmit commented Jul 12, 2023

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
Copy link
Contributor Author

Yes, in fact, there are three roles:

  • solara developer
  • solara app author
  • solara consumer

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
Copy link

dhirschfeld commented Jul 20, 2023

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
Copy link

In other news, I thought I'd open a PR to get solara on conda-forge:
conda-forge/staged-recipes#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
Copy link
Contributor Author

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

@maartenbreddels
Copy link
Contributor Author

maartenbreddels commented Jul 20, 2023

Size decrease for the next release is ~130mb :) due to 463f6dd

290M    /Users/maartenbreddels/venvs/solara-size1
164M    /Users/maartenbreddels/venvs/solara-size5
@dhirschfeld
Copy link

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
Copy link

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

@maartenbreddels
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants