deep copy not copying data

[berceanu]

statepoint = copy.deepcopy(job.sp)
del statepoint['a']

results in changes to the workspace folder, i.e. the removing of parameter 'a' from signac_statepoint.json.

[csadorf]

Thank you for reporting! Which Python version are you running?

[csadorf]

@berceanu I'm having trouble reproducing the bug. Can you verify that this unit test should trigger the described behavior?

[bdice]

This triggers the confusing behavior:

import copy
import os
import signac
pr = signac.init_project('issue_153')
job = pr.open_job({'a': 1})
job.init()
print(job._id)  # 42b7b4f2921788ea14dac5566e6f06d0
copy_sp_bug = copy.deepcopy(job.sp)
copy_sp_bug['a'] = '🐛'
print(job.sp)  # {'a': 1}
print(copy_sp_bug)  # {'a': '🐛'}
print(list(iter(project)))  # [signac.contrib.job.Job(project=signac.contrib.project.Project({'project': 'issue_153', 'project_dir': '/home/bdice/tmp_signac_153', 'workspace_dir': '/home/bdice/tmp_signac_153/workspace'}), statepoint={'a': '🐛'})]
assert job in project  # fails! We have a job handle that doesn't exist in the project anymore...?

[csadorf]

After looking more closely at this issue, we have come to the conclusion that it actually makes most sense that a copy or a deepcopy will still modify the underlying state point and thus job albeit operating on a different in-memory reference. That is because a state point and a job for that matter are directly tied to a specific location on the file system and that doesn't change just because we have a different reference.

What users actually intend when they create a deepcopy of a state point is to generate a dict that is no longer tied to the job and thus the file system. For this, users are advised to use Job.sp() or Job.sp._as_dict().

We have fixed the deepcopy behavior of Job and added unit tests to ensure that we actually implement the behavior described above in pull request #207 .

To help avoid user confusion, we will need to improve the documentation on how to convert state points to dicts (glotzerlab/signac-docs#39).