Skip to content

update to 2.6.0#16

Closed
das-intensity wants to merge 4 commits into
conda-forge:mainfrom
das-intensity:pytorch-2.6
Closed

update to 2.6.0#16
das-intensity wants to merge 4 commits into
conda-forge:mainfrom
das-intensity:pytorch-2.6

Conversation

@das-intensity

Copy link
Copy Markdown
Contributor

Checklist

  • Used a personal fork of the feedstock to propose changes
  • Bumped the build number (if the version is unchanged)
  • Reset the build number to 0 (if the version changed)
  • Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
  • Ensured the license file is being packaged.

@das-intensity

Copy link
Copy Markdown
Contributor Author

@conda-forge-admin, please rerender

@conda-forge-admin

conda-forge-admin commented Mar 14, 2025

Copy link
Copy Markdown
Contributor

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/recipe.yaml:

  • ℹ️ The use of xz is deprecated. If your package links to liblzma, use the new liblzma-devel package. For XZ's command line utilities (like xz and unxz), use the xz-toolspackage. For the xz-enabled GNU tools (like grep), use xz-gpl-tools. Note: Command line utilities should go in requirements/build.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13867067460. Examine the logs at this URL for more detail.

@conda-forge-admin

Copy link
Copy Markdown
Contributor

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you but ran into some issues. Please check the output logs of the GitHub Actions workflow below for more details. You can also ping conda-forge/core (using the @ notation) for further assistance or you can try rerendering locally.

The following suggestions might help debug any issues:

  • Is the recipe/{meta.yaml,recipe.yaml} file valid?
  • If there is a recipe/conda-build-config.yaml file in the feedstock make sure that it is compatible with the current global pinnnings.
  • Is the fork used for this PR on an organization or user GitHub account? Automated rerendering via the webservices admin bot only works for user GitHub accounts.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13866194380. Examine the logs at this URL for more detail.

@das-intensity

Copy link
Copy Markdown
Contributor Author

@conda-forge-admin, please rerender

It seems these `"true"` and `"false"` strings don't work as expected.

Before: Using `"true"` and `"false"` for `cuda` var:
```
 │ │ Resolving build environment:
 │ │   Platform: linux-64 [__unix=0=0, __linux=6.13.5=0, __glibc=2.34=0, __cuda=12.6=0, __archspec=1=zen2]
 │ │   Channels:
 │ │    - file:///home/conda/feedstock_root/build_artifacts/
 │ │    - conda-forge
 │ │   Specs:
 │ │    - gxx_linux-64 12.*
 │ │    - gcc_linux-64 12.*
 │ │    - sysroot_linux-64 2.17.*
 │ │    - cmake
 │ │    - ninja
 │ │    - ccache
 │ │    - git
 │ │
```

After: Using `"enabled"` and `"disabled"`for `cuda` var:
```
 │ │ Resolving build environment:
 │ │   Platform: linux-64 [__unix=0=0, __linux=6.13.5=0, __glibc=2.34=0, __cuda=12.6=0, __archspec=1=zen2]
 │ │   Channels:
 │ │    - file:///home/conda/feedstock_root/build_artifacts/
 │ │    - conda-forge
 │ │   Specs:
 │ │    - gxx_linux-64 12.*
 │ │    - gcc_linux-64 12.*
 │ │    - sysroot_linux-64 2.17.*
 │ │    - cmake
 │ │    - ninja
 │ │    - ccache
 │ │    - git
 │ │    - cuda-nvcc_linux-64 12.6.*
 │ │    - cuda-version ==12.6
 │ │
```
@das-intensity

Copy link
Copy Markdown
Contributor Author

@conda-forge-admin, please rerender

@h-vetinari

Copy link
Copy Markdown
Member

We should do #15 first, which is blocked on conda-forge/llvmlite-feedstock#100

@das-intensity

Copy link
Copy Markdown
Contributor Author

@h-vetinari feel free to pull 58143cb into your renderer PR as I suspect it may be related to the rattler change.

Since you removed the if: cuda == "true" checks, I'm not sure whether it'll affect the other cuda var checks though, so may not be required. However it's probably still safer to switch away from "true" as this is a pretty nasty bug. Perhaps we could switch the remaining 2 use-cases of cuda var to instead use cuda_compiler_version and remove it entirely?

On that vein: I was working on putting up similar fixes like conda-forge/xformers-feedstock#46 for other repos which had the if: cuda == "true"checks. Do you think they should each be instead more like #15 ?

@h-vetinari h-vetinari mentioned this pull request Mar 25, 2025
@h-vetinari

Copy link
Copy Markdown
Member

Hey @das-intensity, sorry for the delays here, there were other blockers for #15 that took a long time. Seeing that this apparently your very first PR in conda-forge (🥳), I didn't want to force-push here, but I've rebased this PR in #17. You can either merge main here yourself, rebase yourself, or I can force-push for you (or we merge #17).

On that vein: I was working on putting up similar fixes like conda-forge/xformers-feedstock#46 for other repos which had the if: cuda == "true"checks.

I haven't had time to dig into this issue yet. If rattler does not treat the strings "true" and "false" as expected, then that's an issue we should raise.

@das-intensity

Copy link
Copy Markdown
Contributor Author

@h-vetinari haha thanks but just merge #17, I'll have plenty more PRs to CF.

Speaking of which, the last outstanding pt2.6 blocker after torchaudio for me is conda-forge/pytorch_scatter-feedstock#70 so if you can quickly stamp that it'd really help me.

However it's probably still safer to switch away from "true" as this is a pretty nasty bug.

Yeah, my best guess is rattler or someone there went to the javascript school of equality ;) either way works.

Perhaps we could switch the remaining 2 use-cases of cuda var to instead use cuda_compiler_version and remove it entirely?

Yeah that's probably a clean way out, less sources of truth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants