Self-compiled versions get numbered the way they don't fit requirements of standard wheels

bones0: <p>Windows 10, Python 3.11.</p>
<p>I compiled a 2.1.0 and a 2.0.0 (why did checking out the tag v2.0.1 get me a version 2.0.0, though?). However, the self-compiled versions are all like torch-2.0.0a0+gite9ebda2 and even torchvision 0.15.1, which should work with 2.0.0, refuses this version string. How do I manipulate the wheel (or the source before creating the wheel) so it does show a version string which is recognised as “==2.0.0”? Or where do I get a torchvision, torchaudio etc. which is a bit less strict? Compiling torch takes around 8 hours on my Alienware 13 notebook so recompiling the whole torch*-universe would be a bit much.</p>
<p>The conflict is caused by:<br>
The user requested torch 2.0.0a0+gite9ebda2 (from C:\repos\stable-diffusion-webui\torch-2.0.0a0+gite9ebda2-cp311-cp311-win_amd64.whl)<br>
torchvision 0.15.2 depends on torch==2.0.1<br>
The user requested torch 2.0.0a0+gite9ebda2 (from C:\repos\stable-diffusion-webui\torch-2.0.0a0+gite9ebda2-cp311-cp311-win_amd64.whl)<br>
torchvision 0.15.1 depends on torch==2.0.0</p>
<p>ERROR: Cannot install torch 2.0.0a0+gite9ebda2 (from C:\repos\stable-diffusion-webui\torch-2.0.0a0+gite9ebda2-cp311-cp311-win_amd64.whl), torchvision==0.15.1 and torchvision==0.15.2 because these package versions have conflicting dependencies.</p>
<p>P.S: I compile it since I want to use the Tesla K40c wich compute-capability 3.5. It works for games so why shouldn’t it work for ML too? <img src="https://discuss.pytorch.org/images/emoji/apple/wink.png?v=12" title=":wink:" class="emoji" alt=":wink:" loading="lazy" width="20" height="20"></p>
<p>Should you want to examine the wheels or need them for one of your own projects they are available at <a href="http://www.chabis.ch/webordner/machinelearning/pytorch-cuda-arch-3.5-cuda11.8/" class="inline-onebox" rel="noopener nofollow ugc">Index of /webordner/machinelearning/pytorch-cuda-arch-3.5-cuda11.8</a></p>

bones0: <p>I found <a href="https://github.com/pytorch/xla/issues/3661" class="inline-onebox" rel="noopener nofollow ugc">Wheel version numbers are incompatible with `torch (==1.11.0)` · Issue #3661 · pytorch/xla · GitHub</a> which resolves to “don’t use unofficial wheels”. Does not fix my problem. Maybe tha hack-script mentioned there does, but that’s not the most elegant way I could imagine.</p>

bones0: <p>Cross-referencing to <a href="https://github.com/pytorch/xla/issues/3661#issuecomment-1689641318" class="inline-onebox" rel="noopener nofollow ugc">Wheel version numbers are incompatible with `torch (==1.11.0)` · Issue #3661 · pytorch/xla · GitHub</a> - I’ll continue at the forum where I get the answer first <img src="https://discuss.pytorch.org/images/emoji/apple/wink.png?v=12" title=":wink:" class="emoji" alt=":wink:" loading="lazy" width="20" height="20"> (Not sure if anybody will answer to a long-closed issue at github at all)</p>

ptrblck: <p>Cross-posting the same questions usually just wastes time as multiple users will often try to help. In any case, you can use some env variables to define a custom version. Set these to <code>2.0.1</code> and it should work.</p>

bones0: <p>True. Well, I don’t expect any answer at github since the issue is closed for so long so it’s probably more like a reference. Actually the “patching”-was works but is tedious. I will try to find out what environment variables I have to set. Any hint where I should start looking for? I am currently searching the repository for the version string. Maybe I am lucky and there’s a set-command or $env somewhere.</p>
<p>EDIT: I guess I got it:</p>
<p>TORCH_BUILD_VERSION:STRING=2.0.0a0+gite9ebda2</p>
<p>in CmakeCache.txt</p>
<p>EDIT: Nope, setting that in $env does not seem to impress the compiler in any way.</p>
<p>Final edit: Changed it in version.txt. Minimal - just removed the 0a which is breaking all dependencies. Had to re-compile anyway since the K40c does not seem to work wit CUDNN which I compiled into the other 2.0.0-wheel.</p>
<p>I somehow expected the checkout of a tag would actually build the version tagged. Does not seem to be the case, though.</p>

bones0: <p>I hid the other comment on github as resolved since the script / manual patching actually works. Just not the way I want to go.</p>

bones0: <p>I consider this solved since I can change the version.txt and all source code packages saying they are 2.0.1 consistently have 2.0.0a0 in version.txt. So I can safely assume they have the funcionality of 2.0.1. And if it’s only 2.0.0 it also works for me. I have it labelled 2.0.0 now and it works with stablediffusion-webui.</p>
<p>If there is an environment variable which can be set and actually works is not sure at this point but as far as I am concerned this is currently irrelevant. I hope in future versions version.txt will make sense again and the environment variable will be documented somewhere. If it exists.</p>
<p>All in all I have mixed feelings working with pytorch but I understand it’s a really complex project so I accept some minor trouble.</p>