Home / journal / 2026-06-29

Daily Journal: 2026-06-29

Wins

Today we've finally commited the work started on the last session with descriptive summary of the work done in the BiteTrack repository, and here.

I encountered an additional source of friction, and my main gap for learning which is planning paralysis. So I've introduced some additional changes to the [[AGENTS.md]] (https://github.com/kiskaadee/backend-residency/commit/5a3b1813b21d58923ce3390d3abbe6f7d5a4c321) that will hopefully help me avoiding falling into confuse-planning-with-productivity traps.

Following the new proposed guidelines, the challenge for today was the following:

Verifying the existing codebase in bitetrack-api and implementing a basic health-check endpoint.

  1. Run Services: Launch the PostgreSQL container via docker-compose.yml.
  2. Add Health Endpoint: write a simple /health GET endpoint in main.py to check application liveliness.
  3. Execute & Test: Run the FastAPI dev server locally and verify both the health endpoint and the /docs auto-generated documentation via curl .
  4. Update Docs: Check off the acceptance tests in todo.md.

When I started working on this implemenatation, I found the first Milestone 0 blocker:

The virtual environment configured via UV was installed succesfully, but some packages could not be executed under NixOS because of dynamically linked binaries

This is actually related to the previous research in [[environments]] and [[devShell]].

Standard Linux distributions follow the Filesystem Hiearchy Standard (FHS) , placing dynamic linkers and shared libraries into expected paths. The pre-compiled binaries are compiled with the hardcoded paths to these expected linkers.

NixOS will immediately fail to run them was such dynamic linkers do not exist in the requested paths.

This usually has two solutions on NixOS; the first, using a System-level shim relying on nix-ld. This feature requires modifying the system level persisting configuration in my NixOS desktop. This would have not been bad, but assuming that another developer aims to work from a Nix-like environment as well, they would have also needed to make the fix before in order to reproduce the environment.

That's why I opted for the second alternative, creating a declarative devShell through a flake.nix file. A devShell is essentially a package definition that defines the packages, env variables and compiler tools needed for the entire project (not only the Python packages). It's created at the project level (rather than the OS configuration), and uses the pkgs.mkShell helper function to define and isolate the development environment.

I followed guidance mainly from this article: How to use uv on NixOS

I was able to configure a minimal flake.nix file, which is pending for commit, and included the hook to direnv:

nix develop

This is meant to automatically load the devShell environment as soon as I enter the project directory, however, we're encountering the following error:

shell bitetrack-api on  main [!+?] is 📦 v0.1.0 via 🐍 v3.13.13 on ☁️ fcortesbio@gmail.com ➜ direnv allow direnv: loading ~/Projects/bitetrack-api/.envrc direnv: using flake direnv: nix-direnv: cache invalidated: files newer than cache: nix-direnv: /home/kiskaadee/Projects/bitetrack-api/.envrc direnv: nix-direnv: Renewed cache /nix/store/9ypz3flqsrl5xl495mm8h645gadjsxi1-coreutils-9.11/bin/rm: /nix/store/7nbi22pcc92y2fqbkyp7h3srvvklmckb-glibc-2.40-224/lib/libc.so.6: version `GLIBC_2.42' not found (required by /nix/store/9ypz3flqsrl5xl495mm8h645gadjsxi1-coreutils-9.11/bin/rm) direnv: export +AR +AS +CC +CONFIG_SHELL +CXX +HOST_PATH +IN_NIX_SHELL +LD +LD_LIBRARY_PATH +NIX_BINTOOLS +NIX_BINTOOLS_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_BUILD_CORES +NIX_CC +NIX_CC_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_CFLAGS_COMPILE +NIX_ENFORCE_NO_NATIVE +NIX_HARDENING_ENABLE +NIX_LDFLAGS +NIX_STORE +NM +OBJCOPY +OBJDUMP +POSTGRES_DB +POSTGRES_PASSWORD +POSTGRES_USER +RANLIB +READELF +SIZE +SOURCE_DATE_EPOCH +STRINGS +STRIP +VIRTUAL_ENV +VIRTUAL_ENV_PROMPT +__structuredAttrs +buildInputs +buildPhase +builder +cmakeFlags +configureFlags +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +dontAddDisableDepTrack +mesonFlags +name +nativeBuildInputs +out +outputs +patches +phases +preferLocalBuild +propagatedBuildInputs +propagatedNativeBuildInputs +shell +shellHook +stdenv +strictDeps +system ~PATH ~XDG_DATA_DIRS /etc/profiles/per-user/kiskaadee/bin/starship: symbol lookup error: /nix/store/7nbi22pcc92y2fqbkyp7h3srvvklmckb-glibc-2.40-224/lib/libc.so.6: undefined symbol: __nptl_change_stack_perm, version GLIBC_PRIVATE /etc/profiles/per-user/kiskaadee/bin/starship: symbol lookup error: /nix/store/7nbi22pcc92y2fqbkyp7h3srvvklmckb-glibc-2.40-224/lib/libc.so.6: undefined symbol: __nptl_change_stack_perm, version GLIBC_PRIVATE

I noticed the error is mentioning a starship: symbol lookup error, which was surprising since starship is part of my shell, not the project. I suspect that, as soon as I enter, direnv is replacing some important PATH definition that is shared by starship and some of the installed dependencies. My current hypothesis is that entering the devShell modifies the dynamic library resolution for subsequently executed binaries, causing unrelated executables such as Starship to resolve incompatible libraries.

That's certainly something we should investigate further as I require more evidence and careful debugging. The session for now is ending. I will return tomorrow to continue working on setting up the flake, and solving the direnv-starship-glibc issue.