Use setuptools-scm #666
Use setuptools-scm #666
Conversation
|
@yzh119 Version in documentation is broken. I will fix it later. |
| @@ -1 +0,0 @@ | |||
| 0.1.6 | |||
There was a problem hiding this comment.
Should we remain compatible with the previous version? @ur4t
There was a problem hiding this comment.
Personally I believe it is no longer useful:
- Inside our project, all usage are replaced.
- In Python packages version info is generated by
setuptools-scmand stored inflashinfer._version. - For C++ users, usually the whole repo is cloned and they have much more freedom to check versions.
There was a problem hiding this comment.
In Python packages version info is generated by setuptools-scm and stored in flashinfer._version.
Could you explain this in detail, because the latest main seems to be missing?
There was a problem hiding this comment.
Could you explain this in detail, because the latest main seems to be missing?
https://setuptools-scm.readthedocs.io/en/latest/usage/
TLDR: When packaged as wheels/sdists or installed via pip install -e, flashinfer/_version.py is generated which contains all version info (base version and git hash, even cuda version and torch version in AOT mode).
This is enough for most usages I believe.
There was a problem hiding this comment.
Where is the information for the base version obtained from?
If the repo is on a tag such as 0.1.7, the wheels will be flashinfer-0.1.7-cp38-abi3-linux_x86_64.whl(AOT mode) or flashinfer-0.1.7-py3-none-any.whl(JIT mode).
It the repo is not on a tag but a commit after 0.1.7, a local version +gXXXXXXX is attached, such as flashinfer-0.1.7+gXXXXXXX-cp38-abi3-linux_x86_64.whl.
It the repo is not clean, .dYYYYMMDD is attached to +gXXXXXXX.
Additional info like CUDA version and Torch version is collected inside setup.py when the wheel is built in AOT mode and attached like 0.1.7(+gXXXXXXX(.dYYYYMMDD)).cu124torch2.5, but I am afraid it is not proper because 0.1.7.cu124torch2.5 is obviously wrong.
There was a problem hiding this comment.
0.1.6+commit_hash.cu124torch2.5 is ok
0.1.6+commit_hash+cu124torch2.5 is wrong
you can check it with twine check
There was a problem hiding this comment.
0.1.6+commit_hash.cu124torch2.5is ok0.1.6+commit_hash+cu124torch2.5is wrong you can check it withtwine check
Yes. + as indicator of local version should only appear once. 0.1.7.cu124torch2.5 is wrong because only 0.1.7.postX or 0.1.7.devX is allowed.
AFAIK, Pypi does not allow to upload wheels with local version. So which version of Torch (and underlying CUDA) should we use is also a problem.
There was a problem hiding this comment.
AFAIK, Pypi does not allow to upload wheels with local version. So which version of Torch (and underlying CUDA) should we use is also a problem.
I know this. ref #666 (comment)
There was a problem hiding this comment.
I have to admit that setuptools-scm is good but not suitable for Github actions hierarchy:
setuptools-scmrequires more git metadata butactions/checkoutperfers shallow clone.setuptools-scmis not that straightforward asversion.txt.
No description provided.