Make ´delete_existing_job´ available to the ´AtomisticGenericJob´ class

[raynol-dsouza]

The AtomisticGenericJob class inherits from the GenericJobCore/GenericJob class. While the GenericJobCore.copy_to() has the argument delete_existing_job, AtomisticGenericJob.copy_to() doesn't. Since Protocol jobs create child jobs, the workflows of some of the them rely on an existing child job being deleted, while using copy_to(). Hence, the PR.

In addition, PyCharm kept complaining that the copy_to() of AtomisticGenericJob did not have the same signature as the copy_to() of GenericJobCore.

[coveralls]

Pull Request Test Coverage Report for Build 849156107

• 4 of 4 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.006%) to 67.126%

---

Totals
Change from base Build 831005000:	0.006%
Covered Lines:	10575
Relevant Lines:	15754

---

💛 - Coveralls

[liamhuber]

Will not get to the review until Monday, but nice catch!

[liamhuber]

The functional code looks perfect; I streamlined the docstring part over in #200 so please review and merge that first.

Not related to your PR, but while we're touching this bit of code: I was unhappy to see that the extra functionality in this child class (a) used not instead of an explicit is not None check, and (b) wasn't covered in the unit tests. So once we get this signature fix in, I'll go write a new unit test.

[pmrv]

Looks good to me, but I had a itch to make it a bit cleaner in pyiron_base and open this and this.

This would make this PR not necessary, but I feel the new PR needs a bit more architecture discussion, so I'd suggest we merge this so that @raynol-dsouza gets this work done and then work on the tests in the new PR.

[liamhuber]

This would make this PR not necessary, but I feel the new PR needs a bit more architecture discussion, so I'd suggest we merge this so that @raynol-dsouza gets this work done and then work on the tests in the new PR.

Yeah, I like this. I'm a giant fan of solving the problem as close to the source as possible, but for the sake of immediacy there's no reason to delay merging this more local fix!