New release of fury causes nightly failures

[arokem]

I think that the solution to this is along these lines: pygfx/pygfx#951, but don't have time to implement right now. Might do it tomorrow if my flight has wifi.

[arokem]

... and assuming I finish the slides for the talk that I am giving on Tuesday morning 😅

[36000]

I think that is the problem, but I think this is a dipy issue. We do install those libraries in the nightly tests that use fury directly. In these tests, we are simply doing things like importing load_tractogram and that is pulling in fury and these requirements. It should not be the case that you need to install graphics libraries to load a trk or trx file.

[36000]

For example, importing save_tractogram is what caused this:

==================================== ERRORS ====================================
___________ ERROR collecting recognition/tests/test_other_bundles.py ___________
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/AFQ/recognition/tests/test_other_bundles.py:4: in <module>
    import AFQ.recognition.other_bundles as abo
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/AFQ/recognition/other_bundles.py:9: in <module>
    import AFQ.recognition.utils as abu
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/AFQ/recognition/utils.py:10: in <module>
    from dipy.io.streamline import save_tractogram
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/dipy/io/streamline.py:15: in <module>
    from dipy.io.vtk import load_vtk_streamlines, save_vtk_streamlines
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/dipy/io/vtk.py:10: in <module>
    import fury.io
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/fury/io.py:13: in <module>
    from fury.lib import Texture, wgpu
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/fury/lib.py:135: in <module>
    wgpu_device = gfx.renderers.wgpu.get_shared().device
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/pygfx/renderers/wgpu/engine/shared.py:267: in get_shared
    Shared()
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/pygfx/renderers/wgpu/engine/shared.py:73: in __init__
    self._device = wgpu.get_default_device()
                   ^^^^^^^^^^^^^^^^^^^^^^^^^
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/wgpu/utils/device.py:200: in get_default_device
    adapter = wgpu.gpu.request_adapter_sync(**self._adapter_kwargs)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/wgpu/_classes.py:116: in request_adapter_sync
    return promise.sync_wait()
           ^^^^^^^^^^^^^^^^^^^
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/wgpu/_async.py:317: in sync_wait
    return self._resolve()  # returns result if fulfilled or raise error if rejected
           ^^^^^^^^^^^^^^^
/opt/hostedtoolcache/Python/3.11.14/x64/lib/python3.11/site-packages/wgpu/_async.py:301: in _resolve
    raise exception_in_promise  # re-raising
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
E   RuntimeError: Request adapter failed (3): Validation Error
E   
E   Caused by:
E     No suitable graphics adapter found; noop support not compiled in, vulkan drivers/libraries could not be loaded, metal support not compiled in, dx12 support not compiled in, gl drivers/libraries could not be loaded, webgpu support not compiled in

Should I post this in DIPY?

[arokem]

I don't think that this is technically a bug, so I don't think we want to report it to DIPY. I think we need to adapt our CI workflows, to use the same strategy as used in DIPY. So, use this script: https://github.com/dipy/dipy/blob/master/tools/ci/setup_headless.sh. This might be a good opportunity to reduce duplications in our CI by adopting a template that includes all of the common steps, similar to what DIPY has.

[36000]

This is definitely a bug from my perspective. It would mean pyAFQ is no longer pip installable in headless environments. Pip install-ability is a core tenant of pyAFQ. I think requiring libgl1-mesa-glx and xvfb to be able to import load_tractogram is a little too much for me. Maybe we should just switch to using nibabel to load and save tractograms, then wrap any dipy imports with an error message explaining you need to first install libgl1-mesa-glx if you want to run code like from dipy.io.streamline import save_tractogram ?

[arokem]

Yeah I think you’re right. It’s odd to require some graphics libraries just to do some io. Do you want to raise this in DIPY?

…

On Mon, Mar 9, 2026 at 10:09 PM John Kruper ***@***.***> wrote: *36000* left a comment (tractometry/pyAFQ#177) <#177 (comment)> This is definitely a bug from my perspective. It would mean pyAFQ is no longer pip installable in headless environments. Pip install-ability is a core tenant of pyAFQ. I think requiring libgl1-mesa-glx and xvfb to be able to import load_tractogram is a little too much for me. Maybe we should just switch to using nibabel to load and save tractograms, then wrap any dipy imports with an error message explaining you need to first install libgl1-mesa-glx if you want to run code like from dipy.io.streamline import save_tractogram ? — Reply to this email directly, view it on GitHub <#177 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA46NWNOBKWJ6MY5USYT7L4P52MZAVCNFSM6AAAAACWLLUQRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMRYGEYDOMZRGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[36000]

Yes, I will raise this issue in DIPY and see what people think

[36000]

dipy/dipy#3837