pyiron / pyiron_workflow

Graph-and-node based workflows
BSD 3-Clause "New" or "Revised" License
10 stars 1 forks source link

[patch] Revert save overload #234

Closed liamhuber closed 2 months ago

liamhuber commented 4 months ago

Reverts #225. Waiting on #226 so we don't lose functionality of getting the requested name, which in turn is waiting on pyiron_base 1356.

github-actions[bot] commented 4 months ago

Binder :point_left: Launch a binder notebook on branch _pyiron/pyiron_workflow/revert_saveoverload

codacy-production[bot] commented 4 months ago

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
:white_check_mark: -0.01% (target: -1.00%) :white_check_mark: 100.00%
Coverage variation details | | Coverable lines | Covered lines | Coverage | | ------------- | ------------- | ------------- | ------------- | | Common ancestor commit (7a5db1dda4d2bdaf75b4bedf1e8e5e513e4e42ec) | 3390 | 2971 | 87.64% | | | Head commit (ff6729bff932fa122df1cc733db30c8fe198da44) | 3388 (-2) | 2969 (-2) | 87.63% (**-0.01%**) | **Coverage variation** is the difference between the coverage for the head and common ancestor commits of the pull request branch: ` - `
Diff coverage details | | Coverable lines | Covered lines | Diff coverage | | ------------- | ------------- | ------------- | ------------- | | Pull request (#234) | 1 | 1 | **100.00%** | **Diff coverage** is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: `/ * 100%`

See your quality gate settings    Change summary preferences

You may notice some variations in coverage metrics with the latest Coverage engine update. For more details, visit the documentation

coveralls commented 4 months ago

Pull Request Test Coverage Report for Build 8543077322

Details


Files with Coverage Reduction New Missed Lines %
job.py 4 90.2%
<!-- Total: 4 -->
Totals Coverage Status
Change from base Build 8543047016: -0.005%
Covered Lines: 6340
Relevant Lines: 6903

💛 - Coveralls
liamhuber commented 3 months ago

With pyiron_base 1358, the naming stays as requested by default when you actually instantiate a job from the class, so we need zero special behaviour in this repo to get the behaviour we want.

After the next base release, this can be re-tested on the updated version and merged.