solara 1.30.1__py2.py3-none-any.whl → 1.31.0__py2.py3-none-any.whl

solara/website/pages/documentation/advanced/content/20-understanding/40-routing.md

@@ -1,240 +0,0 @@
----
-title: Understanding routing in multi-page solara apps
-description: Dive into Solara's routing, which provides a powerful way to compose multiple pages or dashboards into an integrated app.
----
-# Routing
-
-Routing takes care of linking a web address (more specifically the [pathname](https://developer.mozilla.org/en-US/docs/Web/API/Location), e.g. "/docs/basics/solara") to a state of the UI,
-usually in the form of what appears as pages to a user.
-
-
-Routing includes navigation (hitting the back and forward button of your browser) without causing a page reload.
-
-
-## Automatic routing
-
-Setting up routing can be repetitive, and therefore Solara comes also with a more opinionated method for setting up routing automatically.
-
-### Based on a directory
-
-Using [`generate_routes_directory(path: Path) -> List[solara.Route]:`](/documentation/api/routing/generate_routes_directory) we can request Solara to give us a list of
-routes by scanning a directory for Python scripts, Notebooks and Markdown files.
-
-This function is being used by Solara if you run solara server with a directory as argument name, as used in [our Multi Page guide](/documentation/advanced/howto/multipage). More details can be found there.
-
-
-### Based on a Python package
-
-Similar to the previous section [`generate_routes(module: ModuleType) -> List[solara.Route]:`](/documentation/api/routing/generate_routes) will return a list of routes by scanning a Python package or module for `Page` components, or `app` elements. Again, more information can be found at [our Multi Page guide](/documentation/advanced/howto/multipage).
-
-## Manually defining routes
-
-In Solara, we set up routing by defining a list of `solara.Route` objects, where each route can have another list of routes, its children, forming
-a tree of routes. We assign this list to the `routes` variable in your main app script or module.
-
-### Defining route components
-
-If no `Page` component is found in your main script or module, Solara will assume you have either set the `component` or the `module` argument of the `solara.Route` object.
-
-For example
-
-```python
-import solara
-from solara.website.pages.examples.utilities import calculator
-
-
-@solara.component
-def Home():
-    solara.Markdown("Home")
-
-
-@solara.component
-def About():
-    solara.Markdown("About")
-
-
-routes = [
-    solara.Route(path="/", component=Home, label="Home"),
-    # the calculator module should have a Page component
-    solara.Route(path="calculator", module=calculator, label="Calculator"),
-    solara.Route(path="about", component=About, label="About"),
-]
-```
-
-### Defining route components
-
-If you do define a `Page` component, you are fully responsible for how routing is done, but we recommend using [use_route](/documentation/api/routing/use_route).
-
-An example route definition could be something like this:
-
-```python
-import solara as sol
-
-routes = [
-    # route level == 0
-    solara.Route(path="/"),  # matches empty path ''
-    solara.Route(
-        # route level == 1
-        path="docs",  # matches '/docs'
-        children=[
-            # route level == 2
-            solara.Route(path="basics", children=[  # matches '/docs/basics'
-                # route level == 3
-                solara.Route(path="react"),      # matches '/docs/basics/react'
-                solara.Route(path="ipywidgets"), # matches '/docs/basics/ipywidgets'
-                solara.Route(path="solara"),     # matches '/docs/basics/solara'
-            ]),
-            solara.Route(path="advanced")  # matches '/docs/advanced'
-        ],
-    ),
-    solara.Route(
-        path="blog",
-        # route level == 1
-        children=[
-            solara.Route(path="/"),   # matches '/blog'
-            solara.Route(path="foo"), # matches '/blog/foo'
-            solara.Route(path="bar"), # matches '/blog/bar'
-        ],
-    ),
-    solara.Route(path="contact")  # matches '/contact'
-]
-
-# Lets assume our pathname is `/docs/basics/react`,
-@solara.component
-def Page():
-    level = solara.use_route_level()  # returns 0
-    route_current, routes_current_level = solara.use_routes()
-    # route_current is routes[1], i.e. solara.Route(path="docs", children=[...])
-    # routes_current_level is [routes[0], routes[1], routes[2], routes[3]], i.e.:
-    #    [solara.Route(path="/"), solara.Route(path="docs", children=[...]),
-    #     solara.Route(path="blog", children=[...]), solara.Route(path="contact")]
-    if route_current is None: # no matching route
-        return solara.Error("oops, page not found")
-    else:
-        # we could render some top level navigation here based on route_current_level and route_current
-        return MyFirstLevelChildComponent()
-```
-
-Routes are matched by splitting the pathname around the slash ("/") and matching each part to the routes. The level of the depth into the tree is what we call the `route_level`, which starts at 0, the top level.
-Each call to `use_route` will return the current route (if there is a match to the current path) and the list of siblings including itself.
-
-
-Now the `MyFirstLevelChildComponent` component is responsible for rendering the second level navigation:
-
-```python
-@solara.component
-def MyFirstLevelChildComponent():
-    level = solara.use_route_level()  # returns 1
-    route_current, routes_current_level = solara.use_routes()
-    # route_current is routes[1].children[0], i.e. solara.Route(path="basics", children=[...])
-    # routes_current_level is [routes[1].children[0], routes[1].children[1]], i.e.:
-    #    [solara.Route(path="basics", children=[...]), solara.Route(path="advanced")]
-    if route_current is None: # no matching route
-        return solara.Error("oops, page not found")
-    else:
-        # we could render some mid level navigation here based on route_current_level and route_current
-        return MySecondLevelChildComponent()
-
-```
-
-And the `MySecondLevelChildComponent` component is responsible for rendering the third level navigation:
-
-```python
-@solara.component
-def MySecondLevelChildComponent():
-    level = solara.use_route_level()  # returns 2
-    route_current, routes_current_level = solara.use_routes()
-    # route_current is routes[1].children[0].children[0], i.e. solara.Route(path="react")
-    # routes_current_level is [routes[1].children[0].children[0], routes[1].children[0].children[1], routes[1].children[0].children[2]], i.e.
-    #    [solara.Route(path="react"), solara.Route(path="ipywidgets"), solara.Route(path="solara")]
-    if route_current is None: # no matching route
-        return solara.Error("oops, page not found")
-    else:
-        # we could render some mid level navigation here based on route_current_level and route_current
-        if route_current.path == "react":
-            return DocsBasicReact()  # render the actual content
-        elif route_current.path == "ipywidgets":
-            return DocsBasicIpyWidgets()
-        elif route_current.path == "solara":
-            return DocsBasicSolara()
-        else:
-            return solara.Error("oops, not possible!")
-
-```
-
-From this code, we can see we are free how we transform the routes into the state of the UI (i.e. which components are rendered).
-
-## Adding data
-
-Often, your render logic needs some extra data on what to display. For instance, you may want to dynamically render tabs based on the routes,
-which requires you to have a label, and know which component to add.
-For this purposed we added `label: str` and the `component' attributes, so you can defines routes likes:
-
-```python
-routes = [
-    solara.Route("/", component=Home, label="What is Solara ☀️?"),
-    solara.Route("docs", component=docs.App, label="Docs", children=docs.routes),
-    solara.Route(
-        "demo",
-        component=demo.Demo,
-        children=demo.routes,
-        label="Demo",
-    ),
-    ...
-]
-```
-
-In the case where you did not specify a `Page` component, label is used for the [Title](/documentation/components/page/title) component.
-
-If you need to store more data in the route, you are free to put whatever you want in the `data` attribute, see also [Route](/documentation/api/routing/route).
-
-
-
-## Linking
-
-Note that all routes are relative, since a component does not know if it is embedded into a larger application, which may also do routing.
-
-
-Therefore you should never use the `route.path` for navigation since the route object has no knowledge of the full url
-(e.g. `/docs/basics/ipywigets`) but only knows its small piece of the pathname (e.g. `ipywidgets`)
-
-Using [`resolve_path`](/documentation/api/routing/resolve_path) we can request the full url for navigation.
-
-```python
-def resolve_path(path_or_route: Union[str, solara.Route], level=0) -> str:
-    ...
-```
-
-We can pass this full URL to the [`solara.Link`](/documentation/components/advanced/link) component, e.g. like:
-
-```python
-@solara.component
-def LinkToIpywidgets():
-    route_ipywidgets = routes.children[1].children[0].children[1]
-    # route_ipywidgets.path == "ipywidgets"
-    path = solara.resolve_path(route_ipywidgets)
-    # path == '/docs/basics/ipywidgets
-    with solara.Link(path) as main:
-        solara.Button("read about ipywidgets")
-    return main
-```
-
-## Fully manual routing
-
-If you want to do routing fully manually, you can use the [`solara.use_router`](/documentation/api/routing/use_router) hook, and use the `.path` attribute.
-
-```python
-import solara
-
-
-@solara.component
-def Page():
-    router = solara.use_router()
-    path = router.path
-    parts = path.split("/")
-    solara.Markdown(f"Path = {path!r}, and split up into {parts!r}")
-    # now you can do anything with path or parts.
-    # e.g.
-    # if parts[0] == "docs":
-    #   solara.Markdown("You are in the docs section")
-```

solara/website/pages/documentation/advanced/content/20-understanding/50-solara-server.md

@@ -1,86 +0,0 @@
----
-title: Understanding the way Solara server works
-description: Solara server enables running ipywidgets-based applications as standalone dashboards and apps, allowing multiple "Virtual kernels" to share
-   the same process for better performance and scalability.
----
-# Solara server
-
-The solara server enables running ipywidgets based applications without a real Jupyter kernel, allowing multiple "Virtual kernels" to share the same process for better performance and scalability.
-
-## WebSocket in Solara
-Solara uses a WebSocket to transmit state and updates directly from the server to the browser. This ensures that the state remains centralized on the server, facilitating state transitions server-side and enabling live updates to be pushed directly to the browser.
-
-
-## Virtual Kernels
-Normally when a browser page connects to a Solara server, a virtual kernel is created and is assigned a unique identifier termed a "Kernel ID." Should a WebSocket disconnection occur, Solara attempts to re-establish the connection, sending the Kernel ID during this process. If the server recognizes this ID (and the requested kernel hasn't expired) the Solara app resumes operations seamlessly.
-
-### Virtual kernel lifecycle
-Closing a browser page will directly shut the virtual kernel down (if this page was the last known page to the Solara server). This ensures that active closing of pages will directly clean up any memory usage on the server side for this kernel.
-
-However, when the websocket between the web page and the server disconnects, the server keeps the kernel alive for 24 hours after the closure of the last WebSocket connection. The duration is customizable through the `SOLARA_KERNEL_CULL_TIMEOUT` environment variable. This feature is particularly handy in scenarios where devices like computers hibernate, leading to WebSocket disconnections. Upon awakening and subsequent WebSocket reconnection, the Solara app picks up right where it left off.
-
-To optimize memory usage or address specific needs, one might opt for a shorter expiration duration. For instance, setting `SOLARA_KERNEL_CULL_TIMEOUT=1m` will cause sessions to expire after just 1 minute. Other possible options are `2d` (2 days), `3h` (3 hours), `30s` (30 seconds), etc. If no units are given, seconds are assumed.
-
-### Maximum number of kernels connected
-
-Each virtual kernel runs in its own thread, this ensures that one particular user (actually browser page) cannot block the execution of another virtual kernel. However, each thread consumes a bit of resources. If you want to limit the number of kernels, this can be done by setting the `SOLARA_KERNELS_MAX_COUNT` environment variable. The default is unlimited (empty string), but you can set it to any number you like. If the limit is reached, the server will refuse new connections until a kernel is closed.
-
-
-## Handling Multiple Workers
-In setups with multiple workers, it's possible for a page to reconnect to a different worker than its original. This would result in a loss of the virtual kernel (since it lives on a different worker), prompting the Solara app to initiate a fresh start. To prevent this scenario, a sticky session configuration is recommended, ensuring consistent client-worker connections. Utilizing a load balancer, such as [nginx](https://www.nginx.com/), can achieve this.
-
-If you have questions about setting this up, or require assistance, please [contact us](https://solara.dev/docs/contact).
-
-## Sessions
-
-Solara uses a browser cookie (named `solara-session-id`) to store a unique session id. This session id is available via [get_session_id()](https://solara.dev/api/get_session_id) and is the same for all
-browser pages. This can be used to store state that outlives a page refresh.
-
-We recommend storing the state in an external database, especially in the case of multiple workers/nodes. If you want to store state associated to a session in-memory, make sure to set up sticky sessions.
-
-
-
-
-## Readiness check
-
-To check if the server is ready to accept request, the `/readyz` endpoint is added, and should return a 200 HTTP status code, e.g.:
-
-```
-$ curl http://localhost:8765/readyz
-curl -I localhost:8765
-
-HTTP/1.1 200 OK
-...
-```
-
-## Live resource information
-
-
-To check resource usage of the server (CPU, memory, etc.), the `/resourcez` endpoint is added, and should return a 200 HTTP status code and include
-various resource information, like threads created and running, number of virtual kernels, etc. in JSON format. To get also memory and cpu usage, you can include
-the `?verbose` query parameter, e.g.:
-
-```
-$ curl http://localhost:8765/resourcez\?verbose
-```
-
-The JSON format may be subject to change.
-
-
-
-## Production mode
-
-By default, solara runs in development mode. This means, it will:
-
-   * Automatically [reload your project files](/documentation/getting_started/reference/reloading) by watching files on the filesystemn
-   * Load debug version of the CSS files and JavaScript files for improved error messages (which leads to larger asset files).
-
-To disabled all of these option, pass the `--production` flag, or set the environment variable `SOLARA_MODE=production`.
-
-## Telemetry
-
-Solara uses Mixpanel to collect usage of the solara server. We track when a server is started, stopped and a daily report of the number of unique users and connections made. To opt out of mixpanel telemetry, either:
-
- * Set the environmental variable `SOLARA_TELEMETRY_MIXPANEL_ENABLE` to `False`.
- * Install [python-dotenv](https://pypi.org/project/python-dotenv/) and put `SOLARA_TELEMETRY_MIXPANEL_ENABLE=False` in a `.env` file.
- * Run in auto restart mode (e.g. using `$ solara run sol.py --auto-restart`)

solara/website/pages/documentation/advanced/content/20-understanding/60-voila.md

@@ -1,12 +0,0 @@
----
-title: Working together with Voilà
-description: Voilà, together with `voila-vuetify` is an alternative to Solara server. The most significant difference is that Voilà will start one kernel/process
-    per page request, while Solara server is more scalable.
----
-# Voilà
-
-[Voilà](https://voila.readthedocs.io/) allows you to convert a Jupyter Notebook into an interactive dashboard that allows you to share your work with others.
-
-Voilà is Jupyter notebook focused, meaning that it will render all output from your notebook. Using [`voila-vuetify`](https://github.com/voila-dashboards/voila-vuetify) Voilà allows for a more app like experience, showing only the output you want.
-
-Voilà, together with `voila-vuetify` is an alternative to [Solara server](./solara-server). The most significant difference is that Voilà will start one kernel/process per page request, while [Solara server](./solara-server) can serve many more users from a single process. Sharing the same process means Solara apps can share memory among users (e.g. a large dataset), which will usually lead to better performance and less resource usage.

solara/website/pages/documentation/advanced/content/30-enterprise/00-overview.md

@@ -1 +0,0 @@
-# Solara enterprise

solara/website/pages/documentation/advanced/content/30-enterprise/10-oauth.md

@@ -1,171 +0,0 @@
----
-title: Using OAuth in your Solara app
-description: Open Authorization can be readily integrated into your Solara applications via the Solara-Enterprise package.
----
-# OAuth: authentication and authorization support
-
-## What is OAuth
-
-OAuth (Open Authorization) is an open standard for token-based authentication and authorization. It enables third-party applications to obtain limited access to a user's resources on another service without exposing their credentials. The user can grant access to their resources on one site to another site without sharing their credentials, providing a secure and efficient way to authenticate users.
-
-You have probably used OAuth without realizing it when signing into various online services and applications. For example, when you use "Sign in with Google" or "Log in with Facebook" to access a third-party website or application, you are using OAuth. By leveraging OAuth, these services allow users to authenticate themselves using their existing Google or Facebook credentials, simplifying the login process and reducing the need for users to remember multiple usernames and passwords. OAuth has become an essential aspect of online identity management and is widely used by companies and developers to provide a seamless and secure authentication experience.
-
-## Installing
-
-To install Solara with OAuth support, make sure you have [Solara Enterprise](/documentation/advanced/enterprise) install by run the following command:
-
-```bash
-$ pip install solara solara-enterprise[auth]
-```
-
-
-## OAuth support in Solara
-
-Solara offers two modes for enabling OAuth: private mode and application controlled mode.
-
-### Private mode
-
-In private mode, Solara pages or any static resources are not accessible without being authenticated. This mode is suitable for web servers that should not be publicly accessible. To enable private mode, set the following environment variable:
-```bash
-SOLARA_OAUTH_PRIVATE=True
-```
-
-
-### Application controlled mode
-
-In application controlled mode, the application is responsible for checking if a user is authenticated. The application can show a login or logout link and provide user information when the user is logged in. Solara comes preconfigured to run on localhost out of the box, and no additional setup is required to enable OAuth for local development and testing.
-
-Here's an example of how to implement OAuth in application controlled mode:
-
-```solara
-import solara
-from solara_enterprise import auth
-
-@solara.component
-def Page():
-    if not auth.user.value:
-        solara.Button("Login", icon_name="mdi-login", href=auth.get_login_url())
-    else:
-        userinfo = auth.user.value['userinfo']
-        if 'name' in userinfo:
-            solara.Markdown(f"### Welcome {userinfo['name']}")
-        solara.Button("Logout", icon_name="mdi-logout", href=auth.get_logout_url())
-```
-## How to configure OAuth
-
-Solara supports the following OAuth providers: [Auth0](https://auth0.com/) and [Fief](https://fief.dev/).
-
-
-### Configuring Auth0
-
-By default, Solara is configured with a test Auth0 account. This is useful for testing, but you should not use this in production. This account does limit solara running on localhost, port 8765 to 8770 (and 18765 to 18770 for running the tests).
-
-To configure your own Auth0 provider, you need to change the following environment variables from their defaults:
-
-```bash
-# required if you don't use the default test account
-SOLARA_SESSION_SECRET_KEY="change me"
-# found in the Auth0 dashboard Applications->Applications->Client ID
-SOLARA_OAUTH_CLIENT_ID="cW7owP5Q52YHMZAnJwT8FPlH2ZKvvL3U"
-# found in the Auth0 dashboard Applications->Applications->Client secret
-SOLARA_OAUTH_CLIENT_SECRET="zxITXxoz54OjuSmdn-PluQgAwbeYyoB7ALlnLoodftvAn81usDXW0quchvoNvUYD"
-# found in the Auth0 dashboard Applications->Applications->Domain
-SOLARA_OAUTH_API_BASE_URL="dev-y02f02f2bpr8skxu785.us.auth0.com"
-```
-
-You can optionally set the following environment variables:
-
-```bash
-SOLARA_OAUTH_SCOPE = "openid profile email"
-```
-
-### Create your own Auth0 Application
-
-
-To create your own Auth0 application, follow these steps:
-
-1. Go to the [Auth0 dashboard](https://manage.auth0.com/dashboard/) and click on "Applications" on the left side navigation menu.
-
-    ![Auth0 dashboard](https://dxhl76zpt6fap.cloudfront.net/public/docs/enterprise/oauth/goto-applications.webp)
-
-2. Click on "Create Application".
-
-    ![Create Application](https://dxhl76zpt6fap.cloudfront.net/public/docs/enterprise/oauth/click-create-application.webp)
-
-3. Enter a name for your application and select "Regular Web Applications" as the application type. Click on "Create".
-
-    ![Create Application](https://dxhl76zpt6fap.cloudfront.net/public/docs/enterprise/oauth/name-type-create.webp)
-
-4. Click "Skip Integration" to skip the integration step.
-
-5. Click on the "Settings" tabs and enter the following information:
-
-    - Allowed Callback URLs: `http://localhost:8765/_solara/auth/authorize, https://yourdomain.com/_solara/auth/authorize`
-    - Allowed Logout URLs: `http://localhost:8765/_solara/auth/logout, https://yourdomain.com/_solara/auth/logout`
-
-    Note that the localhost URLs are only meant for testing. You can remove them once you are ready to deploy your application.
-    We recommend setting up a new application for each environment (e.g. development, staging, production).
-
-    ![Callback URLs](https://dxhl76zpt6fap.cloudfront.net/public/docs/enterprise/oauth/callbacks.webp)
-
-6. Configure Solara.
-
-    At the top of the "Settings" tab, you should see your "Domain", "Client ID" and "Client Secret". You will need to set the following environment variables to these values:
-
-    ```bash
-    SOLARA_OAUTH_API_BASE_URL="dev-y02f2bpr8skxu785.us.auth0.com"  # replace with your domain
-    SOLARA_OAUTH_CLIENT_ID="ELOFERLovc7e7dPwkxO6WFAljtYj9UzJ"  # replace with your client ID
-    SOLARA_OAUTH_CLIENT_SECRET="..."  # not shown here, replace with your client secret
-    ```
-
-    ![Settings](https://dxhl76zpt6fap.cloudfront.net/public/docs/enterprise/oauth/configuration-values.webp)
-
-    Set your `SOLARA_SESSION_SECRET_KEY` to a random string. See the [Generating a secret key](#generating-a-secret-key) for a convenient way to generate a secret key.
-
-    If you want to test on localhost, you might also want to set `SOLARA_SESSION_HTTPS_ONLY="false"`
-
-    Now you can run the above solara example using your own auth0 provider.
-
-
-### Configuring Fief
-
-You can also configure Solara to use our Fief test account. To do this, you need to set the following environment variables:
-
-```bash
-SOLARA_SESSION_SECRET_KEY="change me"  # required if you don't use the default test account
-SOLARA_OAUTH_CLIENT_ID="x2np62qgwp6hnEGTP4JYUE3igdZWhT-AvjpjwwDyKXU"  # found in the Auth0 dashboard Clients->General Tab->Secret
-SOLARA_OAUTH_CLIENT_SECRET="XQlByE1pVIz5h2SBN2GYDwT_ziqArHJgLD3KqMlCHjg" # found in the Auth0 dashboard Clients->General Tab->ID
-SOLARA_OAUTH_API_BASE_URL="solara-dev.fief.dev"  # found in the Fief dashboard Tenants->Base URL
- # different from Solara's default
-SOLARA_OAUTH_LOGOUT_PATH="logout"
-```
-
-### Generating a secret key
-
-To generate a secret key, you can use the following code:
-
-```bash
-$ python -c "import secrets; print(secrets.token_urlsafe(32))"
-ZgrzSLUyft-JvnNMNJ2LgbCFVqcxPOatANAQhMD5EYU
-```
-
-*Note: do not copy this key, run this yourself in a terminal.*
-
-
-## OAuth Component
-
-Solara provides two convenient components for creating a user interface for login and logout:
-
- 1. [Avatar](/documentation/components/enterprise/avatar): This component shows the user's avatar.
- 2. [AvatarMenu](/documentation/components/enterprise/avatar_menu): This component shows a menu with the user's avatar and a logout button.
-
- ## Python version support
-
-Please note that Python 3.6 is not supported for Solara OAuth.
-
-
-## Possible issues
-
-### Wrong redirection
-
-If the redirection back to solara return to the wrong address, it might be due to solara not choosing the right default for `SOLARA_BASE_URL`. For instance this variable could be set to `SOLARA_BASE_URL=https://solara.dev` for the solara.dev server. If you application runs behind a subpath, e.g. `/myapp`, you might have to set `SOLARA_ROOT_PATH=/myapp`.

solara/website/pages/documentation/advanced/content/40-development/01-contribute.md

@@ -1,45 +0,0 @@
----
-title: Contributing to Solara
-description: You do not need to be a developer to contribute to Solara. We welcome all contributions, bug reports, documentation improvements and code contributions.
----
-# Contributing to Solara
-
-You do not need to be a developer to contribute to Solara. We welcome all contributions, bug reports, documentation improvements and code contributions.
-
-
-## Bug reports
-
-We use [GitHub to manage issues](https://github.com/widgetti/solara/issues/new) and you should not hesitate to report any bug you find. Please include as much information as possible for us to be able to reproduce the bug. Yes, reporting a bug/issue is a contribution!
-
-It might take a while for us to get back to you. If the bug is urgent, and you are able to provide financial support for its rapid resolution, please [contact us](/contact).
-If you can fix the bug yourself, please consider submitting a pull request instead, see [the development guide](/documentation/advanced/development/setup) for more information.
-
-If you are unable to address the bug yourself and find it challenging to provide financial support, please be assured we are still committed to rectifying bugs and resolving issues. However, please understand that our ability to address these issues may be impacted by our resources at hand, as sustaining this project also entails financial obligations. Your patience and understanding in this matter is highly appreciated 🙇.
-
-## Documentation
-
-The documentation is mostly written in Markdown, and can be found at [in the main repository](https://github.com/widgetti/solara/tree/master/solara/website/pages).
-
-You can use the GitHub web interface to edit the files, or clone the repository and edit them locally. See [the development guide](/documentation/advanced/development/setup) for more information.
-
-If you locally want to render the documentation, run:
-
-```bash
-$ solara run solara.website.pages
-```
-
-## Examples or showcase
-
-If you have a complete program you want to share, and you think it would be cool to be listed at [our showcase page](/showcase), [please contact us](/contact).
-
-If you want to show a particular way of using Solara that you think is very useful
-for others, but it is not a complete program, consider adding to [the examples](/documentation/examples/). See [the development guide](/documentation/advanced/development/setup) for more information.
-
-## Share your experiences and ideas
-
-If you want to share your thoughts, share your experiences, or just want to talk
-to other people using and developing on Solara, consider using [GitHub discussions](https://github.com/widgetti/solara/discussions) for asynchronous discussions
-or consider joining discord for more synchronous discussions.
-
-
-[![Discord Shield](https://discordapp.com/api/guilds/1106593685241614489/widget.png?style=banner2)](https://discord.gg/dm4GKNDjXN)

solara/website/pages/documentation/advanced/content/40-development/10-setup.md

@@ -1,76 +0,0 @@
----
-title: Development setup for Solara
-description: Learn how to set up your installation for developing on the Solara itself.
----
-# Development
-
-See also [the contributing guide](/documentation/advanced/development/contribute) for more information on how to contribute to Solara.
-## Development setup
-
-Assuming you have created a virtual environment as described in [the installation guide](/documentation/getting_started/installing), you can install a development install of Solara using:
-
-    $ git clone git@github.com:widgetti/solara.git
-    $ cd solara
-    $ pip install ".[dev,documentation]"  # documentation is optional
-
-
-## Running Solara server in auto restart mode
-
-By passing the `--auto-restart/-a` flag, the solara server will automatically restart when the sourcecode of the solara server changes, which makes it friendlier for development
-
-    $ solara run myscript.py -a
-
-This will:
-
-    * Automatically restart the server if any of the source code of solara changes (excluding solara.website)
-
-## Contributing
-
-If you plan to contribute, also run the following:
-
-    $ pre-commit install
-
-This will cause a test of linters/formatters and mypy to run so the code is in good quality before you git commit.
-
-    $ playwright install
-
-This will install playwright, for when you want to run the integration tests.
-
-### Test suite
-
-If you want to run the unit tests (quick run when doing development, or when you do test driven development)
-
-    $ py.test tests/unit
-
-
-If you want to run the integration tests (uses playwright to open a browser to test the live server with a real browser)
-
-    $ py.test tests/integration
-
-Pass the `--headed` flag to see what is going on, [or check out the docs](https://playwright.dev/python/docs/intro)
-
-
-### Creating a PR
-
-Make sure you forked the repository, and set up the remote and origin correctly.
-
-```
-# rename origin to upstream
-$ git remote rename origin upstream
-# add your fork as origin
-$ git remote add origin https://github.com/yourusername/solara.git
-```
-
-Now we will create a branch, push it, and open a PR
-
-```
-# create a branch
-$ git checkout -b fix_some_thing
-# add whatever changes you want to make
-$ git add -p
-# commit your changes
-$ git commit -m "fix: some thing"
-# push your changes
-$ git push
-# click the link that is printed to open a PR
-```

solara/website/pages/documentation/api/__init__.py

@@ -1,19 +0,0 @@
-"""
-# Overview
-Click on one of the items on the left.
-"""
-
-import solara
-from solara.website.components import CategoryLayout, Gallery
-
-_title = "API"
-
-
-@solara.component
-def Page(route_external=None):
-    Gallery(route_external)
-
-
-@solara.component
-def Layout(children=[]):
-    CategoryLayout(children=children)

solara/website/pages/documentation/api/cross_filter/__init__.py

@@ -1,9 +0,0 @@
-import solara
-from solara.website.components import NoPage, SubCategoryLayout
-
-Page = NoPage
-
-
-@solara.component
-def Layout(children=[]):
-    SubCategoryLayout(children=children)