Fix symlink management in extension packaging backend.
Review Request #14902 — Created March 14, 2026 and submitted
Our extension packaging backend creates a symlink for
.npm-workspaces,
but the implementation managing it had a bug in cases where we're
potentially doing things multiple times.In our case, the Power Pack wheel gets built repeatedly for different
Python versions. After the first build, we clean up the tree, leaving
the workspaces link dangling. In this case, the call to.exists()
returnsFalse, but the symlink is still there, and we'll fail when
attempting to create it again.The fix is to check first if it's a symlink and unlink, and then
otherwise check if there's something present which is not a symlink.
Did a test build of an extension.
| Summary | ID |
|---|---|
| wyqswrllxmwllopmzykwsksmlxnvrkyv |
| Description | From | Last Updated |
|---|---|---|
|
Maybe a typo in the description: "the Power Pack gets built". I don't think we want "the", unless I'm misreading. |
|
- Description:
-
Our extension packaging backend creates a symlink for
.npm-workspaces,but the implementation managing it had a bug in cases where we're potentially doing things multiple times. ~ In our case, the Power Pack gets built repeatedly for different Python
~ versions. After the first build, we clean up the tree, leaving the ~ workspaces link dangling. In this case, the call to .exists()returns~ False, but the symlink is still there, and we'll fail when attempting~ to create it again. ~ In our case, the Power Pack wheel gets built repeatedly for different
~ Python versions. After the first build, we clean up the tree, leaving ~ the workspaces link dangling. In this case, the call to .exists()~ returns False, but the symlink is still there, and we'll fail when~ attempting to create it again. The fix is to check first if it's a symlink and unlink, and then
otherwise check if there's something present which is not a symlink.