[RFC] tlcpack: Thirdparty Binary Packages

Development pre-RFC
25

We discussed this at the TVM Community Meeting this morning. Here are some notes:

  • How are we planning to mark versions?
    • PEP 440 discusses the different ways to denote a dev/release version. If we have a package named .devN, this signifies that it’s not a release version.
    • tlcpack infra already takes this into account.
    • After doing this, it will be possible to install nightly packages using pip.
    • The storage aspect is unclear, don’t know whether nightly releases are too often.
    • last-successful tag marks the latest version of tvm in repo.
  • Mehrdad: Are we going to have better dependency tracking in pyproject.toml as part of this effort?
    • That’s in parallel with this effort.
    • It would be nice to
  • Are we able to measure and track downloads to PyPI packages?
    • One of the side effects of pushing new packages nightly is it would reset the download counters.
    • David: pypistats.org reports stats based on project name. Also libraries.io
    • One challenge with the current scheme is that we both upload new packages and delete older packages. This makes it hard to track, and besides that makes it hard to reproduce issues (i.e. if the package is gone).
  • David: are we going to do any testing on the binaries we build? Doesn’t need to block these initial efforts. Would be nice to have at least some core TVM tests that run. Does this make sense?
    • Leandro: Not in place now, but is sort of vital.
  • David: Are we going to do a back-release of 0.8? Or just wait til 0.9.
    • Leandro: suggest to keep producing dev packages for now, and then do 0.9 release.
    • For the 0.9 point release, we’ll need to consider
  • Andrew: Are people going to find the package useful?
    • Gustavo: I just build from source
    • Sebastian: In some of our workflows it would help, in others we’d build from source.
    • Chris: Seems like for anyone who wants to try this out in e.g. PyTorch environments, this would be really useful. Packaging is a useful step in getting TVM into production, and compiling shouldn’t be the end goal.
    • This is probably the wrong group of folks to ask anyway :), we are all developers.
  • Leandro: packages also useful for us to track performance numbers
  • Gustavo: as users would use more of the packages, they will file issues and complain. Very helpful for us to determine the config.cmake and tag used to build that package. How can we promptly get this info based on a bug report?
    • Leandro: The version tag doesn’t have a place for the git hash. We could instead start tagging the package version in the repo.
    • David: Right now we have the point release listed in the python version, but we could have a lot more included.
    • Gustavo: And for the config.cmake, how can we find that?
      • Ideally we could check in the configs to TVM.
  • Are we going to test the packages at all?
    • Leandro: concrete example is when we needed to get standalone_crt in tvmc (extends to all data dependencies)
  • Next steps: progress the PR and check back in after about a month’s time here.
    • Would be great to start publishing CUDA packages. Help wanted here in collaborating with someone who has experience with CUDA. cc @junrushao if you could suggest someone.
2 Likes