docs: Update dev docs per to describe using uv

[NickCrews]

Please describe the issue

The docs for setting up a dev environment don't describe how to use uv, which is how I would prefer to setup my env.

I think it is uv sync --all-extras --group tests --group docs? But I'm not that familiar with uv, I just started using it myself.

Code of Conduct

• I agree to follow this project's Code of Conduct

[IndexSeek]

I agree, this is something that would be useful. Are you thinking about another entry in the ::: {.panel-tabset} at Setting up a development environment?

I think you're right with the command, it might require the dev group as well.

uv sync --all-extras \
        --group dev \
        --group tests \
        --group docs

[NickCrews]

yes, that looks like the right idea. I also want to take a stab at explaining how all the different parts of the environment are used. For example, I often just develop with uv on my host macOS, NOT inside a container, and I just run the tests with the "easy" backends like duckdb and polars, and then if they pass, then I push to a PR, and then rely on CI to actually test all the "difficult" backends for me. I think explaining this setup might be nice for devs who want a very lightweight setup. I think I will try a PR that explains this setup and see what everyone thinks.

[nickpowersys]

Just for context, I documented uv development usage in a VS Code devcontainer, in the container (uv) section of https://ibis-project.org/contribute/01_environment. The actual uv environment commands are in the Dockerfile (see below). As you said, it would be good to document a non-container setup, as people may have different preferences.

If you want to ensure that uv lock works (meaning it updates the uv.lock file), you may need to name and activate the virtual environment. I found that it did not work otherwise.

According to the uv docs, "Unlike pip, uv requires using a virtual environment by default".
https://docs.astral.sh/uv/pip/environments/

It would be useful to document the use of uv sync as you switch between different branches, if the pyproject.toml dependencies have changed. If someone knows of a way or if uv itself finds a way to make syncing automatic, that could simplify development even further.

I found in using the uv's own Docker example was that when I ran multiple uv sync commands with different dependency groups in sequence, it would uninstall some packages that a previous uv sync had installed. Therefore, it seems easiest to simply determine all of the options, and just re-run the same command every time the set of dependencies has changed in pyproject.toml, modifying the extras or not as needed.

See the uv-related commands in the Dockerfile I contributed at

ibis/.devcontainer/Dockerfile

Lines 27 to 28 in c94db5c

	uv venv && uv sync --group dev --group tests \
	--extra duckdb --extra clickhouse --extra examples --extra geospatial

and

ibis/.devcontainer/Dockerfile

Line 39 in c94db5c

SHELL ["/bin/bash", "-c", "source .venv/bin/activate"]

.

[cpcloud]

Why don't we just make some just commands to make this easier, and if anyone wants to understand what's going on they can read the command definitions, otherwise people can invoke the just commands without having to read a bunch of docs.

[NickCrews]

Sounds good to me. Also would have better odds of staying up to date and funtional

[cpcloud]

The docs for setting up a dev environment don't describe how to use uv, which is how I would prefer to setup my env.

Typically such tools' usage are described in their own documentation. What are you trying to achieve by duplicating such information in the Ibis documentation? Am I understanding what you're after here?

I think documenting, in pyproject.toml, the various dependency groups and what tasks they're used for is useful, but how to use uv IMO is not something we should ever do, since that is what the uv docs are for.

[romaingd]

Hi! Following this discussion, #10959 proposes new just recipes , and a new uv entry to the dev setup panel. Hopefully that fits the bill!