In reply to @connorbaker:matrix.org

How do you all handle PRs which have dependencies on other PRs?

For context, this is related to a PR I made here (https://github.com/NixOS/nixpkgs/pull/215229) which has spiraled into a grab-bag of changes.

As an example, if you have a PR A and a PR B which relies on that changes A has, how do you make that clear?

• Should B use the branch A creates instead of Nixpkgs' master?
• Should there be notes or warnings in the description of the PRs about the merge order? If so, is there a particular style you'd recommend?
• How do you test multiple PRs which depend on each other with nixpkgs-review? I had tried specifying multiple PRs as arguments, but it didn't seem like it stacked them.

The closest thing I think I've seen before is PRs against torch (example: https://github.com/pytorch/pytorch/pull/94243). They use this tool: https://github.com/ezyang/ghstack.

-import tflite_runtime.interpreter as tflite
+try:
+    from tflite_runtime.interpreter import Interpreter
+except ModuleNotFoundError:
+    from tensorflow.lite.python.interpreter import Interpreter

Example of me trying to run something I just packaged (https://github.com/connorbaker/bsrt) and maybe getting bitten by (what I think is) exactly this:

[connorbaker@fedora bsrt_temp]$ python3 -m bsrt
Traceback (most recent call last):
  File "/nix/store/0pyymzxf7n0fzpaqnvwv92ab72v3jq8d-python3-3.10.9/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/nix/store/0pyymzxf7n0fzpaqnvwv92ab72v3jq8d-python3-3.10.9/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/connorbaker/Documents/bsrt_temp/bsrt/__main__.py", line 6, in <module>
    from mfsr_utils.pipelines.synthetic_burst_generator import (
  File "/nix/store/ay2msah0yd16xjwyldqd0n6incf9gd7l-python3.10-mfsr_utils-1.7/lib/python3.10/site-packages/mfsr_utils/pipelines/synthetic_burst_generator.py", line 6, in <module>
    import cv2  # type: ignore[import]
ImportError: /nix/store/ps7an26cirhh0xy1wrlc2icvfhrd39cj-gcc-11.3.0-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /nix/store/s9jsa3p9csvnpvfhix19b3rfyg08m275-opencv-4.7.0/lib/libopencv_gapi.so.407)

OpenCV specifies the CUDA host compiler, but does not set the C or C++ compilers. I'm trying a build with a patched derivation for opencv and hoping that resolves the problem. (Also, OpenCV apparently doesn't build for specific GPU architectures or take advantage of CUDNN!)

Is there an issue with cudaPackages since the the gcc version bump to 12? I'd expect the following to work

let pkgs = import ./. { };
in pkgs.runCommandCC "test" { buildInputs = with pkgs.cudaPackages; [ cuda_nvcc cuda_cudart ]; } ''
  nvcc ${pkgs.writeText "test.cu" "int main() { return 0; }"} -o $out
''

but on master I see

error -- unsupported GNU version! gcc versions later than 11 are not supported!

(might be missing something because I'm not immediately finding workarounds that were necessary for other CUDA packages since gcc was bumped)