I am also seeing this exact error on a clean build.  It happens to me every time too.  The error happens in the build output around 2 hours into my build, but the build keeps going for another 10 hours, then the build says it failed on py39-duckdb, although the actual failure is on py39-setuptools-scm-8.0.4.  But I noticed that py39-setuptools-scm-8.0.4 actually DOES succeed later in the build after the errors.  That's why, when the build stops/fails, if you just do the make again, it all succeeds (45min later for me), and it doesn't try to redo py39-setuptools-scm-8.0.4, because that actually did succeed the first time.

Anyhow, since this is 100% reproducible for me, if you want me help with investigation or testing a fix or whatever, just let me know.

Also, is there a way to *only* build the py39 stuff, hopefully can reproduce this in a much shorter timeframe?

Thanks,
John

Having the same issue. Running on 14-STABLE. All ports are up to date except py-setuptools-scm. So i have this error immediately after a clean make.

Comment 3 Koichiro Iwao 2024-03-05 07:00:09 UTC

If py39-setuptools_scm-6.4.2 is installed, uninstall it first and try to install devel/py-setuptools-scm.

It's a clean build of py-duckdb with nothing installed (chroot).


Cheers,
Franco

I'm having the same issue here and it also appears there's no package available?

Comment 6 Charlie Li 2024-03-06 02:36:40 UTC

databases/py-duckdb doesn't specify this as a dependency in any form, so something else in your environments is not clean. And speaking of which, building Python package ports in environments other than something resembling poudriere has not really been supported in the Python world for a while now. This will be elaborated on in CHANGES after some more setuptools changes are made.

This version will not be cherry-picked to the current quarterly.

In my case it is plain py-setuptools-scm make that fails missing infer_version
14.0-STABLE FreeBSD 14.0-STABLE #0 009c8a3d2


[myuser@myhost:/usr/ports/devel/py-setuptools-scm] # make clean
===>  Cleaning for git-2.44.0
===>  Cleaning for py39-setuptools-scm-8.0.4


[myuser@myhost:/usr/ports/devel/py-setuptools-scm] # make
===>  License MIT accepted by the user
===>   py39-setuptools-scm-8.0.4 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by py39-setuptools-scm-8.0.4 for building
===>  Extracting for py39-setuptools-scm-8.0.4
=> SHA256 Checksum OK for setuptools-scm-8.0.4.tar.gz.
===>  Patching for py39-setuptools-scm-8.0.4
===>   py39-setuptools-scm-8.0.4 depends on package: py39-setuptools>0 - found
===>   py39-setuptools-scm-8.0.4 depends on package: py39-wheel>0 - found
===>   py39-setuptools-scm-8.0.4 depends on file: /usr/local/bin/python3.9 - found
===>   py39-setuptools-scm-8.0.4 depends on package: py39-tomli>0 - found
===>   py39-setuptools-scm-8.0.4 depends on package: py39-build>=0 - found
===>   py39-setuptools-scm-8.0.4 depends on package: py39-installer>=0 - found
===>   py39-setuptools-scm-8.0.4 depends on file: /usr/local/bin/ccache - found
===>  Configuring for py39-setuptools-scm-8.0.4
===>  Building for py39-setuptools-scm-8.0.4
* Getting build dependencies for wheel...
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
    main()
  File "/usr/local/lib/python3.9/site-packages/pyproject_hooks/_in_process/_in_process.py", line 335, in main
    json_out['return_val'] = hook(**hook_input['kwargs'])
  File "/usr/local/lib/python3.9/site-packages/pyproject_hooks/_in_process/_in_process.py", line 118, in get_requires_for_build_wheel
    return hook(config_settings)
  File "/usr/local/lib/python3.9/site-packages/setuptools/build_meta.py", line 177, in get_requires_for_build_wheel
    return self._get_build_requires(
  File "/usr/local/lib/python3.9/site-packages/setuptools/build_meta.py", line 159, in _get_build_requires
    self.run_setup()
  File "/usr/local/lib/python3.9/site-packages/setuptools/build_meta.py", line 174, in run_setup
    exec(compile(code, __file__, 'exec'), locals())
  File "setup.py", line 1, in <module>
  File "/usr/local/lib/python3.9/site-packages/setuptools/__init__.py", line 87, in setup
    return distutils.core.setup(**attrs)
  File "/usr/local/lib/python3.9/site-packages/setuptools/_distutils/core.py", line 139, in setup
    _setup_distribution = dist = klass(attrs)
  File "/usr/local/lib/python3.9/site-packages/setuptools/dist.py", line 476, in __init__
    _Distribution.__init__(
  File "/usr/local/lib/python3.9/site-packages/setuptools/_distutils/dist.py", line 275, in __init__
    self.finalize_options()
  File "/usr/local/lib/python3.9/site-packages/setuptools/dist.py", line 899, in finalize_options
    for ep in sorted(loaded, key=by_order):
  File "/usr/local/lib/python3.9/site-packages/setuptools/dist.py", line 898, in <lambda>
    loaded = map(lambda e: e.load(), filtered)
  File "/usr/local/lib/python3.9/site-packages/setuptools/_vendor/importlib_metadata/__init__.py", line 196, in load
    return functools.reduce(getattr, attrs, module)
AttributeError: module 'setuptools_scm.integration' has no attribute 'infer_version'

ERROR Backend subprocess exited when trying to invoke get_requires_for_build_wheel
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/py-setuptools-scm

Upps, in my case there was indeed an older version. Removed and build works

pkg version | grep setuptools
py39-setuptools-63.1.0_1           =
py39-setuptools-pkg-0.9            =
py39-setuptools-rust-1.8.1         =
py39-setuptools_scm-6.4.2          ?

> databases/py-duckdb doesn't specify this as a dependency in any form, so something else in your environments is not clean.

How can you say this? Multiple people are CC'd now and this only stared a few days ago so isn't it at all likely that this is an issue in the framework, i.e. a single commit responsible?

> And speaking of which, building Python package ports in environments other than something resembling poudriere has not really been supported in the Python world for a while now.

While the over-reliance on poudriere is another topic I don't agree with the sentiment that this shouldn't be fixed, because poudriere is not infallible and I've reported framework bugs in the past that had maintainers go out on a limb accusing me of all sorts of things until they figured it out and fixed it.  :)

> This will be elaborated on in CHANGES after some more setuptools changes are made.

Yes, please.

> This version will not be cherry-picked to the current quarterly.

I don't quite get the reference.

The python response on this has been less-than-stellar, but it's still early.

If you need help pinpointing this let me know.  Not knowing about the intricacies of setuptools and current work efforts I don't want to spend hours figuring this out on my own.


Cheers,
Franco

Comment 10 Charlie Li 2024-03-06 06:50:26 UTC

(In reply to Franco Fichtner from comment #9)
Others have suggested that this problem goes away upon finding and removing the old/stale setuptools_scm (under that old name). If this port didn't change directories, this issue some of youse are encountering probably wouldn't happen. Unfortunately MOVED isn't entirely foolproof. I have never encountered this issue myself, and neither have the official package builders, because of the use of clean and isolated build environments that are destroyed upon completion.

> While the over-reliance on poudriere is another topic I don't agree with the sentiment that this shouldn't be fixed, because poudriere is not infallible and I've reported framework bugs in the past that had maintainers go out on a limb accusing me of all sorts of things until they figured it out and fixed it.  :)
I was only using poudriere as an example of a clean and isolated build environment automation. For Python packages, poudriere specifically is almost irrelevant; the greater Python community have all but embraced virtual environments for nearly everything that is purely Python. When it comes to building PEP-517 packages (ie bdist wheels), we actually override devel/py-build's default behaviour of creating and building in a virtualenv by passing a flag not to, because otherwise Python packages installed via pkg(8) aren't picked up or prioritised. Isolating environments is thus necessary, as some Python packages (unfortunately) pin specific dependency versions, and in nearly every case, two versions of the same package cannot co-exist in the same environment. It is further unfortunate that said pins are necessary in certain cases due to feature/functionality deprecations/removals. setuptools is a casualty of this. As a result, this reality extends to Python package port builds, and as such, building Python package ports in-place is not supported.

Ok, let me ask another way: what do you need from me to find and fix this? As I said it's likely an inherent framework problem and even if you don't agree with that it wouldn't be bad to take that to the test, or would it?


Cheers,
Franco

Ok, interesting: the renaming of the package coupled with the version update probably caused this.  I'm looking forward to that missing UPDATING entry then.


Cheers,
Franco

To be clear: 
A "make" of a port should be always possible, no matter if a earlier version exists. If there could be a conflict, there is a check if already installed on "make install" :

/usr/ports/devel/py-setuptools-scm] # make install
===>  Installing for py39-setuptools-scm-8.0.4
===>  Checking if py39-setuptools-scm is already installed
===>   Registering installation for py39-setuptools-scm-8.0.4
Installing py39-setuptools-scm-8.0.4...

So yes: this was annoying....