<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 11, 2024 at 4:23 AM fourtysixandtwo <<a href="mailto:fourtysixandtwo@sliderr.net">fourtysixandtwo@sliderr.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Sep 10, 2024 at 12:55 PM Jeremy Hansen <<a href="mailto:jebrhansen%2BSBo@gmail.com" target="_blank">jebrhansen+SBo@gmail.com</a>> wrote:<br>
> export SETUPTOOLS_SCM_PRETEND_VERSION=$VERSION<br>
><br>
> and a few<br>
><br>
> export PDM_BUILD_SCM_VERSION=$VERSION<br>
><br>
> to fix some issue with versions not being detected properly during build time (although, I believe several are due to me choosing GitHub tarballs instead of PyPi, which are packaged differently). If those hacks were to be fixed by these updates, I'd remove them.<br>
<br>
I use the pypi tarballs solely because I can also grab the MD5SUM they provide with my update script.</blockquote><div><br></div><div>This isn't an issue for me as my update script will generate MD5SUM automatically no matter how many source files there are. It will just download everything in the DOWNLOAD or DOWNLOAD_X86_64 variables in the .info (if they don't already exist) and then generate MD5s for all of them and update the .info file.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It is a bonus that I haven't had to use those methods above with any builds I maintain.</blockquote><div><br></div><div>This is a minor inconvenience for a handful of packages that prefer downloads from PyPi or a git clone (rather than an archive download from a tag/release). Luckily, out of the 150+ packages I maintain, there's probably less than a dozen that I had to add this tweak/hack. I think my preference to GitHub was many python packages I took over that used PyPi as their source location used hashed download links, which prevented my update script from using the right download link (although, I suppose I could add the functionality to switch to links that simply require updating the version -- future me will worry about that :D). This led me to prefer GitHub links and then outta sheer stubbornness, when problems arose from it, I found hacks to continue using GitHub over PyPi.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I just checked with python3-tox and python3-pyproject-api tarballs from pypi and they both include a "src/*/*version.py".  One does have to watch for the change in source from say pyproject-api to pyproject_api in both download and SRCNAM though.<br>
<br>
Have you come across this for troubleshooting?<br>
export SETUPTOOLS_SCM_DEBUG=true<br></blockquote><div><br></div><div>I was not aware of that flag, however, it led to either a similar or the same issue (too lazy to investigate further right now).</div><div><br></div><div>"mAke sURe yoU're EitHer bUildINg frOM A FulLy iNTAcT git RepOsiToRY oR PyPi taRbaLLs."</div><div><br></div><div>Error, meet stubbornness (my hack) :D</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">While we are on the topic of setuptools_scm, I have a method using<br>
venv to upgrade it to 8.1.0, but unfortunately the newer versions do<br>
not honour PYTHONPATH precedence and import the older slackware 15.0<br>
version.  One would have to remove the older system package or use the<br>
venv hack on every slackbuild that requires the newer setuptools_scm<br>
in /opt.</blockquote><div><br></div><div>I mean, we currently have to add hacks in SlackBuilds to use newer python packages residing in /opt/ (which are mostly, if not entirely, packages you maintain). This has opened up the ability to upgrade a lot of python packages further than would be allowed if we solely used the packages from 15.0. They've been very helpful in allowing upgrades without additional hacks.</div><div><br></div><div>If the newer version offers something severely lacking on Slackware or SBo today, I (and I can only speak for myself), have no issues adding a line or few to my SlackBuilds that require that newer version.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Upstream is aware of this issue but don't have any interest in fixing it currently.</blockquote><div><br></div><div>That sucks.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Go for it! It's easier than me trying to merge your changes and submit a PR this week.<br>
<br>
Done!<br></blockquote><div><br></div><div>Thanks! </div></div></div>