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.

❌ 1 New Failure

As of commit df9c97a with merge base 7b39a0c ():

NEW FAILURE - The following job has failed:

• pull / test-moshi-linux / linux-job (gh)
  test_exported_decoder_xnnpack

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

[keyprocedure]

If the downgrade is being caused by something that I'm doing incorrectly during the install process/isolated to my build, I can remove the no-deps flag from the pip install command for this PR. I'm open to any suggestions/guidance.

[mergennachin]

Hi @keyprocedure

I did some digging and found out that torchvision and torchaudio were in fact downgrading.

torch, torchvision and torchaudio are in lock step dependency.

I did some refactoring in (#11653). torchvision and torchaudio are not absolute necessity. Only used for examples.

Once that PR is landed, we can update the Intel instruction to be as follows:

Build torch from source
./install_executorch.sh --use-pt-pinned-commit --minimal

[keyprocedure]

Hey @mergennachin, I really appreciate your follow up!

Perfect, that'll simplify things.
I'll update the Intel instructions in this PR once #11653 lands.

[mergennachin]

Hi @keyprocedure

I just landed the PR, please rebase. Hopefully it will simplify a lot of things in this PR

[keyprocedure]

@mergennachin I've rebased and updated the Intel macOS install instructions to ./install_executorch.sh --use-pt-pinned-commit --minimal. Feel free to let me know if there's anything else that needs to be changed.

[mergennachin]

See inline

[mergennachin]

Use relative paths

[keyprocedure]

I updated the flag links to use relative paths to the .py file.
For the PyTorch instructions link, since it points to a doc in the PyTorch repo, is there a way to reference that using a relative path, or should we keep the current path?

[mergennachin]

Let's not have two instructions. Let's consolidate Intel based instructions in "building from source section" and call it a day

[keyprocedure]

Good point, moved the instructions.

[mergennachin]

s/Executorch/ExecuTorch/g

[keyprocedure]

I removed the mention of building Torchvision and Torchaudio from source in the building-from-source doc for Intel-macOS builds to simplify the instructions, since they're not required to install ExecuTorch.

[mergennachin]

Thank you @keyprocedure

[keyprocedure]

Happy to help!

[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.

❌ 1 New Failure

As of commit df9c97a with merge base 7b39a0c ():

NEW FAILURE - The following job has failed:

• pull / test-moshi-linux / linux-job (gh)
  test_exported_decoder_xnnpack

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

[keyprocedure]

If the downgrade is being caused by something that I'm doing incorrectly during the install process/isolated to my build, I can remove the no-deps flag from the pip install command for this PR. I'm open to any suggestions/guidance.

[mergennachin]

Hi @keyprocedure

I did some digging and found out that torchvision and torchaudio were in fact downgrading.

torch, torchvision and torchaudio are in lock step dependency.

I did some refactoring in (#11653). torchvision and torchaudio are not absolute necessity. Only used for examples.

Once that PR is landed, we can update the Intel instruction to be as follows:

Build torch from source
./install_executorch.sh --use-pt-pinned-commit --minimal

[keyprocedure]

Hey @mergennachin, I really appreciate your follow up!

Perfect, that'll simplify things.
I'll update the Intel instructions in this PR once #11653 lands.

[mergennachin]

Hi @keyprocedure

I just landed the PR, please rebase. Hopefully it will simplify a lot of things in this PR

[keyprocedure]

@mergennachin I've rebased and updated the Intel macOS install instructions to ./install_executorch.sh --use-pt-pinned-commit --minimal. Feel free to let me know if there's anything else that needs to be changed.

[mergennachin]

See inline

[mergennachin]

Use relative paths

[keyprocedure]

I updated the flag links to use relative paths to the .py file.
For the PyTorch instructions link, since it points to a doc in the PyTorch repo, is there a way to reference that using a relative path, or should we keep the current path?

[mergennachin]

Let's not have two instructions. Let's consolidate Intel based instructions in "building from source section" and call it a day

[keyprocedure]

Good point, moved the instructions.

[mergennachin]

s/Executorch/ExecuTorch/g

[keyprocedure]

I removed the mention of building Torchvision and Torchaudio from source in the building-from-source doc for Intel-macOS builds to simplify the instructions, since they're not required to install ExecuTorch.

[mergennachin]

Thank you @keyprocedure

[keyprocedure]

Happy to help!

[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.

❌ 1 New Failure

As of commit df9c97a with merge base 7b39a0c ():

NEW FAILURE - The following job has failed:

• pull / test-moshi-linux / linux-job (gh)
  test_exported_decoder_xnnpack

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

[keyprocedure]

If the downgrade is being caused by something that I'm doing incorrectly during the install process/isolated to my build, I can remove the no-deps flag from the pip install command for this PR. I'm open to any suggestions/guidance.

[mergennachin]

Hi @keyprocedure

I did some digging and found out that torchvision and torchaudio were in fact downgrading.

torch, torchvision and torchaudio are in lock step dependency.

I did some refactoring in (#11653). torchvision and torchaudio are not absolute necessity. Only used for examples.

Once that PR is landed, we can update the Intel instruction to be as follows:

Build torch from source
./install_executorch.sh --use-pt-pinned-commit --minimal

[keyprocedure]

Hey @mergennachin, I really appreciate your follow up!

Perfect, that'll simplify things.
I'll update the Intel instructions in this PR once #11653 lands.

[mergennachin]

Hi @keyprocedure

I just landed the PR, please rebase. Hopefully it will simplify a lot of things in this PR

[keyprocedure]

@mergennachin I've rebased and updated the Intel macOS install instructions to ./install_executorch.sh --use-pt-pinned-commit --minimal. Feel free to let me know if there's anything else that needs to be changed.

[mergennachin]

See inline

[mergennachin]

Use relative paths

[keyprocedure]

I updated the flag links to use relative paths to the .py file.
For the PyTorch instructions link, since it points to a doc in the PyTorch repo, is there a way to reference that using a relative path, or should we keep the current path?

[mergennachin]

Let's not have two instructions. Let's consolidate Intel based instructions in "building from source section" and call it a day

[keyprocedure]

Good point, moved the instructions.

[mergennachin]

s/Executorch/ExecuTorch/g

[keyprocedure]

I removed the mention of building Torchvision and Torchaudio from source in the building-from-source doc for Intel-macOS builds to simplify the instructions, since they're not required to install ExecuTorch.

[mergennachin]

Thank you @keyprocedure

[keyprocedure]

Happy to help!

[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.

❌ 1 New Failure

As of commit df9c97a with merge base 7b39a0c ():

NEW FAILURE - The following job has failed:

• pull / test-moshi-linux / linux-job (gh)
  test_exported_decoder_xnnpack

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

[keyprocedure]

If the downgrade is being caused by something that I'm doing incorrectly during the install process/isolated to my build, I can remove the no-deps flag from the pip install command for this PR. I'm open to any suggestions/guidance.

[mergennachin]

Hi @keyprocedure

I did some digging and found out that torchvision and torchaudio were in fact downgrading.

torch, torchvision and torchaudio are in lock step dependency.

I did some refactoring in (#11653). torchvision and torchaudio are not absolute necessity. Only used for examples.

Once that PR is landed, we can update the Intel instruction to be as follows:

Build torch from source
./install_executorch.sh --use-pt-pinned-commit --minimal

[keyprocedure]

Hey @mergennachin, I really appreciate your follow up!

Perfect, that'll simplify things.
I'll update the Intel instructions in this PR once #11653 lands.

[mergennachin]

Hi @keyprocedure

I just landed the PR, please rebase. Hopefully it will simplify a lot of things in this PR

[keyprocedure]

@mergennachin I've rebased and updated the Intel macOS install instructions to ./install_executorch.sh --use-pt-pinned-commit --minimal. Feel free to let me know if there's anything else that needs to be changed.

[mergennachin]

See inline

[mergennachin]

Use relative paths

[keyprocedure]

I updated the flag links to use relative paths to the .py file.
For the PyTorch instructions link, since it points to a doc in the PyTorch repo, is there a way to reference that using a relative path, or should we keep the current path?

[mergennachin]

Let's not have two instructions. Let's consolidate Intel based instructions in "building from source section" and call it a day

[keyprocedure]

Good point, moved the instructions.

[mergennachin]

s/Executorch/ExecuTorch/g

[keyprocedure]

I removed the mention of building Torchvision and Torchaudio from source in the building-from-source doc for Intel-macOS builds to simplify the instructions, since they're not required to install ExecuTorch.

[mergennachin]

Thank you @keyprocedure

[keyprocedure]

Happy to help!

[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.

❌ 1 New Failure

As of commit df9c97a with merge base 7b39a0c ():

NEW FAILURE - The following job has failed:

• pull / test-moshi-linux / linux-job (gh)
  test_exported_decoder_xnnpack

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

[keyprocedure]

If the downgrade is being caused by something that I'm doing incorrectly during the install process/isolated to my build, I can remove the no-deps flag from the pip install command for this PR. I'm open to any suggestions/guidance.

[mergennachin]

Hi @keyprocedure

I did some digging and found out that torchvision and torchaudio were in fact downgrading.

torch, torchvision and torchaudio are in lock step dependency.

I did some refactoring in (#11653). torchvision and torchaudio are not absolute necessity. Only used for examples.

Once that PR is landed, we can update the Intel instruction to be as follows:

Build torch from source
./install_executorch.sh --use-pt-pinned-commit --minimal

[keyprocedure]

Hey @mergennachin, I really appreciate your follow up!

Perfect, that'll simplify things.
I'll update the Intel instructions in this PR once #11653 lands.

[mergennachin]

Hi @keyprocedure

I just landed the PR, please rebase. Hopefully it will simplify a lot of things in this PR

[keyprocedure]

@mergennachin I've rebased and updated the Intel macOS install instructions to ./install_executorch.sh --use-pt-pinned-commit --minimal. Feel free to let me know if there's anything else that needs to be changed.

[mergennachin]

See inline

[mergennachin]

Use relative paths

[keyprocedure]

I updated the flag links to use relative paths to the .py file.
For the PyTorch instructions link, since it points to a doc in the PyTorch repo, is there a way to reference that using a relative path, or should we keep the current path?

[mergennachin]

Let's not have two instructions. Let's consolidate Intel based instructions in "building from source section" and call it a day

[keyprocedure]

Good point, moved the instructions.

[mergennachin]

s/Executorch/ExecuTorch/g

[keyprocedure]

I removed the mention of building Torchvision and Torchaudio from source in the building-from-source doc for Intel-macOS builds to simplify the instructions, since they're not required to install ExecuTorch.

[mergennachin]

Thank you @keyprocedure

[keyprocedure]

Happy to help!

[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.

❌ 1 New Failure

As of commit df9c97a with merge base 7b39a0c ():

NEW FAILURE - The following job has failed:

• pull / test-moshi-linux / linux-job (gh)
  test_exported_decoder_xnnpack

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

[keyprocedure]

If the downgrade is being caused by something that I'm doing incorrectly during the install process/isolated to my build, I can remove the no-deps flag from the pip install command for this PR. I'm open to any suggestions/guidance.

[mergennachin]

Hi @keyprocedure

I did some digging and found out that torchvision and torchaudio were in fact downgrading.

torch, torchvision and torchaudio are in lock step dependency.

I did some refactoring in (#11653). torchvision and torchaudio are not absolute necessity. Only used for examples.

Once that PR is landed, we can update the Intel instruction to be as follows:

Build torch from source
./install_executorch.sh --use-pt-pinned-commit --minimal

[keyprocedure]

Hey @mergennachin, I really appreciate your follow up!

Perfect, that'll simplify things.
I'll update the Intel instructions in this PR once #11653 lands.

[mergennachin]

Hi @keyprocedure

I just landed the PR, please rebase. Hopefully it will simplify a lot of things in this PR

[keyprocedure]

@mergennachin I've rebased and updated the Intel macOS install instructions to ./install_executorch.sh --use-pt-pinned-commit --minimal. Feel free to let me know if there's anything else that needs to be changed.

[mergennachin]

See inline

[mergennachin]

Use relative paths

[keyprocedure]

I updated the flag links to use relative paths to the .py file.
For the PyTorch instructions link, since it points to a doc in the PyTorch repo, is there a way to reference that using a relative path, or should we keep the current path?

[mergennachin]

Let's not have two instructions. Let's consolidate Intel based instructions in "building from source section" and call it a day

[keyprocedure]

Good point, moved the instructions.

[mergennachin]

s/Executorch/ExecuTorch/g

[keyprocedure]

I removed the mention of building Torchvision and Torchaudio from source in the building-from-source doc for Intel-macOS builds to simplify the instructions, since they're not required to install ExecuTorch.

[mergennachin]

Thank you @keyprocedure

[keyprocedure]

Happy to help!

[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.

❌ 1 New Failure

As of commit df9c97a with merge base 7b39a0c ():

NEW FAILURE - The following job has failed:

• pull / test-moshi-linux / linux-job (gh)
  test_exported_decoder_xnnpack

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

[keyprocedure]

If the downgrade is being caused by something that I'm doing incorrectly during the install process/isolated to my build, I can remove the no-deps flag from the pip install command for this PR. I'm open to any suggestions/guidance.

[mergennachin]

Hi @keyprocedure

I did some digging and found out that torchvision and torchaudio were in fact downgrading.

torch, torchvision and torchaudio are in lock step dependency.

I did some refactoring in (#11653). torchvision and torchaudio are not absolute necessity. Only used for examples.

Once that PR is landed, we can update the Intel instruction to be as follows:

Build torch from source
./install_executorch.sh --use-pt-pinned-commit --minimal

[keyprocedure]

Hey @mergennachin, I really appreciate your follow up!

Perfect, that'll simplify things.
I'll update the Intel instructions in this PR once #11653 lands.

[mergennachin]

Hi @keyprocedure

I just landed the PR, please rebase. Hopefully it will simplify a lot of things in this PR

[keyprocedure]

@mergennachin I've rebased and updated the Intel macOS install instructions to ./install_executorch.sh --use-pt-pinned-commit --minimal. Feel free to let me know if there's anything else that needs to be changed.

[mergennachin]

See inline

[mergennachin]

Use relative paths

[keyprocedure]

I updated the flag links to use relative paths to the .py file.
For the PyTorch instructions link, since it points to a doc in the PyTorch repo, is there a way to reference that using a relative path, or should we keep the current path?

[mergennachin]

Let's not have two instructions. Let's consolidate Intel based instructions in "building from source section" and call it a day

[keyprocedure]

Good point, moved the instructions.

[mergennachin]

s/Executorch/ExecuTorch/g

[keyprocedure]

I removed the mention of building Torchvision and Torchaudio from source in the building-from-source doc for Intel-macOS builds to simplify the instructions, since they're not required to install ExecuTorch.

[mergennachin]

Thank you @keyprocedure

[keyprocedure]

Happy to help!

[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.

❌ 1 New Failure

As of commit df9c97a with merge base 7b39a0c ():

NEW FAILURE - The following job has failed:

• pull / test-moshi-linux / linux-job (gh)
  test_exported_decoder_xnnpack

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

[keyprocedure]

If the downgrade is being caused by something that I'm doing incorrectly during the install process/isolated to my build, I can remove the no-deps flag from the pip install command for this PR. I'm open to any suggestions/guidance.

[mergennachin]

Hi @keyprocedure

I did some digging and found out that torchvision and torchaudio were in fact downgrading.

torch, torchvision and torchaudio are in lock step dependency.

I did some refactoring in (#11653). torchvision and torchaudio are not absolute necessity. Only used for examples.

Once that PR is landed, we can update the Intel instruction to be as follows:

Build torch from source
./install_executorch.sh --use-pt-pinned-commit --minimal

[keyprocedure]

Hey @mergennachin, I really appreciate your follow up!

Perfect, that'll simplify things.
I'll update the Intel instructions in this PR once #11653 lands.

[mergennachin]

Hi @keyprocedure

I just landed the PR, please rebase. Hopefully it will simplify a lot of things in this PR

[keyprocedure]

@mergennachin I've rebased and updated the Intel macOS install instructions to ./install_executorch.sh --use-pt-pinned-commit --minimal. Feel free to let me know if there's anything else that needs to be changed.

[mergennachin]

See inline

[mergennachin]

Use relative paths

[keyprocedure]

I updated the flag links to use relative paths to the .py file.
For the PyTorch instructions link, since it points to a doc in the PyTorch repo, is there a way to reference that using a relative path, or should we keep the current path?

[mergennachin]

Let's not have two instructions. Let's consolidate Intel based instructions in "building from source section" and call it a day

[keyprocedure]

Good point, moved the instructions.

[mergennachin]

s/Executorch/ExecuTorch/g

[keyprocedure]

I removed the mention of building Torchvision and Torchaudio from source in the building-from-source doc for Intel-macOS builds to simplify the instructions, since they're not required to install ExecuTorch.

[mergennachin]

Thank you @keyprocedure

[keyprocedure]

Happy to help!