Additional context:

Commit c3a19ba from 2018 added relevant tests and introduced the use of deepcopy along side with _consolidate_package_data_files:

-    package_data = kw.get('package_data', {}).copy()
+    package_data = copy.deepcopy(kw.get('package_data', {}))

Source: c3a19ba#diff-31c811f03446fcfe70dbf03560cef0781f582d6f5d66334b76b2282e2e0b8733L386-R388

For comparison, this pull request introduces the following changes:

-    package_data = copy.deepcopy(kw.get("package_data", {}))
+    package_data = {k: copy.copy(v) for k, v in kw.get("package_data", {}).items()}

Source: https://github.com/scikit-build/scikit-build/pull/675/files#diff-31c811f03446fcfe70dbf03560cef0781f582d6f5d66334b76b2282e2e0b8733L513-R513

To give some context about why these behavior are different:

My guess is that the first change you linked was made to fix an issue where if a user did

data_names = ['bar']
setup(..., package_data = {'foo': data_names}, ...)

and you just called package_data.copy() it would result in a shallow copy of the dict, so modifying package_data['foo'] inside skbuild would lead to changes in the user-provided input list. Perhaps there were also other side effects within skbuild of such a shallow copy. My changes should still be safe in those cases, but they also address the more subtle case where a user does

data_names = ['bar']
setup(..., package_data = {'foo': data_names, 'baz': data_names}, ...)

In this scenario the deepcopy code will result in skbuild using a new object internally, so it will not persist changes to the caller's data_names variable. However, any changes to package_data['foo'] inside skbuild will also propagate to package_data['bar'] because the deepcopy will see that in the original dictionary both values are references to the same list and will therefore propagate that reference structure to the deep copy.

The analysis sounds correct to me, and this seems fairly safe. I would guess you could still do a deep copy inside (package_data = {k: copy.deepcopy(v) for k, v in kw.get("package_data", {}).items()}) for a little extra peace of mind, but I think this is fine. It still addresses the reason for the original deep copy, it fixes a more subtle version of the problem still present with deepcopy, and it exactly targets the thing we modify for the copy.

You could safely do a deepcopy. I think that the API explicitly requires the values to be lists of strings, so anything that required a deep rather than a shallow copy for safety would violate the existing API, but there's probably no harm in future-proofing in case that changes.

Thanks @vyasr and @henryiii for following up on this 🙏