dev_environment.py: copy the runtime libraries next to the wrapper - #9489
Open
theoryshaw wants to merge 2 commits into
Open
theoryshaw wants to merge 2 commits into
theoryshaw wants to merge 2 commits into
Conversation
Replacing a package folder with a symlink aborted on the first PermissionError, leaving the extension partially linked - Blender can't import it until the script is run again, and nothing in the traceback said so. rmtree is only reached on the first setup, since later runs find a symlink and unlink it instead. That means the unguarded branch is also the one that always runs while the extension binaries are newly written and most likely to be held by an antivirus scanner, which on Windows surfaces as PermissionError (WinError 5). Retry the removal a few times before giving up, and if it still fails, print what state the extension is in and that re-running is safe. Also note that copying the compiled wrapper has to stay ahead of the symlinking - that ordering is what kept the binaries recoverable when this aborted. Closes IfcOpenShell#9239 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The compiled dependencies were collected with a "ifcopenshell/*_wrapper*" glob, written when the wrapper was a single self-contained binary. Since 0.9.0 it isn't. The package ships runtime libraries alongside it - ifcopenshell.parse.dll, ifcopenshell.geometry.dll, the per-schema ifcopenshell_parse_schema_ifc*.dll and friends - which are loaded by name at runtime rather than linked, so none of them match that glob. Only the wrapper was copied into the repo, and the symlink that replaces the package folder then shadowed the originals left in site-packages. The wrapper came up with nothing it needed and failed at import with "RuntimeError: No schema named IFC4", a long way from the cause. Select on file type instead of on the name. Checked against both generations: identical selection for ifcopenshell-0.8.6a260708-py313, and 8 files rather than 2 for 0.9.0a260909. The schema libraries are picked up by the same rule once they ship, and .so/.dylib keep Linux and macOS from hitting the same gap. Closes IfcOpenShell#9488 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #9488.
The compiled dependencies were collected with a
ifcopenshell/*_wrapper*glob, written when the wrapper was a single self-contained binary.Since 0.9.0 it isn't. The package ships runtime libraries alongside it —
ifcopenshell.parse.dll,ifcopenshell.geometry.dll, the per-schemaifcopenshell_parse_schema_ifc*.dlland friends — which are loaded by name at runtime rather than linked, so none of them match that glob. Only the wrapper was copied into the repo, and the symlink that replaces the package folder then shadowed the originals left behind in site-packages. The wrapper came up without the libraries it needs and failed at import withRuntimeError: No schema named IFC4, a long way from the cause.This selects on file type instead of on the name. Checked against both generations:
ifcopenshell-0.8.6a260708-py313ifcopenshell-0.9.0a260909-py313No behaviour change on 0.8.6. On 0.9.0 it picks up the six runtime libraries that were being dropped. The schema libraries are collected by the same
.dllrule once they ship, and.so/.dylibkeep Linux and macOS from hitting the same gap.Worth noting this is independent of #9423 despite the identical error text: that one is the Windows packaging step failing to collect
ifcopenshell_parse_schema_ifc*.dllinto the published zip, this one is the dev-link script failing to copy runtime libraries that are present. They compound — once #9423 ships fixed packages, this glob would still drop the schema libraries on everydev_environment.pyrun.Stacked on #9240, which touches the same region of this file — please merge that one first. Until it lands this PR's diff shows both commits; it narrows to the single commit here once #9240 is merged.
🤖 Generated with Claude Code