-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deps cleanup #162
deps cleanup #162
Conversation
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 ( |
@conda-forge-admin, please rerender. |
…nda-forge-pinning 2023.02.02.19.14.40
How did you get around the issues with OSX SDK? |
I think in the other PR we were sometimes flying somewhat blindly with not rerendering correctly, but also just to be safe I bumped the SDK to the highest. The GitHub team made Xcode 14.2 the default actions/runner-images#6746 which in their docs correspond to SDK 13.1 https://github.com/actions/runner-images/blob/main/images/macos/macos-12-Readme.md#installed-sdks, but I really don't understand why we cannot find the other available SDKs. One reason is the method we use to detect them: It goes through Xcode thus perhaps limiting us to what is associated with the default Xcode https://github.com/conda-forge/conda-forge-ci-setup-feedstock/blob/80f0566fcd3c58ad33331c9d0f0084276c158f30/recipe/run_conda_forge_build_setup_osx#L32. So anyway, to be safest, I thought we could just target the latest SDK. Fwiw, I think PyTorch no longer passes for anything before 12.3 anyway. I am not sure if there are any real downsides with setting the SDKs higher (not the deployment target) and I don't know why we have it really low by default. Here's the relevant snippet: https://github.com/conda-forge/conda-forge-ci-setup-feedstock/blob/bf1f98d6694b63e9487fbc9817d2bf2d9523b73a/recipe/download_osx_sdk.sh#L7 |
As always: compatibility for old systems, though of course part of it is also inertia in changing something at all. With |
While you are using the newer SDK, you are still targetting the older deployment targets unless you specify one more variable. https://conda-forge.org/docs/maintainer/knowledge_base.html#requiring-newer-macos-sdks |
Yeah, I understand the difference between the deployment target and the SDK. I am just not sure why we set the SDK so low if we can set it higher with no downsides. If I remember, I think isuruf said that it’s not guaranteed that it would work across the board, so we are just being safe in setting it lower. I saw the SDK fix. I would recommend to keep the pytorch feedstock at the highest SDK we could, because they’ve been adding all sorts of newer functionalities for MPS that might have appeared in later releases. But I personally don’t care as much at the moment. So I am happy to revert this PR. (A discussion for another day: The larger issue around MacOS support is that Apple is quite unfriendly to those who don’t update/upgrade. On Linux, it makes sense we go out of our way to support older systems (believe me, I am on some “newer” HPC systems that have git 1.8.x and python 2.7 as defaults). There are these random stats that latest iOS/macOS adoption/upgrade rate is more than 90%. The bottom line, we could potentially make our lives easier by going with the newer stuff. But if it is not broken, why bother?! And it definitely isn’t broken 😄) |
There are downsides. Most build systems don't understand the difference between the two (SDK version vs deployment target). |
@@ -100,12 +102,7 @@ outputs: | |||
- {{ pin_compatible('magma', max_pin='x.x.x') }} # [cuda_compiler_version != "None"] | |||
# other requirements | |||
- python | |||
- {{ pin_compatible('numpy') }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we cannot remove numpy from the build time dependneices, this should be moved to a run_constraint
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I misunderstood. Do you want us to remove them as build dependency or just run dependencies? I thought run dependencies only...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Their package doesn't seem to depend on at runtime
Their recipe seems to look like:
{% set build_variant = environ.get('PYTORCH_BUILD_VARIANT', 'cuda') %}
{% set cross_compile_arm64 = environ.get('CROSS_COMPILE_ARM64', 0) %}
package:
name: pytorch
version: "{{ environ.get('PYTORCH_BUILD_VERSION') }}"
source:
path: "{{ environ.get('PYTORCH_GITHUB_ROOT_DIR') }}"
requirements:
build:
- cmake
- {{ compiler('c') }} # [win]
- pkg-config # [unix]
- libuv # [unix]
host:
- python
- setuptools
- pyyaml
{% if cross_compile_arm64 == 0 %}
- mkl-include # [x86_64]
- mkl=2020.2 # [x86_64 and (not win or py <= 39)]
- mkl=2021.4 # [x86_64 and win and py >= 310]
{% endif %}
- typing_extensions
- ninja
- libuv # [win]
- numpy=1.19 # [py <= 39]
- numpy=1.21.5 # [py >= 310]
- openssl=1.1.1l # [py >= 310 and linux]
{{ environ.get('PYTORCH_LLVM_PACKAGE', ' - llvmdev=9') }}
{{ environ.get('MAGMA_PACKAGE', '') }}
run:
- python
{% if cross_compile_arm64 == 0 %}
- mkl >=2018 # [x86_64]
{% endif %}
- libuv # [win]
- intel-openmp # [win]
- typing_extensions
{% if cross_compile_arm64 == 0 %}
- blas * mkl
{% endif %}
- pytorch-mutex 1.0 {{ build_variant }} # [not osx ]
{{ environ.get('CONDA_CUDATOOLKIT_CONSTRAINT', '') }}
{% if build_variant == 'cpu' %}
run_constrained:
- cpuonly
{% elif not osx %}
run_constrained:
- cpuonly <0
{% endif %}
build:
number: {{ environ.get('PYTORCH_BUILD_NUMBER', '1') }}
detect_binary_files_with_prefix: False
string: "{{ environ.get('PYTORCH_BUILD_STRING') }}"
script_env:
- BUILD_SPLIT_CUDA
- CUDA_VERSION
- CUDNN_VERSION
- CONDA_CUDATOOLKIT_CONSTRAINT
- USE_CUDA
- CMAKE_ARGS
- EXTRA_CAFFE2_CMAKE_FLAGS
- DEVELOPER_DIR
- DEBUG
- USE_FBGEMM
- USE_GLOO_WITH_OPENSSL # [unix]
- USE_SCCACHE # [win]
- USE_DISTRIBUTED # [unix]
- CMAKE_OSX_ARCHITECTURES # [unix]
- USE_MKLDNN # [unix]
- USE_NNPACK # [unix]
- USE_QNNPACK # [unix]
- BUILD_TEST # [unix]
- USE_PYTORCH_METAL_EXPORT # [osx]
- USE_COREML_DELEGATE # [osx]
- _GLIBCXX_USE_CXX11_ABI # [unix]
test:
imports:
- torch
about:
home: http://pytorch.org/
license: BSD 3-Clause
license_family: BSD
license_file: LICENSE
summary: PyTorch is an optimized tensor library for deep learning using GPUs and CPUs.
Which means that numpy is required at build time, but not runtime. Therefore, we should move the line you added to the run_constraint
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems we can just remove numpy from the run section. Which one?
- add numpy as run_constraint
- add llvm-openmp as run_constraint instead of run
- both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not an expert with llvm. I can't comment on that.
upstream they use Xcode 13.3.1 which corresponds to SDK 12.3 Will revert to that. |
…nda-forge-pinning 2023.02.04.12.26.59
PR upcoming in other feedstock to fix latest issue... conda-forge/conda-forge-ci-setup-feedstock#230 |
No problem... btw, I confirmed that for both cases, the actual folders do have the .sdk suffix, so what you did was arguably more coherent 😺 |
Looks good to me; @hmaarrfk what do you think? Paging @Tobias-Fischer as well |
(btw, I wouldn't bother uploading cuda builds...) |
Awesome, thanks for that! Seems like you got the osx-* build all to pass which is great :) |
- mkl-devel {{ mkl }} # [x86] | ||
- libcblas * *_mkl # [x86] | ||
- libcblas # [not x86] | ||
- liblapack # [not x86] | ||
- openblas # [not x86] | ||
- libgomp # [linux] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i was only going to ask about this line with respect to the CUDA builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this to be consistent with the osx additions. However, I highly doubt it is worth the hassle of building locally and uploading. We never faced any issues with the cuda builds. So yes, imo we could skip building cuda this time around; if there are any problems, we will address them in the next release, and perhaps make a more informed decision about adding/removing this. But ultimately you will have to make a decision on this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok lets skip the builds this time, and maybe upload them over time later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ninja was already removed as a dependency so i htink the main issue is resolved via a repo-data patch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. I would offer to build them myself, but I just moved jobs (with plenty of access to HPCs) and I need time to navigate the policies 😶🌫️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Congrats on the move!
Can confirm this PR fixed conda-forge/norse-feedstock#11 |
great! |
Fix #160
Fix #161
Close #159
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)