Any update? (again necrobump )
I’m surprised there’s not more info on this. But I guess the whole paradigm of the platform (managing and downloading frameworks all the time) is “incompatible” with NixOS?
So what’s the best way to do e.g. arduino development under NixOS? Should I be running platformio in a container and pass-through my serial device with the programmer?
(Just as a remote comparison: I already had to resort to running graphical apps (openmodelica in this case) in a container because even though it’s in nixpkgs it suffers from subtle bugs (only under NixOS) making it unusable, at least for many OMEdit use cases.)
Ok, I took a deeper look and can confirm @rychly 's analysis.
I tried a very dirty workaround by making a wrapper bash script that wraps python and pio and forwards all invocations to a podman container with platformio. This gets pretty close (in that it intercepts most (?) script calls from the vscode-extension), but it still fails before having started the server. Starting the server manually in parallel doesn’t work, possibly of mismatched port number negotiation due to unsynced startup.
Going back to the “nix-way”: basically all we would need to do is make an FHS-nix-shell that combines platformio and a python3 interpreter (this by itself is trivial), but also adds the realised/built platformiopython module to the python environment.
Could this mean we have to use buildPythonPackage on the platformio-core sources (maybe elegantly adding an extra output to the nix-package expression of platform-core?) and add it to the python env instantiation in the FHS? And while at it, make the current platformio-core build which uses buildPythonApplication to build the whole thing simply into the original thin python wrapper that then imports our new module?
Looking further: will the toolchains that platformio downloads into ~/.platformio/... work in the FHS, or can we expect difficult issues with that further down the line as well?