# Productionizing native torch extensions

**URL:** <https://dev-discuss.pytorch.org/t/productionizing-native-torch-extensions/668>\
**Category:** release/packaging\
**Created:** [June 24, 2022, 10:58pm UTC](https://dev-discuss.pytorch.org/t/productionizing-native-torch-extensions/668 "2022-06-24T22:58:20Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![\_sean\_silva](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/_sean_silva/32/301_2.png) [@\_sean\_silva](https://dev-discuss.pytorch.org/u/_sean_silva)\
**Post date:** [June 24, 2022, 10:58pm UTC](https://dev-discuss.pytorch.org/t/productionizing-native-torch-extensions/668/1 "2022-06-24T22:58:20Z")

</div>

Hi, I work on the [Torch-MLIR](https://github.com/llvm/torch-mlir) project and we are currently trying to figure out how to productionize our python packaging situation. The biggest problem appears to be how to address version skew / binary compatibility across PyTorch versions vs our native code that links against libtorch. One of my goals here is for `pip install torch-mlir` (with no additional flags or version requirements) to automatically install a binary-compatible torch-mlir+torch combo.

What are the best practices for handling that?

For example, we are playing with [statically linking libtorch](https://github.com/llvm/torch-mlir/pull/955) which removes some degrees of ABI incompatibility surface area but opens up other ones.

---

<div class="post-metadata">

**Author:** ![albanD](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/alband/32/9_2.png) [@albanD](https://dev-discuss.pytorch.org/u/albanD)\
**Post date:** [June 25, 2022, 3:30pm UTC](https://dev-discuss.pytorch.org/t/productionizing-native-torch-extensions/668/2 "2022-06-25T15:30:17Z")

</div>

Hi,

I think the simplest version will be to pin a specific version of PyTorch as the dependency for your package so that the right now comes with your package.  
The way we do this for domain libraries that have the same issue is:

- Releases are pinned against last torch package release
- Nighly binaries are pinned to the latest nightly version of pytorch

This way, both `pip install torchvision` and `pip install --pre torchvision --extra-index-url https://download.pytorch.org/whl/nightly/cpu` work as expected.

---

<div class="post-metadata">

**Author:** ![\_sean\_silva](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/_sean_silva/32/301_2.png) [@\_sean\_silva](https://dev-discuss.pytorch.org/u/_sean_silva)\
**Post date:** [June 27, 2022, 6:13pm UTC](https://dev-discuss.pytorch.org/t/productionizing-native-torch-extensions/668/3 "2022-06-27T18:13:31Z")

</div>

Thanks, that seems like a good approach!