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

solara/website/pages/documentation/getting_started/content/05-fundamentals/00-overview.md

@@ -1,7 +0,0 @@
-# Fundamentals
-
-If you want to dive deeper into Solara, this section is for you. We will cover the following topics:
-
-  * [Components](/documentation/getting_started/fundamentals/components)
-  * Hooks (soon)
-  * [State management](/documentation/getting_started/fundamentals/state-management)

solara/website/pages/documentation/getting_started/content/05-fundamentals/10-components.md

@@ -1,218 +0,0 @@
-<!-- TODO: column auto -->
-
-# Introduction to Components
-
-In Solara, components are the building blocks of your web application. They allow you to create modular, reusable, and maintainable user interface (UI) elements that can be combined to create a complete and interactive application. Components can range from simple UI elements, such as buttons or text inputs, to more complex and custom visualizations or forms.
-
-The primary benefits of using components in Solara include:
-
- * Modularity: Components can be designed independently and then combined to form more complex UIs. This modular approach promotes separation of concerns, making it easier to reason about and maintain each part of your application.
- * Reusability: Components can be reused across different parts of your application or even across multiple projects. This can save time and effort by reducing the need to rewrite similar code and can lead to more consistent UIs.
- * Maintainability: By breaking your application into smaller, self-contained components, it becomes easier to understand, debug, and update your code. This results in more maintainable and resilient applications.
- * Performance: When a component instance depends on a specific state, and that state changes, only the render function of the affected component instance will be re-executed. This selective re-rendering ensures that other components or instances that do not depend on the changed state remain unaffected, leading to more efficient performance.
-
-## Types of Components
-
-In Solara, there are two main types of components: Widget Components and Function Components.
-
-## Widget components
-
-Widget Components correspond to ipywidgets and are responsible for rendering visual elements in the browser, such as buttons, sliders, or performing layout tasks. These components are the foundation of your user interface and provide the essential building blocks for creating interactive applications.
-
-Solara mainly uses the [ipyvuetify library](/documentation/advanced/understanding/ipyvuetify) for its widget components. It provides a set of high-level components that can be used to create rich, interactive user interfaces.
-
-See the [components page](/documentation/components) for a complete list of basic UI components.
-
-## Function Components
-
-Function Components (Components for short), on the other hand, are responsible for combining logic, state, and other components to create more complex and dynamic applications. These components serve as a way to create reusable and modular structures that can be easily integrated into your application.
-
-These are the components that you will be writing when building Solara applications.
-
-By utilizing both Widget Components and Function Components, you can create flexible and powerful applications that provide a rich user experience while maintaining a clean and organized codebase.
-
-## Creating New Components
-
-In Solara, users can create their own custom components without any special distinction from the built-in components provided by the framework, they are all components. These user-defined components have the same capabilities and can be composed seamlessly alongside Solara's components, allowing for the creation of highly customized and reusable user interfaces.
-
-# Defining Components
-To create a component in Solara, you'll start by defining a Python function decorated with @solara.component. Inside the function, you can create the component's structure by calling Solara's built-in components or creating custom components to suit your specific needs. If a single element is created, it's taken as the component's main element. If multiple elements are created, they are automatically wrapped in a Column component.
-
-Here's an example of a simple Solara component that displays a button:
-
-```python
-import solara
-
-@solara.component
-def MyButton():
-    solara.Button("Click me!")
-```
-
-In this example, we create a component function named MyButton and apply the @solara.component decorator to it. Within the component function, a Button component from Solara is created, displaying the text "Click me!".
-
-## Using Components
-Once you've created your components, you can use them in your Solara app by calling the components to create elements. Elements, the lightweight representations of components, can be combined to build complex UIs. They can also be passed as arguments to other components, enabling a flexible and modular application structure.
-
-Here's an example of using the `MyButton` component we defined earlier:
-
-```python
-import solara
-
-@solara.component
-def MyApp():
-    MyButton()
-    MyButton()
-```
-
-In this example, we create a `MyApp` function decorated with `@solara.component`. The function create two MyButton elements, resulting in two buttons (or two component instances).
-
-## Handling User Interactions
-Components in Solara can capture user input and respond to events, such as button clicks or form submissions. To handle user interactions, you'll define callback functions and connect them to your components using Solara's event handling system.
-
-Here's an example of a Solara component that displays a button and responds to click events:
-
-```python
-import solara
-
-def on_button_click(event):
-    print("Button clicked!")
-
-@solara.component
-def MyInteractiveButton():
-    solara.Button("Click me!", on_click=on_button_click)
-```
-
-In this example, we define a function called on_button_click that will be executed when the button is clicked. In the MyInteractiveButton function, we create a Button component and set the on_click argument to the on_button_click function.
-
-By following these steps, you can create and use components to build rich, interactive applications with Solara.
-
-
-## Component Arguments and State
-In Solara, components can accept arguments and maintain internal state to manage their behavior and appearance. This section will explain how to use arguments and state in your Solara components and provide code examples to demonstrate their usage.
-
-### Component Arguments
-Arguments are the values that you pass to a component when you call it, allowing you to customize its behavior and appearance. You can define the arguments your component accepts by specifying them as parameters in the component function. This makes your components more reusable and flexible, as you can easily modify their behavior by passing different argument values.
-
-Here's an example of a Solara component that accepts an argument:
-
-```python
-import solara
-
-@solara.component
-def MyButton(text):
-    solara.Button(text)
-```
-
-In this example, we define a function called MyButton that takes a single argument, text. The render function creates a Button component from Solara with the specified text.
-
-### Using Application state in Components
-To manage the state of a component in Solara, you can use the solara.reactive() function to create reactive variables. Reactive variables are used to store values that can change over time and automatically trigger component updates when their values change. This allows you to create components that respond to changes in data and user interactions.
-
-Here's an example that demonstrates the use of reactive variables in Solara components:
-```solara
-import solara
-
-counter = solara.reactive(0)
-
-def increment():
-    counter.value += 1
-
-@solara.component
-def CounterDisplay():
-    solara.Info(f"Counter: {counter.value}")
-
-@solara.component
-def IncrementButton():
-    solara.Button("Increment", on_click=increment)
-
-@solara.component
-def Page():
-    IncrementButton()
-    CounterDisplay()
-
-```
-
-In this example, we create a reactive variable counter with an initial value of 0. We define two components: `CounterDisplay` and `IncrementButton`. `CounterDisplay` renders the current value of counter, while `IncrementButton` increments the value of counter when clicked. Whenever the counter value changes, `CounterDisplay` automatically updates to display the new value.
-
-By using arguments and state in your Solara components, you can create more dynamic and interactive applications that respond to user input and changes in data.
-
-### Internal State in Components
-
-In addition to using reactive variables for global or application-wide state, you can also manage internal or component-specific state using the use_state hook in Solara. The use_state hook allows you to define state variables that are local to a component, and automatically trigger updates when their values change.
-
-To use the use_state hook, call the solara.use_state() function inside your component function. This function takes an initial value as an argument and returns a tuple containing the current state value and a function to update the state.
-
-Here's an example that demonstrates the use of the use_state hook to manage internal state in a Solara component:
-
-```solara
-import solara
-
-@solara.component
-def Counter():
-    count, set_count = solara.use_state(0)
-
-    def increment():
-        set_count(count + 1)
-
-    solara.Button("Increment", on_click=increment)
-    solara.Info(f"Counter: {count}")
-
-@solara.component
-def Page():
-    Counter()
-```
-
-In this example, we define a Counter component that uses the use_state hook to manage its internal state. We create a state variable count with an initial value of 0 and a function set_count to update the state. The increment function increments the value of count when the button is clicked. Whenever the count value changes, the component automatically updates to display the new value.
-
-By using the use_state hook, you can manage the internal state of your components and create more dynamic and interactive applications that respond to user input and changes in data.
-
-## Lazy Rendering in Solara Components
-
-In Solara, understanding the relationship between components, elements, and instances is essential to grasp the rendering process. Components serve as a blueprint or template for defining the structure and behavior of a part of the user interface. Elements are lightweight virtual representations of components, created when the components are invoked. Instances, on the other hand, represent the function body of the component and its state.
-
-Solara employs a "lazy rendering" approach, where the rendering of a component's children is deferred until it is necessary. When a component is invoked, an element is created immediately, representing that particular instance of the component. However, the actual rendering of the component's children is postponed until the component is rendered within the virtual tree, either as a child of another component or as the root component. This allows Solara to optimize the rendering process and update only the necessary components when the application state or component arguments change.
-
-Lazy rendering in Solara ensures that the render function is executed only when necessary, improving the application's performance. To illustrate this concept, let's consider the following example:
-
-
-```solara
-import solara
-
-counter = solara.reactive(0)
-
-@solara.component
-def CounterDisplay():
-    solara.Info(f"Counter: {counter.value}")
-
-@solara.component
-def IncrementButton():
-    def increment():
-        counter.value += 1
-
-    solara.Button("Increment", on_click=increment)
-
-@solara.component
-def RandomText():
-    import random
-    solara.Info(f"Random number: {random.random()}")
-
-@solara.component
-def Page():
-    IncrementButton()
-    CounterDisplay()
-    RandomText()
-```
-
-In this example, we define several components: `IncrementButton`, `CounterDisplay`, and `RandomText`. The `IncrementButton` component increments the value of the counter reactive variable when clicked. The `CounterDisplay` component displays the current value of the counter. The `RandomText` component displays a random number but does not depend on any state or reactive variables.
-
-When the user clicks the `IncrementButton`, the counter reactive variable is updated, and the `CounterDisplay` component re-renders to show the new value. The RandomText component does not re-render in this scenario because it does not depend on any state or reactive variables.
-
-This example demonstrates Solara's lazy rendering, where only the relevant components are instantiated and rendered based on changes in their arguments or internal state. This ensures that the render function is executed only when necessary, improving the application's performance.
-
-
-## Conclusions
-In conclusion, understanding components, their arguments, and how to manage their internal state is crucial for building Solara applications. To create more advanced components, you need to have a deeper understanding of hooks, such as the use_state hook we have already discussed.
-
-In the next fundamentals article, we will explore more hooks available in Solara, which will enable you to build more sophisticated components that cater to a wide range of use cases. By learning about hooks, you can create powerful components that can manage state, interact with other components, and respond to user input.
-
-To summarize, components are the building blocks of Solara applications, and they can accept arguments to customize their behavior and appearance. Managing state in components can be done either through local (component) state or application-wide state, each with its advantages and disadvantages. By striking a balance between reusable components and application-specific code, you can create scalable and maintainable applications in Solara. With a solid understanding of components and their state management, you are well on your way to creating powerful and interactive web applications with Solara.

solara/website/pages/documentation/getting_started/content/05-fundamentals/50-state-management.md

@@ -1,83 +0,0 @@
-# Introduction
-
-State management is a crucial aspect of building data-focused web applications with Solara. By effectively managing state, you can create interactive and responsive applications that react to changes in data and user input. In Solara, there are two primary ways to define state: global application state using [`solara.reactive`](/documentation/api/utilities/reactive) and local component state using [`solara.use_state`](/documentation/api/hooks/use_state) or [`solara.use_reactive`](/documentation/api/hooks/use_reactive). This article will discuss these two approaches and provide examples of how to use them in your Solara applications.
-
-## Two main ways of defining state in Solara
-
-### Global application state using solara.reactive
-
-Using [`solara.reactive`](/documentation/api/utilities/reactive) allows you to create global state variables that can be accessed and modified from any component within your application. This approach is useful when you need to manage state that is shared across multiple components or when you want to maintain consistency throughout your application.
-
-Example:
-
-```solara
-import solara
-
-color = solara.reactive("red")
-
-@solara.component
-def SomeAppSpecificComponent():
-    solara.Select(label="Color", values=["red", "green", "blue", "orange"], value=color)
-    solara.Markdown("### Solara is awesome", style={"color": color.value})
-
-@solara.component
-def Page():
-    SomeAppSpecificComponent()
-
-```
-
-In this case, the `SomeAppSpecificComponent` is not reusable in the sense that a second component has a different state. The `color` variable is global and shared across all components. This component is meant to be used only once, and mainly helps to organize the code.
-
-## Local component state using solara.use_state
-
-[`solara.use_state`](/documentation/api/hooks/use_state) is a hook that allows you to manage local state within a specific component. This approach is beneficial when you want to encapsulate state within a component, making it self-contained and modular. Local state management is suitable for situations where state changes only affect the component and do not need to be shared across the application.
-
-Example:
-```solara
-import solara
-
-@solara.component
-def ReusableComponent():
-    # color = solara.use_reactive("red")  # another possibility
-    color, set_color = solara.use_state("red")  # local state
-    solara.Select(label="Color",values=["red", "green", "blue", "orange"],
-                    value=color, on_value=set_color)
-    solara.Markdown("### Solara is awesome", style={"color": color})
-
-@solara.component
-def Page():
-    # this component is used twice, but each instance has its own state
-    ReusableComponent()
-    ReusableComponent()
-
-```
-
-## Local component state using solara.use_reactive
-
-
-`use_reactive` is the middle ground between `use_state` and `reactive`. It allows you to create a reactive variable that is scoped to a specific component. This is more a matter of taste, we generally recommend using `use_reactive`, but if you prefer a little less magic, you can use `use_state` instead.
-
-
-If we take the previous example using `use_state`, are replace `use_state` by `use_reactive`, we get:
-```solara
-import solara
-
-@solara.component
-def ReusableComponent():
-    color = solara.use_reactive("red")  # another possibility
-    solara.Select(label="Color",values=["red", "green", "blue", "orange"],
-                  value=color)
-    solara.Markdown("### Solara is awesome", style={"color": color.value})
-
-@solara.component
-def Page():
-    # this component is used twice, but each instance has its own state
-    ReusableComponent()
-    ReusableComponent()
-
-```
-
-## Conclusion
-Understanding the advantages and disadvantages of reusable components and application-specific code can help you strike the right balance between modularity and simplicity when building your Solara applications.
-
-By understanding the trade-offs between local and application state, as well as reusable components and application-specific code, you can make better decisions when designing and building your Solara applications. Both approaches have their benefits and drawbacks, but choosing the right method for your specific use case will help you create more efficient, maintainable, and scalable applications.

solara/website/pages/documentation/getting_started/content/06-reference/00-overview.md

@@ -1,3 +0,0 @@
-# Reference documentation
-
-Our reference documentation informs you about how certain parts in Solara work.

solara/website/pages/documentation/getting_started/content/06-reference/40-static_files.md

@@ -1,27 +0,0 @@
-# Static files
-
-Files located on your local filesystem at the `../public` directory will be served by the Solara server at `/static/public`. A typical directory layout looks like this:
-
-```
-├── pages
-│   ├── 01-landing-page.md
-│   ├── 02-some_app.py
-└── public
-    └── beach.jpeg
-```
-
-For instance, on this server, the `beach.jpeg` file will be available at `/static/public/beach.jpeg` and the full URL will be [`https://solara.dev/static/public/beach.jpeg`](https://solara.dev/static/public/beach.jpeg)
-
-Putting the `public` directory 1 level higher than the `pages` directory avoids name collision with pages.
-
-```solara
-import solara
-
-
-@solara.component
-def Page():
-    image_url = "/static/public/beach.jpeg"
-    with solara.Card(title="The following image is served from the ../public directory"):
-        solara.Image(image_url)
-
-```

solara/website/pages/documentation/getting_started/content/06-reference/41-asset-files.md

@@ -1,32 +0,0 @@
-# Assets files
-
-Asset files are special files with are loaded by Solara-server and thus have a special meaning, and come with defaults. Current supported assets files are:
-
- * `favicon.png` - Image shown by the browser (usually in the tab).
- * `style.css` - Default `CSS` used by Solara.
- * `custom.css` - Custom `CSS` you can override for your project (empty `CSS` file by default).
- * `custom.js` - Custom Javascript you can use for your project (empty Javascript file by default).
- * `theme.js` - Javascript file containing the definitions for [vuetify themes](https://v2.vuetifyjs.com/en/features/theme/) ([example theme.js file](https://github.com/widgetti/solara/blob/master/solara/website/assets/theme.js)).
-
-
-Assets files can be overridden by putting a file in the `../assets` directory.  A typical directory layout looks like this:
-
-```
-├── pages
-│   ├── 01-landing-page.md
-│   ├── 02-some_app.py
-└── public
-    └── beach.jpeg
-└── assets
-    ├── custom.css
-    ├── custom.js
-    ├── theme.js
-    └── favicon.png
-```
-
-All assets files are served under `/static/assets/<filename>`, but how the assets go to the browser is considered an implementation detail (we could bundle/minimize the css for instance).
-
-Putting the `assets` directory 1 level higher than the `pages` directory avoids name collision with pages.
-
-
-Although the `assets` directory can be used for serving arbitrary files, we recommend using the [static files](/documentation/getting_started/reference/static-files) directory instead, to avoid name collisions.

solara/website/pages/documentation/getting_started/content/06-reference/60-static-site-generation.md

@@ -1,55 +0,0 @@
-## Static Site Generation
-## Introduction
-Solara's static site generation (SSG) feature allows you to pre-render HTML for your website, improving the user experience by providing quick page loads. When a user requests a page, the pre-rendered HTML is served directly to the user. After the page is displayed, the Solara server will connect and take over rendering to make the page interactive.
-
-Using SSG is mostly useful when the content of your website is the same for all users. This is the case for this page (the Solara page itself).
-
-## Benefits of SSG
-Another benefit of using SSG is improved search engine optimization (SEO). By allowing web crawlers to index your pages, you can improve the visibility of your website in search engine results.
-
-In addition to improving SEO, using SSG can also help with indexing your pages and making them more easily discoverable by users.
-
-## Using Solara's SSG feature.
-
-### Requirements
-
-Using SSR requires installation of [Playwright for Python](https://playwright.dev/python/). Follow their [installation instructions](https://playwright.dev/python/docs/library) or simply execute:
-
-
-```
-$ pip solara-enterprise[ssg]
-$ playwright install
-```
-
-### Pre-deployment
-
-Using the command
-
-```
-$ solara ssg your.awesome.app
-```
-
-Will run the solara server and use playwright to fetch all known pages and save them to the `../build` directory. Solara knows about your pages because of its [routing support](/documentation/advanced/understanding/routing).
-
-All HTML files in the `../build` will be used to pre-populate the HTML served to the user.
-
-### During deployment
-
-For fast and simpler deployment, you can also add the `--ssg` flag to the `solara run` command, e.g.:
-
-```
-$ solara run our.awesome.app --ssg
-```
-
-This will start you server immediately, and start a thread in the background that will fetch the known pages and put the in the `../build` directory, similar to the [pre-deployment](#pre-deployment) procedure.
-
-
-The downsides of this method, is that users or crawlers may request a page when SSR is not done yet, leading to a slower page load or missing content for the crawler.
-
-## Configuration
-
-### Environment variables
-
- * `SOLARA_SSG_BUILD_PATH`: Override the directory where there html pages are stored.
- * `SOLARA_SSG_ENABLED`: Alternative to passing the `--ssg` flag. Should be used when running solara without `solara run` (e.g. using gunicorn/uvicorn).
- * `SOLARA_SSG_HEADED`: Run playwright using `headed` mode (in contrast to `headless`). Useful for debugging.

solara/website/pages/documentation/getting_started/content/06-reference/70-search.md

@@ -1,30 +0,0 @@
-# Search
-
-Solara can provide search, if [SSG](/documentation/getting_started/reference/static-site-generation) is enabled. This allows you to add a search box to you website, which performs a full-text search to provide quick access to pages. The solara website itself uses the
-search feature as well in the toolbar.
-
-## Using Solara's Search feature.
-
-By running `solara run myapp.pages --ssg --search` solara will fetch all your pages, and build up a search index afterards. This option can also be abled using the environment variable `SOLARA_SEARCH_ENABLED=True`.
-
-You can import as use the Search component as follow:
-
-```
-import solara
-from solara_enterprise.search.search import Search
-
-
-@solara.component
-def Page():
-    with MyToolbar():
-        ...
-        Search()
-```
-
-## Requirements
-
-This feature requires `solara-enterprise`, which can be installed as follows:
-
-```
-pip install solara-enterprise
-```

solara/website/pages/documentation/getting_started/content/06-reference/80-reloading.md

@@ -1,30 +0,0 @@
-# Reloading
-
-## Reloading of Python files
-
-Solara will auto detect if your script or the sourcecode of an imported module has changes. If so, Solara will reload the page.
-
-(*Note: Upgrade to solara 1.14.0 for a fix in hot reloading using `pip install "solara>=1.14.0"`*)
-
-## Reloading of .vue files
-
-The solara server automatically watches all `.vue` files that are used by vue templates (there are some used in solara.components for example).
-When a `.vue` file is saved, the widgets get updated automatically, without needing a page reload, aiding rapid development.
-
-## Reloading of .vue files
-
-The [Style component](/documentation/components/advanced/style) accepts a Path as argument, when that is used and the server is in development mode (the default), also
-CSS files will be hot reloaded.
-
-
-## Restarting the server after changes to the solara packages
-
-
-You don't need to care about this feature if you only use solara, this is only relevant for development on solara itself, [see also development instructions](/documentation/advanced/development/setup).
-
-If the `--auto-restart/-a` flag is passed to solara-server and any changes occur in the `solara` package (excluding `solara.webpage`), solara-server will restart. This speeds up development on `solara-server` for developers since you do not
-need to manually restart the server in the terminal.
-
-## Disabling reloading
-
-In production mode (pass the `--production` argument to `solara run`) watching of files is disabled, and no reloading of files or vue templates will occur. If you run solara integrated in flask or uvicorn as laid out in [deployment documentation](https://solara.dev/documentation/getting_started/deploying/self-hosted)

solara/website/pages/documentation/getting_started/content/06-reference/90-notebook-support.md

@@ -1,4 +0,0 @@
-
-# Notebook support
-
-We also support notebooks, simply assign to the `Page` variable in a code cell, save your notebook, and run `$ solara run myapp.ipynb`. If you widget or component is called differently, run like `$ solara run myapp.ipynb:myobject.nested_widget`.

solara/website/pages/documentation/getting_started/content/06-reference/95-caching.md

@@ -1,143 +0,0 @@
-# Caching
-
-Solara has a dict-like object at `solara.cache.storage` that can be used to store objects in under a key. So we can use this global
-object as normal dict, e.g.:
-
-```python
-import solara
-solara.cache.storage["my-key"] = expensive_function_call()
-assert "my-key" in solara.cache.storage
-```
-
-Note that at any time later on, the key may be removed from this object, as a cache always has a limited capacity.
-
-The `solara.cache.storage` cache object is used by [memoize](/documentation/api/utilities/memoize), if no storage argument is passed to this decorator.
-
-## Types of cache
-
-Solara core comes by default with an in-memory cache using a [LRU](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)) (Least recently used) strategy. When the
-cache becomes too full, this removes entries used least recently.
-
-The cache is set by default to:
-```python
-solara.cache.storage = solara.cache.Memory(maxsize=128)
-```
-
-Which will remove the least recently used element when the 129th item is added.
-
-The memory cache is also configurable using environment variable:
-```
-$ export SOLARA_CACHE=memory  # already the default
-$ export SOLARA_CACHE_MEMORY_MAX_ITEMS=128  # already the default
-```
-
-## Custom caches
-An infinite cache can be set using:
-
-```python
-solara.cache.storage = {}  # a regular dict
-```
-
-The [cachetools](https://cachetools.readthedocs.io/) project has some caching types that behave like a Python dict, and are compatible with Solara, e.g.:
-
-```python
-import cachetools
-import solara
-solara.cache.storage = cachetools.FIFOCache(maxsize=100)
-```
-
-## Solara-enterprise
-
-With solara-enterprise, we have more cache storage options.
-
-### Memory (byte size based)
-
-The cache will limit the total number of bytes to a set maximum, instead of the number of items as is with the normal 'memory' cache.
-
-This can be set using code:
-
-```python
-import solara
-solara.cache.configure("memory-size")
-# or more explicit
-import solara_enterprise.cache.memory_size
-solara.cache.storage = solara_enterprise.cache.memory_size.MemorySize(
-    max_size="1GB"  # already the default
-)
-```
-
-The 'memory-size' cache can also be configured using environment variables:
-
-```
-$ export SOLARA_CACHE=memory-size
-$ export SOLARA_CACHE_MEMORY_MAX_SIZE=1GB  # already the default
-
-```
-
-
-### Disk cache
-
-This cache will persist the entries to disk, allowing multiple processes to share the same data. This cache type is ideal when using multiple workers on a single node.
-
-This can be set using code:
-
-```python
-import solara
-solara.cache.configure("disk")
-# or more explicit
-import solara_enterprise.cache.disk
-solara.cache.storage = solara_enterprise.cache.disk.Disk(
-    max_size="10GB", path="/home/maarten/.solara/cache"  # already the default
-)
-```
-
-Or configurable using environment variable:
-```
-$ export SOLARA_CACHE=disk
-$ export SOLARA_CACHE_DISK_MAX_SIZE=10GB  # already the default
-$ export SOLARA_CACHE_PATH_=/home/maarten/.solara/cache  # already the default
-```
-
-### Redis cache
-
-This cache will store the entries in a [Redis](https://redis.io/) server, allowing multiple nodes to share the same data. This is ideal in a cluster/distributed configuration.
-
-This can be set using code:
-
-```python
-import solara
-solara.cache.configure("redis")
-# or more explicit
-import solara_enterprise.cache.redis
-# optionally pass in a redis.Client object
-solara.cache.storage = solara_enterprise.cache.redis.Redis()
-```
-
-Or configured using environment variable:
-```
-$ export SOLARA_CACHE=redis
-```
-
-### Multi-level cache
-
-We can chain a few caches to get a multilevel cache. This allows us to get the benefits of the low latency memory cache while sharing it with other workers and nodes.
-
-```python
-import solara
-solara.cache.configure("memory,disk,redis")
-# or more explicit
-import solara_enterprise.cache.multi_level
-import solara_enterprise.cache.disk
-import solara_enterprise.cache.redis
-l1 = solara.cache.Memory()
-l2 = solara_enterprise.cache.disk.Disk()
-l3 = solara_enterprise.cache.redis.Redis()
-solara.cache.storage = solara_enterprise.cache.multi_level.MultiLevel(
-    l1, l2, l3
-)
-```
-
-Or configured using an environment variable:
-```
-$ export SOLARA_CACHE="memory,disk,redis"
-```

solara/website/pages/documentation/getting_started/content/07-deploying/00-overview.md

@@ -1,3 +0,0 @@
-# Deploying a solara app
-
-A Solara app can be [self hosted](/documentation/getting_started/deploying/self-hosted) or [cloud hosted](/documentation/getting_started/deploying/cloud-hosted).