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

docs: Add readthedocs examples #1423

Merged
merged 4 commits into from
Jun 12, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 18 additions & 5 deletions examples/README.md
Original file line number Diff line number Diff line change
@@ -1,18 +1,31 @@
# Examples

These examples demonstrate the main features of `pixi`. To run an example move to the folder and run `pixi run start`
This will start the main application of the project. Some projects have more run commands available for that check the `pixi.toml`
These examples demonstrate the main features of `pixi`. To run an example move
to the folder and run:

NOTE: Make sure your on the latest version or the version of pixi on which you are trying the examples.
```bash
pixi run start
```

This will start the main application of the project. Some projects have more run
commands available:

```bash
pixi task list
```

> [!IMPORTANT]
>
> Make sure you are on the latest version of `pixi` to try the examples.

## Examples in other Repositories

These are examples that are hosted in other repositories that use pixi for building and running the project.

### AI

[Llama.cpp](https://github.com/tdejager/llama.cpp)
- [Llama.cpp](https://github.com/tdejager/llama.cpp)

### Games

[Crispy Doom](https://github.com/baszalmstra/pixi-crispy-doom)
- [Crispy Doom](https://github.com/baszalmstra/pixi-crispy-doom)
1 change: 1 addition & 0 deletions examples/readthedocs-extend/.gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
build/
24 changes: 24 additions & 0 deletions examples/readthedocs-extend/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# ReadTheDocs: Extend Build

This example shows how to [extend] a [ReadTheDocs] `sphinx` build by customizing:
- `docs/.readthedocs.yaml` to:
- install native `apt` packages to support a heavyweight dependency
- bootstrap a [conda.environment] with the supported `mambaforge`
- prepare a `pixi` environment with [build.jobs]
- avoid another file in the project root
- this requires manual configuration in the ReadTheDocs web UI
- `docs/conf.py` to:
- support extended ReadTheDocs features provided by [readthedocs-sphinx-ext]
- allow the default build to run against an un-published `rtd.rst`
- use `sphinx` lifecycle events to run the actual build with `pixi` tasks

> [!NOTE]
>
> For a simpler `mkdocs` build, see the [`readthedocs-override`][override] example.

[ReadTheDocs]: https://readthdocs.com
[extend]: https://docs.readthedocs.io/en/stable/build-customization.html#extend-the-build-process
[build.jobs]: https://docs.readthedocs.io/en/stable/config-file/v2.html#build-jobs
[readthedocs-sphinx-ext]: https://github.com/readthedocs/readthedocs-sphinx-ext
[conda.environment]: https://docs.readthedocs.io/en/stable/config-file/v2.html#conda-environment
[override]: ../readthedocs-override/README.md
30 changes: 30 additions & 0 deletions examples/readthedocs-extend/docs/.readthedocs.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
version: 2

build:
os: ubuntu-22.04
apt_packages:
- libasound2
- libatk1.0-0
- libcups2
- libdbus-glib-1-2
- libgtk-3-0
- libnss3
- libpangocairo-1.0-0
- libx11-xcb1
- libxcomposite1
- libxcursor1
- libxdamage1
- libxi6
- libxrandr2
- libxss1
- libxtst6
tools:
python: mambaforge-latest
jobs:
pre_build:
- pixi install --environment=rtd
sphinx:
builder: html
configuration: docs/conf.py
conda:
environment: docs/environment.yml
25 changes: 25 additions & 0 deletions examples/readthedocs-extend/docs/conf.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
import os
import subprocess

RTD = "READTHEDOCS"

if os.getenv(RTD) == "True":
root_doc = "rtd"

def setup(app) -> None:
"""Customize the sphinx build lifecycle."""

def _run_pixi(*_args) -> None:
args = ["pixi", "run", "-e", "rtd", "rtd"]
env = {k: v for k, v in os.environ.items() if k != RTD}
subprocess.check_call(args, env=env)

app.connect("build-finished", _run_pixi)
else:
# exclude RTD
exclude_patterns = ["rtd.rst"]

# the "real" configuration goes here...
extensions = ["myst_parser"]

# ... RTD will add additional configuration here
6 changes: 6 additions & 0 deletions examples/readthedocs-extend/docs/environment.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
channels:
- conda-forge
- nodefaults
dependencies:
- pixi
- pip
1 change: 1 addition & 0 deletions examples/readthedocs-extend/docs/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
# ``pixi`` on ReadTheDocs
4 changes: 4 additions & 0 deletions examples/readthedocs-extend/docs/rtd.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
RTD
===

This is provided for the default ReadTheDocs build, and is not published.
2,769 changes: 2,769 additions & 0 deletions examples/readthedocs-extend/pixi.lock

Large diffs are not rendered by default.

38 changes: 38 additions & 0 deletions examples/readthedocs-extend/pixi.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
[project]
name = "readthedocs-extend"
platforms = ["linux-64", "osx-64", "win-64", "osx-arm64"]
channels = ["conda-forge"]

[environments]
rtd = ["docs", "rtd"]
docs = ["docs", "dev"]

[feature.dev.tasks.start]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about adding a test task which can run in CI, we have a tests/test_examples.sh which runs some of our examples in the CI to verify no weird behavior was introduced.

Not a must, but could be a good example to run more often.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems out-of-scope for this PR (which, if you'll recall, is the second PR to try to get this content based on trying to share my experiences using pixi to get open source work done), but can do so if we're spinning for the CF issue.

I'm likely not qualified to add test tasks to each of the examples, as many of them are intended to be interactive, and may require exotic techniques to properly test beyond

  • does it pixi r install
  • does pixi r start result in a process that stays running for more than five seconds

The interesting wrinkle in this case is that one would really want pixi to be matrixed across:

  • a minimum-pixi or whatever from old pixi cannot parse parse project manifests from new version #1346 as a baseline
    • as a stopgap, examples/p{ixi,yproject}.toml#tool.pixi-example-test could provide a temporary place for this, as the point is they continue to work with older versions
  • the system-under-test nightly or whatever from an upstream GHA artifact from that last-good main
    • the rust build is... not fast, and this matrix will be... really not fast

However... also out-of-scope, and while this could be done out-of-band, this points to a very real use case for #1285. As I keep thinking about these issues, I keep coming back to a future grammar of depends-on (along with #1330, #1272).

this repo's root pixi.toml would only need to declare a single task

[tasks.test-examples]
depends-on = [
  {task = "test", project=["examples/*/"]},
]

The advantage here over punting to a .sh (always a problem on stock windows) would be in e.g. reporting and listing (a la #1434, #1344). Indeed, being able to pixi task list --status (and always in --json) to show the last-known error code would be wonderful for projects trying to adopt pixi at scale.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm likely not qualified to add test tasks to each of the examples, as many of them are intended to be interactive, and may require exotic techniques to properly test beyond

Don't worry was just curious if you knew a neat way of testing the RTD examples in an on interactive way. I've never tried RTD in a production setting myself, that was the source of the question.

When we get pixi build (which depends on rattler-build) in a proper state, we'll most likely try to start on a way to do "workspaces". Which in my idea of a "workspace" includes a lot of those ideas. Which our examples would be an first user of. So please hold tight! 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As with any third-party integration, the RTD case wouldn't be testable without some kind of real event (usually a commit) and then an API request. It would require secrets, which would ratchet up the complexity significantly.

pixi build (which depends on rattler-build)

Welp... not to keep telling you and your team your business, but... maybe just a little: this perspective suggests a team's goal is delivering a matrix of .conda packages as a first-class output of both its subprojects and its ultimate deliverable. This is totally awesome for e.g. conda-forge, which basically exists only to ship .conda packages, and indeed, a near term PR to use pixi in conda-smithy would be... amazing. Indeed, miniforge would benefit substantially from this, if #1375 (or even #1216, as a stopgap) took some of that pain away.

In a corporate, research, or even large open source project setting, the ultimate output of a whole team's multi-month effort might be a horrifying contraption of nodejs -> python -> rattler -> constructor -> packer (plus a bunch of docs, tests, static analysis reports, etc.), which pixi could probably reduce to a single command on a devleoper's desktop. But this is probably not feasible for every task to be defined inside a single pixi.toml file (and even YAML &anchors might not help too much) and pixi-calling-pixi-from-cmd feels... bad.

Looking across even smaller open source projects, there's an enormous value proposition in a generalized, self-documenting, observable, schema-constrained, rework-reducing task model that does predictable, non-magical environment provisioning based on a number of smaller projects, stored in one or more repos, that keeps working, even for historic builds.

cmd = "sphinx-autobuild docs ./build/docs"

[feature.docs.tasks.docs]
cmd = "sphinx-build -W --keep-going --color -b html docs ./build/docs"
inputs = ["docs/"]
outputs = ["build/docs/.buildinfo"]

[feature.docs.dependencies]
firefox = "115.*"
ruben-arts marked this conversation as resolved.
Show resolved Hide resolved
myst-parser = "*"
sphinx = "*"

[feature.dev.dependencies]
sphinx-autobuild = "*"

[feature.rtd.tasks.rtd]
cmd = """
rm -rf $READTHEDOCS_OUTPUT/html
&& cp -r build/docs $READTHEDOCS_OUTPUT/html
"""
depends-on = ["docs"]
inputs = ["build/docs/"]


[feature.rtd]
platforms = ["linux-64"]
dependencies = {requests = "*", jinja2 = ">=2.9", packaging = "*"}
pypi-dependencies = {readthedocs-sphinx-ext = "*"}
11 changes: 11 additions & 0 deletions examples/readthedocs-override/.readthedocs.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
\version: 2
build:
os: ubuntu-22.04
tools:
# this ensures a viable `mamba` is on `$PATH``
python: mambaforge-latest
commands:
- mamba install -c conda-forge -c nodefaults pixi
- pixi install
- pixi run docs
- pixi run readthedocs
17 changes: 17 additions & 0 deletions examples/readthedocs-override/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
# ReadTheDocs: Override Build

> [!WARNING]
> The full build override feature is still in _beta_. See the ReadTheDocs
> [documentation][override] for more.

This example shows how to [override] a [ReadTheDocs] `mkdocs` build by using
`pixi` in [build.commands].

> [!NOTE]
>
> For a more involved `sphinx` build, see the [`readthedocs-extend`][extend] example.

[ReadTheDocs]: https://readthdocs.com
[override]: https://docs.readthedocs.io/en/stable/build-customization.html#override-the-build-process
[build.commands]: https://docs.readthedocs.io/en/stable/config-file/v2.html#build-commands
[extend]: ../readthedocs-extend/README.md
1 change: 1 addition & 0 deletions examples/readthedocs-override/docs/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
# `pixi` on ReadTheDocs
3 changes: 3 additions & 0 deletions examples/readthedocs-override/mkdocs.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
site_name: basic example
nav:
- README: index.md
Loading
Loading