[Slackbuilds-users] important info regarding python3-hatchling update

[Jeremy Hansen]

On Wed, Sep 11, 2024 at 4:23 AM fourtysixandtwo <fourtysixandtwo at sliderr.net>
wrote:

> On Tue, Sep 10, 2024 at 12:55 PM Jeremy Hansen <jebrhansen+SBo at gmail.com>
> wrote:
> > export SETUPTOOLS_SCM_PRETEND_VERSION=$VERSION
> >
> > and a few
> >
> > export PDM_BUILD_SCM_VERSION=$VERSION
> >
> > 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.
>
> I use the pypi tarballs solely because I can also grab the MD5SUM they
> provide with my update script.


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.


> It is a bonus that I haven't had to use those methods above with any
> builds I maintain.


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.


> 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.
>
> Have you come across this for troubleshooting?
> export SETUPTOOLS_SCM_DEBUG=true
>

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).

"mAke sURe yoU're EitHer bUildINg frOM A FulLy iNTAcT git RepOsiToRY oR
PyPi taRbaLLs."

Error, meet stubbornness (my hack) :D


> While we are on the topic of setuptools_scm, I have a method using
> venv to upgrade it to 8.1.0, but unfortunately the newer versions do
> not honour PYTHONPATH precedence and import the older slackware 15.0
> version.  One would have to remove the older system package or use the
> venv hack on every slackbuild that requires the newer setuptools_scm
> in /opt.


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.

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.


> Upstream is aware of this issue but don't have any interest in fixing it
> currently.


That sucks.


> > Go for it! It's easier than me trying to merge your changes and submit a
> PR this week.
>
> Done!
>

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20240911/29afdb1f/attachment.htm>