Repeatable builds, virtual environment

[phreed]

Currently the Jank development environment is the host environment.
Is there interest in using one of the techniques for reproducible development environments?

[phreed]

There are several techniques for reliable and repeatable builds.
They each prepare some type of environment which isolates the development environment from the host environment.
Here are some common approaches:

• Dedicated build machinery : expensive and non-portable
• Specific VirtualMachines: such as VMware, KVM, etc.
• Linux Containers: works only with linux or something like Windows WSL2 with devcontainers
• Virtual Environments: this was popularized by tools like virtualenv

[phreed]

My preferred approach is to use a virtual environment (sometimes several) for each project.

A simple form of virtual environment is update-alternatives. Which manipulates environment variables, symbolic links, and hard links.
The python virtualenv extends this approach significantly.
Using venv is the recommended approach for python developers.

The conda ecosystem has significantly expanded the virtual environment even more.
While it was originally python specific, with conda-forge it now supports many programming languages.
pixi and uv have lockfiles which force specific versions of the packages, thereby making it relatively easy to establish and maintain consistent development environments between developers.

[phreed]

Pixi creates a fairly big pixi.lock file.
In the experiment I did here are the respective file sizes:

Contribution	Lines
pixi.lock (auto-generated)	~3,671
pixi.toml	~180
15 nushell scripts	~436
CMakeLists.txt additions	~30
GitHub Actions workflows	~100
Documentation, Clojure scripts, flake.nix	~50
Approximate total	~4,467

As you can see the number of lines for all the changes was ~800 lines, not ~4K when the pixi.lock is included.

[jeaye]

Hi! Thanks for the discussion. Others are welcome to chime in, but I will give my current stance.

Developing jank itself can be done in a reproducible environment, given our flake.nix. However, for developing jank apps, as jank user, we do not have a specific reproducible environment setup. I am not currently interested in building, or maintaining, a custom solution to this. There are too many custom solutions to this.

Ultimately, jank is just a C++ project which compiles Clojure code to C++. I will expect that if users want a reproducible environment, they will use whatever works for them.

[phreed]

I had heard about Nix Flakes but I have not used it, I will take a look.

[phreed]

It looks like you already have tooling for repeatable builds with Nix.
Nix seems to take a different approach than the four I listed.
I do not yet, quite understand the approach.
Apparently, Nixpkgs exist for several of the gitmodules:

submodule	nixpkgs name	latest version
bdwgc	boehmgc	8.2.8
boost-multiprecision	boost	1.88.0
boost-preprocessor	boost	1.88.0
boost-process	boost-process	0.5
clojure-test-suite	—	—
cppinterop	—	—
cpptrace	cpptrace	0.8.3
doctest	doctest	2.4.11
folly	folly	2025.04.21.00
ftxui	ftxui	6.1.9
immer	immer	0.8.1
stduuid	stduuid	1.2.3
zip	zip	3.0

Is there a reason for the gitmodules?

[jeaye]

Most people don't use nix.

Trying to find a universal solution for this is admirable, but unrealistic. People use what they want to use. We cannot change that.

[phreed]

Having read a bit about Nix, it sounds like one reason "most people don't use nix" is because most people use MSVC on Windows. In order for Nix to cross-compile to Window MSVC there is a legal problem with using the headers and libraries.
The conda-forge people get around this by building on Windows.
(Note: I am not a fan of Windows but there sure are a lot of them.)