fix jupyterlab on darwin

[nbren12]

Motivation for this change

The jupyterlab stack was broken on mac: https://hydra.nixos.org/build/143189378

ZHF: #122042

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Added a release notes entry if the change is major or breaking
• Fits CONTRIBUTING.md.

[risicle]

Hmm... all of these packages are reported as working from 1672185 https://hydra.nixos.org/eval/1672185?filter=jupyterlab_server&compare=1672118&full=

[nbren12]

Those are all for Linux. The darwin builds are broken.

[risicle]

Sorry, the darwin ones are all still under the "Queued" tab, but I definitely had at least jupyter_server working as of #124027

Edit: just successfully built all three on master (77efb5b) on macos 10.15

[nbren12]

Are you doing sandboxed builds? I'm on Mac 10.15 too and it is failing for me even on the latest master: bd24952

Here is an portion of the error log:

successfully installed jupyter-server-1.5.0
/private/tmp/nix-build-python3.9-jupyter_server-1.5.0.drv-0/jupyter_server-1.5.0
Finished executing pipInstallPhase
post-installation fixup
strip is /nix/store/9xawf09c90761xkxv8r1b55ja46x4wr3-cctools-binutils-darwin-949.0.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/2rcq8wzjgkgfvb3zcqxfwkg7dyi8wn76-python3.9-jupyter_server-1.5.0/lib  /nix/store/2rcq8wzjgkgfvb3zcqxfwkg7dyi8wn76-python3.9-jupyter_server-1.5.0/bin
patching script interpreter paths in /nix/store/2rcq8wzjgkgfvb3zcqxfwkg7dyi8wn76-python3.9-jupyter_server-1.5.0
Rewriting #!/nix/store/dv0p8j60nqh7riq7fk9v5vf8kvbb2s90-python3-3.9.4/bin/python3.9 to #!/nix/store/dv0p8j60nqh7riq7fk9v5vf8kvbb2s90-python3-3.9.4
wrapping `/nix/store/2rcq8wzjgkgfvb3zcqxfwkg7dyi8wn76-python3.9-jupyter_server-1.5.0/bin/jupyter-server'...
Executing pythonRemoveTestsDir
Finished executing pythonRemoveTestsDir
running install tests
no Makefile or custom installCheckPhase, doing nothing
pythonCatchConflictsPhase
pythonRemoveBinBytecodePhase
pythonImportsCheckPhase
Executing pythonImportsCheckPhase
pytestCheckPhase
Executing pytestCheckPhase
============================= test session starts ==============================
platform darwin -- Python 3.9.4, pytest-6.2.3, py-1.10.0, pluggy-0.13.1
rootdir: /private/tmp/nix-build-python3.9-jupyter_server-1.5.0.drv-0/jupyter_server-1.5.0
plugins: tornasync-0.6.0.post2, anyio-0.0.0
collected 487 items / 47 deselected / 440 selected

jupyter_server/tests/test_config_manager.py .                            [  0%]
jupyter_server/tests/test_files.py EEEEEEE                               [  1%]
jupyter_server/tests/test_gateway.py EEEEEEE                             [  3%]
jupyter_server/tests/test_paths.py ..EEEE                                [  4%]
jupyter_server/tests/test_serialize.py ..                                [  5%]

[nbren12]

I tried setting sandbox=false in my nix config, and the build passed, so I bet this is the issue.

[risicle]

I am doing sandboxed builds. I wish hydra would hurry up and settle this.

[nbren12]

Would the version of nix matter? I don't really understand how these tests could pass in a darwin sandbox. They spin-up an HTTP server and then try to connect to it, a pattern which for me always fails in packages that don't use __darwinAllowLocalNetworking=true.

Maybe someone else can settle this for us if Hydra is too slow.

[risicle]

I'm seeing very strange sandbox behaviour on my darwin machine now, this suggest something could well be up with it...

[risicle]

Ok - I've got to the bottom of my issue - turns out I need to restart my nix daemon one last time at the end of my macos bringup script to get the sandbox-enabling setting to take effect. It does indeed fail now. Let me run a proper test for this now...

[risicle]

WFM macos 10.15

[nbren12]

bump @jonringer