Add patches for conda compatibility #666
Conversation
|
Is there any (sane) way to test the different "deployment types" we want to support? |
|
I can add a conda forge based CI if you want |
|
I also have an other patch to disable the hatchling script. |
|
Is it possible to unit test the required functionality? It seems like that should be sufficient? |
|
I’m not sure I can think of a test that is guaranteed to run successfully to completion on your local setups. Even to unit test the behavior. Would it be ok for me to add a CI job with a comment to delete it if/when I become inactive and unable to maintain it? |
|
Personally, I don't mind not-testing the conda-specific behaviour here. Its (I assume) already tested in the conda forge feedstock. When it fails, an update is made relatively easily. A test here (in the current repo) might catch such errors sooner, but I doubt whether the maintenance overhead is worth it, since I don't expect these paths to change very often. |
hmaarrfk
force-pushed
the
add_patches_for_conda_compatibility
branch
from
6e53552 to
74ca92e
Compare
|
Ok let me test with conda-forge CIs before I unmark this as draft. |
hmaarrfk
force-pushed
the
add_patches_for_conda_compatibility
branch
from
74ca92e to
531ae45
Compare
|
Ok i backported the patch and it seems like it both tested the new path (since I found a bug in lib vs bin on windows) so this seems good to go from my end if it is cool with all of you! |
For the conda-forge packages I package wgpu-native myself and install them in the "system" libraries. This should continue to allow you to use the "wheel" vendored headers but then also look for the headers in the "system" locations. I've been dragging on a simpler (less upstreamable) version of this patch for about a year but I'm hoping I don't have to with this addition.
Korijn
force-pushed
the
add_patches_for_conda_compatibility
branch
from
0e7e95c to
dc830f2
Compare
|
thank you! |
|
Can you explain how this works in the conda distribution? I would expect the new code to still prefer vendored headers when they're there. Does the conda package not ship the vendored headers? This question is purely out of interest. :) |
|
hmm, i didn't realize that you vendored the headers in the source package itself.... I'll have to try again.
|
|
I've packaged the headers and the library and depend on those "c-like" packages in the recipe: https://github.com/conda-forge/wgpu-py-feedstock/blob/main/recipe/meta.yaml#L36 |
|
and followup: conda-forge/wgpu-py-feedstock#29 |
For the conda-forge packages I package wgpu-native myself and install them in the "system" libraries.
This should continue to allow you to use the "wheel" vendored headers but then also look for the headers in the "system" locations.
I've been dragging on a simpler (less upstreamable) version of this patch for about a year but I'm hoping I don't have to with this addition.