[Bug 277472] devel/py-setuptools-scm: AttributeError: module 'setuptools_scm.integration' has no attribute 'infer_version'

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277472

--- Comment #10 from Charlie Li <vishwin@freebsd.org> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.