Change:
hash = "sha256-gplrkrFTIP6TLvk1YazD5roDzsPvDtOXLlTOmTio52s="; }; <ins> patches = [ # Drop when next release is out (fetchpatch { name = "drop-support-for-python-37.patch"; url = "https://github.com/saulpw/visidata/commit/738bb8b43814c14b1b8a1f1f60397c1520c5ef4a.patch"; hash = "sha256-5jDAzKMuW3s7BCGpWyLcS4Lw8GUbjNxVhF5mUKbR1YY="; }) (fetchpatch { name = "update-tests-for-python-312.patch"; url = "https://github.com/saulpw/visidata/commit/627f6f126cdd49bcdda0bbc16fab42eb5bd42103.patch"; hash = "sha256-3FHgjLrzMHObEheJoRY8VlnDUtDZ68FqCqAyhP7333E="; }) ]; </ins> propagatedBuildInputs = [ # from visidata/requirements.txt # packages not (yet) present in nixpkgs are commented

Discussion:
Steps to reproduce the behavior: as my Nix starter template for macOS - uses home-manager and nix-darwin. , which causes some kind of build failure with visidata. (Previously visitdata seemed to be working correctly - however, I recently ran a - and it seems to have been broken for the last week or so). I've uploaded the build logs () as a gist here: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. I get this error when I try to run this command: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Looking at the build log, that is a failing test from visidata itself, where something is wrong with the number having a different value vs So that should hopefully be fixed upstream
Forwarded the issue upstream:
Well, that's what it looked like at first to my naive eyes (a failing test). However, it didn't make sense because it's Visidata 3.0.2 - which was released back in January 2024. Also, if I look at the Nix visidata package - there's been no changes in 6 months. And I could have sworn visidata was working for me last week or so, before I ran since then...although maybe I'm mistaken...
Could be a floating point number issue. I spoke too soon, seems like it also affects x86_64-linux on Hydra:
Hi Do you, by any chance have set to anything?
Thinking about it, in nixpkgs has switched from to last month. I managed to reproduce the issue locally as well, confirming that something changed between those versions of Python. This failure seems to be happening only with Python 3.12.4. The test suite passes fine with Python 3.11.9 however. The failing tests are: describe-error describe edit-type All failing the same way with the number rounding. The tests are executed in a sandboxed environment with Nix, so user config should not affect those.
That gives me the info to address this!
This is fixed upstream.
Thanks and =).

Quick question for a Nix newbie - if I'm currently using nixpkgs-unstable (default on the I'm using) - but Visidata hasn't cut a new release yet with this fix just yet - and nixpkgs is using 3.0.2 () - is there an easy way to have it build from the visidata develop branch instead? Or is it just a case of waiting for the next visidata release, and then also for the nixpkgs to get updated?
We'll try to update the package here asap, which shouldn't take too long since a new release is currently "in the works" on upstream's side. In the meantime, since the compatibility issue only seems to be within the tests, you can keep using the current stable version, simply skipping the test phase with something like: . You can also override the attribute the same way as above to override the source to use the develop branch if desired.