Disable LTC by default until upstream revert relands

[powderluv]

Tracked with the WIP #1292

[henrytwo]

I assume the issues are due to PyTorch constantly reverting and unreverting that change which changed some function signatures, right?

When @antoniojkim reverts part of his changed (or PyTorch reverts again...), I assume this should be fixed?

Is there anything we can do to improve the stability here? It seems that we kinda just have to deal with this due to usually the latest PyTorch master

[henrytwo]

Oh wait minor comment, perhaps we should have a comment to link back to the issue, in case people are confused about why it's disabled?

This way we also know what code to "rollback" when reenabling

[ashay]

We face a similar issue internally (even before the current revert/re-revert pattern), so we pin the PyTorch version in requirements.txt and bump it the most recent PyTorch version when we update Torch-MLIR. Is that (i.e. updating PyTorch on demand) something that we would be open to doing here as well?

[powderluv]

@henrytwo yes added a comment.

@ashay yes we can pin & roll. Ideally we can automate the roll so we don't fall too behind (or even have an informational top of main build so we know if there is a breakage).

[silvasean]

We face a similar issue internally (even before the current revert/re-revert pattern), so we pin the PyTorch version in requirements.txt and bump it the most recent PyTorch version when we update Torch-MLIR. Is that (i.e. updating PyTorch on demand) something that we would be open to doing here as well?

Yes, I think that moving to a model where we update PyTorch on demand would be better here. We already do that for LLVM/MLIR, and now that LTC gives us so much more exposure to PyTorch churn I think it would benefit from the same kind of approach.