Update install script and building from source docs

[keyprocedure]

Summary

• Updated install_requirements.sh to improve compatibility with source-built PyTorch and Intel macOS systems.
• Added checks to prevent install commands from altering existing PyTorch builds by adding the --no-deps flag.
• Removed torchaudio and torchvision dependencies for Intel macOS systems to avoid compatibility issues.

Fixes #9772

Test plan

Tested executorch installations with source-built PyTorch on:

• Intel-macOS with PyTorch 2.7.0, Python 3.12.9
• ARM64 macOS with PyTorch 2.8.0a0, Python 3.12.9

Validated by exporting and running the MobileNet V2 image classification model, following the examples on the Getting Started with ExecuTorch page.

cc @larryliu0820 @jathu

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/10652

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 5 New Failures

As of commit 9158045 with merge base 936ac2b ():

NEW FAILURES - The following jobs have failed:

• pull / test-models-linux (llama3_2_vision_encoder, portable, linux.4xlarge.memory) / linux-job (gh)
  RuntimeError: Command docker exec -t dcc3bcd8f575247725b8e09287b04bd25c199bb76cb2ba6900c6124d6c1d1bf5 /exec failed with exit code 1
• pull / unittest / linux / linux-job (gh)
  examples/models/llama/tests/test_export_llama_lib.py::ExportLlamaLibTest::test_has_expected_ops_and_op_counts
• pull / unittest / macos / macos-job (gh)
  examples/models/llama/tests/test_ring_attention.py::TestRingAttention::test_sliding_window_attention_custom
• pull / unittest-editable / linux / linux-job (gh)
  examples/models/llama/tests/test_export_llama_lib.py::ExportLlamaLibTest::test_has_expected_ops_and_op_counts
• pull / unittest-editable / macos / macos-job (gh)
  examples/models/llama/tests/test_ring_attention.py::TestRingAttention::test_sliding_window_attention_custom

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[keyprocedure]

@pytorchbot label "module: build/install"

[keyprocedure]

@pytorchbot label "release notes: build"

[mergennachin]

Thank you @keyprocedure

Overall looks great. Thank you for testing end-to-end. Glad that it works.

Please see inline comments below.

[mergennachin]

https://pytorch.org/executorch/0.6/ -> change this to https://pytorch.org/executorch/main/

[mergennachin]

The print message should appear inside this block.

  if use_pytorch_nightly and is_intel_mac:

is_intel_mac_os() is just a getter function that should do any printing.

[mergennachin]

what about this logic?

f"torchaudio==2.6.0.{NIGHTLY_VERSION}" if use_pytorch_nightly else "torchaudio"

[keyprocedure]

I had removed it for testing and forgot to restore it. Updated the code :)

[keyprocedure]

Hi @mergennachin, I’ve made the requested changes — could you please take a look when you get a chance?

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[mergennachin]

Thanks @keyprocedure

I just started the full CI tests

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[keyprocedure]

@mergennachin
It looks like CI is failing because the --no-deps flag prevents the required modules from being installed. I used it to avoid torch from being upgraded, but that's leading to missing modules

Is the expectation that any torch version should be usable, or only ones compatible with the current dependencies?

If any torch version should be usable, would it make more sense to use a temporary constraints.txt file to pin the torch version instead of the --no-deps flag? That may still lead to breakages, but those conflicts would be clearer during the install process. Otherwise, we could keep the --no-deps flag for Intel-macOS installs only

[mergennachin]

@keyprocedure - First of all, thanks for being patient with this PR.

Looking a bit more into it. Why do we need --no-deps in the first place?

Presumably, when you install torch from source manually as first step, it should install a newer version from source. And in the install_requirements.py step, perhaps it won't try to upgrade it. Do you know which package is transitively trying to upgrade it?

[keyprocedure]

@mergennachin Sorry for the delay

It looks like the torch version is actually downgraded to fit the dependency requirements. I'm not sure which package is causing the version change, but I recently tried to install executorch with the latest torch build without the no-deps flag and after running ./install_executorch.sh --use-pt-pinned-commit, torch gets downgraded to 2.7.0:

Installing collected packages: zstd, sentencepiece, pytz, antlr4-python3-runtime, xxhash, tzdata, tqdm, tomli, safetensors, regex, python-dateutil, pycryptodomex, pyarrow, propcache, pillow, omegaconf, multidict, lxml, hf-xet, hf-transfer, fsspec, frozenlist, dill, cmake, aiohappyeyeballs, yarl, `torch`, tiktoken, pandas, multiprocess, kagglehub, huggingface_hub, blobfile, aiosignal, torchvision, torchdata, torchaudio, tokenizers, aiohttp, transformers, torchsr, timm, datasets, torchtune
Attempting uninstall: torch
Found existing installation: torch 2.8.0a0+git9a8c42f
Uninstalling torch-2.8.0a0+git9a8c42f:
Successfully uninstalled torch-2.8.0a0+git9a8c42f