feat: slides for week 5

henryiii · henryiii · commit b8907291327d · 2025-06-04T11:59:13.000-04:00
Signed-off-by: Henry Schreiner &lt;henryschreineriii@gmail.com&gt;
diff --git a/content/week01/intro.md b/content/week01/intro.md
@@ -132,23 +132,23 @@ provides different printouts for different structures:
 
 ```python
 if isinstance(x, list):
-   print(*x)
+    print(*x)
 elif isinstance(x, dict):
-   print(*(f"{k}={v}" for k, v in x.items()))
+    print(*(f"{k}={v}" for k, v in x.items()))
 else:
-   print(x)
+    print(x)
 ```
 
 versus using pattern matching:
 
 ```python
 match x:
-   case [*_]:
-       print(*x)
-   case {}:
-       print(*(f"{k}={v}" for k, v in x.items()))
-   case _:
-       print(x)
+    case [*_]:
+        print(*x)
+    case {}:
+        print(*(f"{k}={v}" for k, v in x.items()))
+    case _:
+        print(x)
 ```
 
 The pattern matching case is more focused, so it takes less reading. You know
diff --git a/content/week05/packaging.md b/content/week05/packaging.md
@@ -1,12 +1,14 @@
 # Packaging and quality control
 
+[Slides](https://henryiii.github.io/se-for-sci/slides/week-05-1)
+
 Now you have your Git Repo, it's time to talk about how you structure it to make
 it distributable and usable by others. We'll focus on building a Python package,
 though most of the ideas here are available in other ecosystems for modern
 languages. C, C++, and Fortran stick out a bit for not having things like
 standard package managers; you can substitute a build system for these.
 
-## Pip and PyPI
+## Pip / uv and PyPI
 
 Most languages have at least one package manager; "pip" is the canonical package
 manager for Python. To distribute packages for pip to install, either SDists or
@@ -38,7 +40,11 @@ permission, or to your user's site-packages if you don't, or if you are in a
 virtual environment (more on those later), then it installs into that
 environment's site-packages.
 
-## Conda/Mamba/MicroMamba and conda-forge
+There is also a Rust rewrite of pip (and several other tools) called "uv" that
+is faster (think 10-100x faster) and has an alternate high-level API. It's only
+about a year old, but already 20% of the PyPI downloads are now via uv.
+
+## Conda/Mamba/MicroMamba/Pixi and conda-forge
 
 Wheels have been a huge success in binary packaging, but before wheels solved
 many of the problems with binary packaging, conda was developed with different
@@ -58,6 +64,22 @@ that works everywhere, while conda packages bundle everything and are build with
 custom toolchains. Conda distributes Python itself - it's just another
 dependency to Conda, while Pip can only install to an existing Python.
 
+There are several packages, so here's a quick summary:
+
+- **Conda**: The original, written in Python. The resolver is now from Mamba,
+  so it's much closer to speed in mamba that is used to be.
+  a large ecosystem.
+- **Mamba**: A faster, drop-in replacement for conda that uses a different
+  dependency resolver and is written in C++.
+- **MicroMamba**: Used to be different from Mamba, but now is simply a
+  statically linked version of Mamba.
+- **Pixi**: A Rust rewrite of conda, designed around a new high-level API.
+  Unlike uv, it does not have a low-level API to match conda/mamba.
+
+It turns out, writing a tool that can get Python, in Python, has bad
+chicken-and-egg problem.  That's why it's been rewritten not once, but twice, in
+compiled languages.
+
 Which do you pick? I'll focus on PyPI; it's the "official" ecosystem, and most
 conda packages just build PyPI packages. But there are often places (like ML)
 where conda is preferred. Unless you are making your own package (in which case
diff --git a/content/week05/using_packages.md b/content/week05/using_packages.md
@@ -50,12 +50,20 @@ you don't expect to import it, _do not use pip_; use
 environment, but hide all that for you, and then you'll just have an application
 you can use with no global/user side effects!
 
+`````{tab-set}
+````{tab-item} uv
+```bash
+uv tool install black
+black myfile.py
+```
+````
+````{tab-item} pipx
 ```bash
-pip install pipx  # Easier to install like this
-
 pipx install black
 black myfile.py
 ```
+````
+`````
 
 Now you have "black", but nothing has changed in your global site packages! You
 cannot import black or any of it's dependencies! There are no conflicting
@@ -67,17 +75,26 @@ packages that have incompatible requirements).
 Pipx also has a very powerful feature: you can install and run an application in
 a temporary environment!
 
-For example, this works just as well as the second two lines above:
+For example, this works just as well as the lines above:
 
+`````{tab-set}
+````{tab-item} uv
+```bash
+uvx black myfile.py
+```
+````
+````{tab-item} pipx
 ```bash
 pipx run black myfile.py
 ```
+````
+`````
 
 The first time you do this, pipx create a venv and puts black in it, then runs
 it. If you run it again, it will reuse the cached environment if it hasn't been
 cleaned up yet, so it's fast.
 
-Another example:
+Another example (note: for uv, use `uv build`, which is built-in):
 
 ```bash
 pipx run build
@@ -87,13 +104,22 @@ pipx run build
 > you do not need `actions/setup-python` to run it.
 
 If the command and the package have different names, then you may have to write
-this with a `--spec`, though pipx has a way to customize this, and it will try
+this with a `--spec` (`--from` with uvx), though pipx has a way to customize this, and it will try
 to guess if there's only one command in the package. You can also pin exactly,
 specify extras, etc:
 
+`````{tab-set}
+````{tab-item} uv
+```bash
+uvx --from cibuildwheel==2.9.0 cibuildwheel --platform linux
+```
+````
+````{tab-item} pipx
 ```bash
 pipx run --spec cibuildwheel==2.9.0 cibuildwheel --platform linux
 ```
+````
+`````
 
 #### Self-contained scripts
 
@@ -165,11 +191,22 @@ rich >=9.8
 This is technically a valid `requirements.txt` file. If you wanted to use it,
 you would do:
 
+`````{tab-set}
+````{tab-item} uv
 ```bash
-python3 -m venv venv
-. venv/bin/activate
+uv venv
+. .venv/bin/activate
+uv pip install -r requirements.txt
+```
+````
+````{tab-item} pip
+```bash
+python3 -m venv .venv
+. .venv/bin/activate
 pip install -r requirements.txt
 ```
+````
+`````
 
 Use `deactivate` to "leave" the virtual environment.
 
@@ -212,6 +249,20 @@ example, `pip install rich[jupyter]` will add some extra requirements for
 interacting with notebooks. _These add requirements only_, you can't change the
 package with an extra.
 
+### Dependency-groups
+
+You can also use dependency groups, which are a way to specify optional
+dependencies in `pyproject.toml`. This is a new feature, but most recent
+versions of most tools support it. It looks like this:
+
+```toml
+[dependency-groups]
+dev = ["pytest"]
+```
+
+You can install it with `--group dev`. The high-level interface to uv automatically
+installs the `dev` group, so using this makes `uv run` work out of the box.
+
 ### Conda environments
 
 If you use Conda, the environment file is called `environment.yaml`. The one we
diff --git a/slides/week-01-1.md b/slides/week-01-1.md
@@ -106,23 +106,23 @@ for i in range(10):
 
 ```python
 if isinstance(x, list):
-   print(*x)
+    print(*x)
 elif isinstance(x, dict):
-   print(*(f"{k}={v}" for k, v in x.items()))
+    print(*(f"{k}={v}" for k, v in x.items()))
 else:
-   print(x)
+    print(x)
 ```
 
 vs.
 
 ```python
 match x:
-   case [*_]:
-       print(*x)
-   case {}:
-       print(*(f"{k}={v}" for k, v in x.items()))
-   case _:
-       print(x)
+    case [*_]:
+        print(*x)
+    case {}:
+        print(*(f"{k}={v}" for k, v in x.items()))
+    case _:
+        print(x)
 ```
 
 ---
diff --git a/slides/week-05-1.md b/slides/week-05-1.md
