[RFC] tlcpack: Thirdparty Binary Packages

Development pre-RFC
#21

@leandron I support all of that. Do you have cycles to re-engage with pypa? It seems like we would do this for just the tlcpack package and not tlcpack-nightly?

I imagine our package retention policy might be somewhat informed by whatever quota we’re allowed. On the -nightly server, we can likely find quota if needed, but probably want to retain only e.g. a week or two.

Could you say more on this one?

#22

It relates to making sure that at some point in the release process we generate the tlcpack, including all supported configuration, and upload it to pypi.

In practice, it means amending the docs at (Apache TVM Release Process — tvm 0.9.dev114+g278173c18 documentation) to mention at least to create a ticket on tlcpack so that packages are created and uploaded properly, given the subtle distinction of TVM being an Apache project and tlcpack a community initiative.

I have some experience and ideas on how to amend tlcpack to make it able to upload to pypi, given we get credentials e quota for our packages, would you (@areusch or @tqchen or @haichen) mind to deal with points 1 and 2 on my list above, while I prototype the changes on tcpack repo?

#23

@leandron I could work on this in Jan.

#24

So, updating this thread again, we’re currently improving tlcpack so that is able to upload packages into PyPI.

During the investigation for these improvements, we realised we own the project name apache-tvm in PyPI, and as a way to make it simpler for our users to get hold of a TVM package, we’ll be using that namespace. The intended final result is that an user can simply pip install apache-tvm to get the latest CPU-capable release version of TVM.

Other packages will be available for GPU enabled builds, similar to what mxnet does: mxnet · PyPI. We can’t promise any time scales for this to be delivered. In case that is important for you, we invite you to get involved.

Current status:

  • We sorted out the required credentials for apache-tvm on PyPI so that committers who want to contribute with packaging work are able to (thanks @areusch and @driazati)
  • We have an ongoing PR that adds functionality to tlcpack GitHub Actions to upload a package to PyPI - https://github.com/tlc-pack/tlcpack/pull/102 (CPU only)

Next steps:

  • We welcome more contributions and people interested in helping with packaging. This is the only way to speed-up this process
  • Expand this work for GPU enabled packages
  • Collaborate with other initiatives in the TVM project so that we can link this works with a more frequent release process, as well as making the package available very soon after the release is declared in TVM.
1 Like
#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