Should "pip install trame" install less packages?
DavidBerger98 opened this issue · comments
As of now pip install trame installs the following packages:
trame-client
trame-components
trame-deckgl
trame-markdown
trame-matplotlib
trame-plotly
trame-router
trame-server
trame-simput
trame-vega
trame-vtk
trame-vuetify
trame-rca
Installing trame-client, trame-server makes totally sense as they are a fundamental requirement of trame, but maybe we can have the others in and extras_require. Especially trame-vtk is pretty hefty since it installs vtk with >300MB.
I understand that for showing the tutorials and demos it is pretty nice to have "just do pip install trame and it works", but maybe having a "just do pip install trame[vtk] and it works" isn't that bad.
trame-vtk does not bring vtk so I'm not sure why you think that?
They should all be fairly small. If not, I would agree with you to make things optional.
2.0M aiohttp
13M pip
3.7M setuptools
424K trame
1.0M trame_client
5.3M trame_components <---- not that small
2.5M trame_deckgl <---- not that small
3.9M trame_markdown <---- not that small
352K trame_matplotlib
47M trame_plotly <---- This is BIG...
748K trame_rca
104K trame_router
168K trame_server
1.9M trame_simput <---- not that small
1.0M trame_vega
2.0M trame_vtk
6.0M trame_vuetify <---- not that small but key
224K wslink
Trame without Plotly is 30 MB, that is not that bad...
My bad about trame-vtk.
I agree, 30MB is not that bad.
But once the number of trame packages grows, this could be something we should think about. I think we agree that the goal is not to have pip install trame install all packages. On the flip-side, it may become un-intuitive for new users that e.g. trame-plotly comes with the main package, but for something like trame-leaflet they need to install it manually. WDYT?
Yes we will have to decide what is core (comes by default) vs what you need to declare as dependency. So far, once validated and working fine, I was bringing them inside trame by default (and leaflet should be part of it).
But in general, it might be worth figuring where we draw that line and it might not be even driven by size.
I think this is another excellent use case for pypa/setuptools#1139
If setuptools/pip could implement a "default" extra requirements, then all of the trame submodules could be in that, allowing users to opt-out for more lightweight, targeted installations.
Until then, IMO, having trame hard-require all the submodules is lightweight "enough" when considering that none of these modules have any non-trame dependencies (AFAIK).
But this brings up a different issue: while trame-vtk not requiring vtk makes absolute sense, I was thrown off a bit by trame-matplotlib not bringing in matplotlib.
in general, it might be worth figuring where we draw that line and it might not be even driven by size.
+1. This will inevitably get messy when a community-led module gains traction that has its own heavy dependencies. I'm brainstorming a trame-large-image package which would necessarily require large-image's core module bringing with it Pillow, numpy, cachetools, etc.
In an ideal world, that repo would have its own examples and docs, and the user could simply pip install trame-large-image to get everything they need -- which under the current design pattern is not the case.
I want to point out the django ecosystem and how I think they've done a fantastic job of this. There is a contrib module in django itself that has some of the core add-on modules, and then there are thousands of django-* community add-on modules as their own packages. In that ecosystem, it is standard for the django-* package to list explicitly what is required so that a user could install everything necessary with pip install django-name-of-module. IMO, we should look to that ecosystem for inspiration.
Further, IMO, the list of core trame modules should be trimmed down a bit and then we should adopt a design pattern for the rest of the trame ecosystem to explicitly list the specific, required trame packages and their necessary versions.
IMO, the "core" trame modules would be:
- trame-client
- trame-server
- trame-components
- trame-router
- trame-vuetify
Then modules like trame-matplotlib would require trame and matplotlib.
This would extend to hypothetical packages like trame-large-image requiring trame, trame-leaflet, and large-image
@banesullivan what you are describing was indeed my plan for trame>=3.0.0.
Having just trame-server/trame-client being part of the core and any other trame-* bring their dependency while forcing the trame application to be explicit on what they use. Along with "maybe" a couple profiles that could bring various set of components.
Aslo since we don't want to create many breaking change, I wanted to add support for vue-3 in trame>=3.0.0. And I want to make the user choose which version they want at runtime (API add-on) with probably a default to vue-3. That will allow to be future proof and for a long time. In that work, I also want to figure out how to publish components for both versions in a streamline fashion.
Sounds like a good plan for trame>=3.x