Feature request: ability to select the Python version in the sandbox

[rchen152]

Describe the Bug

I wanted to test some version-specific behavior of dataclasses, and I had to open a terminal to build and run pyrefly. It would be nice if the sandbox supported a version selector like https://mypy-play.net/ or https://play.ty.dev/ (the latter lets you set up a fully custom config, which would be even nicer).

Sandbox Link

No response

(Only applicable for extension issues) IDE Information

No response

[Adist319]

I can give this a shot.

[yangdanny97]

Thanks! The entry point for the sandbox code should be https://github.com/facebook/pyrefly/blob/main/pyrefly_wasm/lib.rs and https://github.com/facebook/pyrefly/blob/main/pyrefly/lib/playground.rs, so I imagine the task would be to plumb a version number through and add a new UI element.

@dluo could you please add some instructions to the contributing guide for how to build the website? @Adist319 please reach out if you get stuck on this.

[Adist319]

I tried building the website locally using the following steps:

1. cargo install wasm-pack wasm-opt
2. yarn install
3. cd website
4. yarn start

On Windows
I first ran the commands on Windows, but encountered this error:

unset FB\_INTERNAL && INTERNAL\_STATIC\_DOCS=0 docusaurus start 'unset' is not recognized as an internal or external command, operable program or batch file. error Command failed with exit code 1.

Looks like unset isn’t supported on Windows CMD.

On WSL
I then tried running the same steps in WSL, but got a different error:

\[ERROR] Error: not found: hg at getNotFoundError (.../node\_modules/which/lib/index.js:16:17) ... code: 'ENOENT'

Looks like it’s expecting hg (Mercurial) to be installed and looks like building the website only works internally? Let me know if that’s expected, or if there’s a way to bypass this requirement when building locally. Happy to install it if needed.

[dluo]

Thanks for picking this up @Adist319! A bunch of the tools we use for the website aren't supported on Windows, so WSL would be your best bet. Could you try to install hg and see if it unblocks you?

You mention that that the website only works internally, could you share a pointer on why you think so? I just tested building the website in an external environment on mac which seem to be working ok, so I wonder if there's something else that I'm missing.

[Adist319]

Hey @dluo, installing hg (on WSL) actually unblocked me, thanks! Just wanted to confirm: is yarn start the right command for local development?

For context on why I initially assumed the website was internal-only: I saw the following text on the terminal: unset FB_INTERNAL && INTERNAL_STATIC_DOCS=0 docusaurus start, which made me think the build might require Meta-internal infrastructure. In hindsight (after a good night’s sleep 😅), I realize that was a hasty assumption.

[yangdanny97]

Our internal source control is sapling, which evolved from & is very similar to mercurial.

The FB_INTERNAL setting is so that docs meant for internal users are hidden from the public version of the site, but we should be able to build a public version without depending on it.

[Adist319]

Just wanted to share my full setup steps after doing some digging in case others run into similar issues getting the website running on WSL:

---

Local Development Setup for Pyrefly Website

1. Install WASM Tools

Install the required Rust WebAssembly tools:

cargo install wasm-pack wasm-opt

2. Install Node Dependencies

cd website
yarn install

---

Running the Development Server

WASM Mode

cd website
yarn start-with-wasm

This will:

• Compile Rust code to WebAssembly (first build takes 2–5 minutes)
• Copy the WASM files to the website
• Start the development server at http://localhost:3000
• Enable the interactive sandbox at http://localhost:3000/sandbox

---

Alternative

cd website
yarn start

This mode:

• Skips the WASM build
• Sandbox won't work, but it's fast

---

Key Points from My Experience

Why WSL Is Required

• Native Windows fails due to Unix-only tooling (unset, shell scripts)
• Windows mounts (/mnt/c/...) cause script execution issues
• WASM build requires clang, which is harder to configure on Windows

---

Common Issues and Fixes

scripts/start.sh: not found

Solution:

• Use the WSL file system (e.g., ~/pyrefly) — not /mnt/c/...

Failed to find tool. Is clang installed?

Solution:

sudo apt install clang build-essential

Error: not found: hg

Solution:

sudo apt install mercurial

Expected Output When Successful

You should see:

[INFO]: 🎯  Checking for the Wasm target...
[INFO]: 🌀  Compiling to Wasm...
[many compilation messages...]
copying wasm files from pyrefly_wasm/ to website/
finished copying wasm files
[SUCCESS] Docusaurus website is running at: http://localhost:3000/

---

[darricklaidin]

Thanks for sharing the steps that you used for your local dev environment setup; can confirm that they work for me on Linux as well.

[dluo]

I'm glad you are unblocked on this, and thank you for documenting all the steps that you took! I can see why you are confused, I'll add some comments to package.json so that it's clear why we are using some of the flags to reduce confusion. I will also add the steps for installing clang and mercurial to CONTRIBUTING.md (or if you would like to put up a PR for this, feel free to and send it to me for review) , these were steps that I missed documenting since they were tools that I had installed by default.