# \[RFC\] Consolidating TVM Python Dependencies

**URL:** <https://discuss.tvm.apache.org/t/rfc-consolidating-tvm-python-dependencies/8329>\
**Category:** RFC\
**Created:** [October 29, 2020, 4:17pm UTC](https://discuss.tvm.apache.org/t/rfc-consolidating-tvm-python-dependencies/8329 "2020-10-29T16:17:24Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![mjs](https://discuss.tvm.apache.org/user_avatar/discuss.tvm.apache.org/mjs/32/143_2.png) [@mjs](https://discuss.tvm.apache.org/u/mjs)\
**Post date:** [November 2, 2020, 9:49am UTC](https://discuss.tvm.apache.org/t/rfc-consolidating-tvm-python-dependencies/8329/10 "2020-11-02T09:49:21Z")

</div>

Hi. The semver proposal makes sense to me. There is arguably a case the that maximum major version constraints should be provided since the semver definition of a major version change specifically implies a breaking change of some form.

w.r.t the discussion around requirements.txt, common convention and best practice encourages that:

- install\_requires: provide abstract, minimal, requirements for a specific package
- requirements.txt: provides exhaustive pinned versions for a compete environment

There is a general overview here: [https://packaging.python.org/discussions/install-requires-vs-requirements/](https://packaging.python.org/discussions/install-requires-vs-requirements/)

The end user experience is defined by how we manage install\_requires, rather than what we provide in a requirements.txt. While requirements.txt foo is a viable way to share fixed environments within the tvm projects own developer community, we should focus on the install\_requires mechanism for tvm end users, because, that is the one they will use by default.

---

_[View the full topic](https://discuss.tvm.apache.org/t/rfc-consolidating-tvm-python-dependencies/8329)._