AttributeError: 'HigherOrderOperator' object has no attribute 'py_functionalize_impl'

[ice-ux]

Traceback (most recent call last):
File "C:\Users\17255.conda\envs\myenv\lib\runpy.py", line 194, in _run_module_as_main
return run_code(code, main_globals, None,
File "C:\Users\17255.conda\envs\myenv\lib\runpy.py", line 87, in run_code
exec(code, run_globals)
File "D:\edge\executorch\examples\xnnpack\aot_compiler.py", line 14, in
from executorch.backends.xnnpack.partition.xnnpack_partitioner import XnnpackPartitioner
File "C:\Users\17255.conda\envs\myenv\lib\site-packages\executorch\backends\xnnpack_init.py", line 8, in
from .partition.xnnpack_partitioner import (
File "C:\Users\17255.conda\envs\myenv\lib\site-packages\executorch\backends\xnnpack\partition\xnnpack_partitioner.py", l
ine 14, in
from executorch.backends.xnnpack.partition.configs import (
File "C:\Users17255.conda\envs\myenv\lib\site-packages\executorch\backends\xnnpack\partition\configs.py", line 8, in
from executorch.exir.dialects.ops import ops as exir_ops
File "C:\Users\17255.conda\envs\myenv\lib\site-packages\executorch\exir_init.py", line 9, in
from executorch.exir.capture import (
File "C:\Users\17255.conda\envs\myenv\lib\site-packages\executorch\exir\passes_init.py", line 19, in
from executorch.exir import control_flow, memory, memory_planning
File "C:\Users\17255.conda\envs\myenv\lib\site-packages\executorch\exir\memory_planning.py", line 20, in
from executorch.exir.delegate import executorch_call_delegate
File "C:\Users\17255.conda\envs\myenv\lib\site-packages\executorch\exir\delegate.py", line 120, in
@executorch_call_delegate.py_functionalize_impl
AttributeError: 'HigherOrderOperator' object has no attribute 'py_functionalize_impl'

[kegsay]

I'm also getting this on MacOS when trying to follow the tutorial https://pytorch.org/executorch/stable/getting-started-setup.html#generate-a-sample-executorch-program - AttributeError: 'HigherOrderOperator' object has no attribute 'py_functionalize_impl'

When running: python3 -m examples.portable.scripts.export --model_name="add"

[kegsay]

I'm guessing this is due to #1149 ( 5c92ab9 ) which is weird as the tutorial specifically pins to branch v0.1.0 from October, whereas that PR is from November.

[kegsay]

Actually this is due to the torch dependency being out-of-date now. When running install_requirements.sh it produces:

ERROR: Could not find a version that satisfies the requirement torch==2.2.0.dev20231010
(from versions: 2.2.0.dev20231021, 2.2.0.dev20231022, 2.2.0.dev20231023, 2.2.0.dev20231024, 2.2.0.dev20231025, 2.2.0.dev20231026, 2.2.0.dev20231027, 2.2.0.dev20231028, 2.2.0.dev20231029, 2.2.0.dev20231030, 2.2.0.dev20231031, 2.2.0.dev20231101, 2.2.0.dev20231102, 2.2.0.dev20231103, 2.2.0.dev20231104, 2.2.0.dev20231105, 2.2.0.dev20231106, 2.2.0.dev20231107, 2.2.0.dev20231108, 2.2.0.dev20231109, 2.2.0.dev20231110, 2.2.0.dev20231111, 2.2.0.dev20231112, 2.2.0.dev20231113, 2.2.0.dev20231114, 2.2.0.dev20231115, 2.2.0.dev20231116, 2.2.0.dev20231117, 2.2.0.dev20231118, 2.2.0.dev20231119, 2.2.0.dev20231120, 2.2.0.dev20231121, 2.2.0.dev20231122, 2.2.0.dev20231123, 2.2.0.dev20231124, 2.2.0.dev20231125, 2.2.0.dev20231126, 2.2.0.dev20231127, 2.2.0.dev20231128, 2.2.0.dev20231129, 2.2.0.dev20231130, 2.2.0.dev20231201, 2.2.0.dev20231202, 2.2.0.dev20231203, 2.2.0.dev20231204, 2.2.0.dev20231205, 2.2.0.dev20231206, 2.2.0.dev20231207, 2.2.0.dev20231208, 2.2.0.dev20231209, 2.2.0.dev20231210, 2.2.0.dev20231211, 2.2.0.dev20231212, 2.2.0.dev20231213, 2.3.0.dev20231214)
ERROR: No matching distribution found for torch==2.2.0.dev20231010

Changing this to torch==2.2.0.dev20231021 fixes this error, and I am able to continue with the tutorial.

For versioned releases like v0.1.0 of executorch, it would be nice if those dependencies were persisted and not deleted...

---

For now, the fix would be to change NIGHTLY_VERSION in install_requirements.sh to something which exists: I chose2.2.0.dev20231021 as it is the closest in age version that is still available. Note that this is inherently fragile. If there is a breaking change in 2.2.0.dev20231021 then potentially executorch v0.1.0 becomes unusable.

[mergennachin]

Hi @huydhn

For release/0.1 branch, we use a specific torch nightly version dev20231010. However, looks like it is expired recently. Is it possible to keep the binary permanently?

https://github.com/pytorch/executorch/blob/release/0.1/install_requirements.sh

https://download.pytorch.org/whl/nightly/torch/

[huydhn]

So, dev20231010 nightly binaries are still there, but it's now older than 60 days and has been removed from PyTorch nightly index. After chatting with @mergennachin a bit, we have decided on the following steps:

• Keep nightly 20231010 for ExecuTorch alpha 0.1 for now builder#1642 is a quick fix to keep dev20231010 in the nightly index. It has been committed and the index re-generated. So, the issue is mitigated now, and I can run bash install_requirements.sh on 0.1.0 branch locally without any issue

$ conda list | grep torch
executorch                0.1.0                    pypi_0    pypi
torch                     2.2.0.dev20231010          pypi_0    pypi
torchaudio                2.2.0.dev20231010          pypi_0    pypi
torchfix                  0.1.1                    pypi_0    pypi
torchvision               0.17.0.dev20231010          pypi_0    pypi

• In ExecuTorch future releases, we need to use PyTorch stable releases instead (and test against them too). PyTorch stable release schedule for 2024 can be found here https://dev-discuss.pytorch.org/t/release-cadence-for-year-2023-2024/1557, just FYI