History support for wire

[adam-urbanczyk]

NB: this required manual implementation due to lack of proper support on the OCCT side. The interface is there, but it does not return anything.

NB2: also includes more robust implementation with edge reordering.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.78%. Comparing base (09773f4) to head (81a2cc5).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2055      +/-   ##
==========================================
+ Coverage   95.76%   95.78%   +0.02%     
==========================================
  Files          30       30              
  Lines        9376     9427      +51     
  Branches     1395     1404       +9     
==========================================
+ Hits         8979     9030      +51     
  Misses        242      242              
  Partials      155      155              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lorenzncode]

One potential issue with history is handling failed operations. Currently it's inconsistent as in this example:

from cadquery.func import *

empty_history = History()
try:
    wire([], history=empty_history)
except Exception:
    pass

disconnected_history = History()
try:
    wire(
        [
            segment((0, 0), (1, 0)),
            segment((5, 0), (6, 0)),
        ],
        history=disconnected_history,
    )
except Exception:
    pass

print(len(empty_history.ops))  # 1
print(len(disconnected_history.ops))  # 0

Should history be committed only on success?

[adam-urbanczyk]

I added an extra check to prevent this. Probably something more generic would be nice to have, but not in this PR.

[jmwright]

Thanks @adam-urbanczyk

Do we have any thoughts on whether the edge reordering will have a performance impact, mainly on larger models?

[jmwright]

It's unusual for us to have an assert outside of the tests, isn't it?

[adam-urbanczyk]

True, I wanted to use this pattern more often because it is more concise. Other than being new, do you see drawbacks?

[jmwright]

No drawbacks, and I'm used to adding asserts within the code in 1 or 2 other languages I work in. I just noted it because it breaks an existing pattern in the codebase.

[adam-urbanczyk]

I don't expect this to be significant. If it becomes an issue in the future, I can add a robust: bool=True flag gating the reordering.