Add Pixi Environment Setup for brian2wasm

[PalashChitnavis]

Setup Pixi Environment for brian2wasm

Closes #12

This PR adds support for using Pixi to simplify setting up the build environment for brian2wasm.

Pixi automates:

• Installing and activating the Emscripten SDK (emsdk)
• Managing the environment for brian2wasm development

---

Steps to Use:

1. Install Pixi — Installation Guide

2. In the root directory (where pyproject.toml is located), run:

pixi install

3. Activate the environment:

pixi shell

4. Run your script

python -m brian2wasm script.py

From the next time onward, simply running pixi shell will drop you into the fully set-up environment.

[PalashChitnavis]

Right now, the activation script does three things:
1. emsdk install
2. emsdk activate
3. source emsdk_env.sh

When setting up the environment for the first time, emsdk install && emsdk activate downloads and activates packages that can be around 150–200 MB, so it may take some time initially.

Would it be better to separate these into two tasks — one for emsdk install && emsdk activate that runs only the first time (or when the user wants to update the emsdk version), and the activation script (which runs every time) for sourcing the emsdk_env.sh file into the environment?

I’ll add GitHub Actions for testing this PR in a couple of days.

[mstimberg]

Good start – apologies it took me so long to take a look. I think it would indeed be the best to move the install and activate into a pixi task. Regarding the activation script: given that we are doing this in the brian2wasm repository for now, we can directly refer to the script as brian2wasm/emsdk_setup.sh without having to know where it will be installed inside the environment (the script actually doesn't need to be installed in that case). And within the activation script, we can use the CONDA_EMSDK_DIR variable that is added by the emsdk package. This means we don't have to fix the Python version and construct the path ourselves. Hope that was clear, please let me know otherwise!

[mstimberg]

Just a quick comment: I don't think we need any authentication here – we don't want to push anything, and we download only from public channels.

[PalashChitnavis]

I followed the Pixi GithHub Actions guide with the approach of installing Pixi, setting up the environment, and then checking whether emsdk, emcc, brian2wasm, and emrun are available.

Since the guide requires an auth-token, I’ve included it in the workflow.

However, I’m facing an issue: when trying to check whether these tools exist, it returns false for emcc and emrun. It seems the script is unable to enter the Pixi shell and throws an error.

[PalashChitnavis]

Hi @mstimberg,
Is there currently a way to only build the WebAssembly files without starting the server? Essentially, I’d like to generate the necessary output (e.g., index.html, .wasm, etc.) but skip the emrun step.

[mstimberg]

Is there currently a way to only build the WebAssembly files without starting the server? Essentially, I’d like to generate the necessary output (e.g., index.html, .wasm, etc.) but skip the emrun step.

Hi @PalashChitnavis. I've seen that you already implemented a workaround, and I think this is the best solution for now. There are two issues: The current brian2wasm code does not only run the simulation in run, but also generates the HTML file there. This should move into compile_source, I think. But even when this is fixed, preventing the run would mean calling set_device with build_on_run=False, and then after the run statement, call device.build(run=False). This is not difficult to do in a script, but of course more complicated in the CLI tool where you only add something to the beginning of the code.

For now, your workaround is fine, but I think the best solution would be to:

1. Move everything that is not about running the code to compile_source
2. Add a new "build_option" so that one can call set_device("wasm_standalone", run=False) – but ideally this would be done at the level of brian2, not brian2wasm.

But let's deal with this later, don't worry about it for this PR.

[PalashChitnavis]

Hi @mstimberg,
The current method does not seem to be working on Linux-based systems. I’m encountering the following error during execution:

shared:INFO: (Emscripten: Running sanity checks)
cache:INFO: generating system asset: symbol_lists/b9ffc9bfa2ead46e562886af0a5c4ca8043aac2d.json... (this will be cached in "/home/runner/work/brian2wasm/brian2wasm/.pixi/envs/default/lib/python3.13/site-packages/emsdk/upstream/emscripten/cache/symbol_lists/b9ffc9bfa2ead46e562886af0a5c4ca8043aac2d.json" for subsequent builds)
processing system library: library_int53.js
processing system library: library.js
processing system library: library_sigs.js

GitHub Actions log: https://github.com/brian-team/brian2wasm/actions/runs/15845645524/job/44667072411?pr=16

I’m not sure why this is happening, as it works correctly on macOS. Do you have any idea what might be causing this?

[PalashChitnavis]

wasm-ld: error: unknown argument: -R/home/runner/work/brian2wasm/brian2wasm/.pixi/envs/default/lib
wasm-ld does not support the -R flag.

[mstimberg]

wasm-ld: error: unknown argument: -R/home/runner/work/brian2wasm/brian2wasm/.pixi/envs/default/lib
wasm-ld does not support the -R flag.

Indeed… Your workaround is good enough for now, as you probably saw we do a similar thing for --enable-new-dtags. The underlying issue is that we use setuptools/distuils to determine the compiler/linker arguments, but those will use the syntax of the respective default compiler for the platform, which means it will use gcc syntax on Linux. In the long run, we will probably have to skip this step and transform everything into emcc arguments ourselves.