Add Brep to supported importShape functions

[brhubbar]

• Makes Brep support available to the importer 'factory' implemented separate to the Shape object
• Accounts for the case where a Brep returns as a non-iterable, such as a Solid
• This is not unit tested but has worked for my purposes This is unit tested, thanks for the assist from Adam
• Ready for review ✔️

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (245b6f3) 94.41% compared to head (ebb95ca) 94.48%.
Report is 7 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1467      +/-   ##
==========================================
+ Coverage   94.41%   94.48%   +0.06%     
==========================================
  Files          28       28              
  Lines        5769     5780      +11     
  Branches     1068     1071       +3     
==========================================
+ Hits         5447     5461      +14     
+ Misses        194      193       -1     
+ Partials      128      126       -2     

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

[adam-urbanczyk]

Could you add a test?

[brhubbar]

Hmm. I seem to be a bit stuck. I baked the test into the existing importStep, since the results should be the same for both cases. However, importBrep seems to be returning a Shell on the azure pipeline:

AssertionError: 'Shell' != 'Solid'

I cannot replicate this locally (I get a shape type of Solid). @adam-urbanczyk - can you

• see if you can reproduce the failure coming from Azure and maybe help me troubleshoot
• or, grant permission to not assert that the import be a Solid? This option seems wrong to me - I don't see why a box wouldn't be a solid on import, since it is a closed surface by definition. However, I don't want to overconstrain myself if I'm misunderstanding

Edit: The volume isn't coming back correctly either -

    self.assertAlmostEqual(importedShape.val().Volume(), 6)

E   AssertionError: 22.0 != 6 within 7 places (16.0 difference)

I'm really uncertain of what's happening, and cannot reproduce on my end

[adam-urbanczyk]

@brhubbar I think I fixed the issue. Could you make the diff coverage 100%?

[brhubbar]

@adam-urbanczyk I have pushed a new test, but it looks like all of your test pipelines are failing as of 8:00 AM CST yesterday due to an issue with libmambapy.

[adam-urbanczyk]

Yes, we'll fix it, but pls focus on appveyor results. Those are actionable for you (i.e. failing because of black and not CI issues).

[brhubbar]

Okay - sorry for all of the lazy test writing; I've been trying to send up fixes in between other things and it has not been working. I fixed my environment, am getting results consistent with the CI pipelines, and have some time to think about this.

My latest test revealed an inconsistency between the STEP and BREP importers. This is because the STEP importer might import multiple "Shapes" and always tosses them into a list for Workplane.newObject - even if the STEP import returns a single Compound. The Brep importer was splitting compounds out into multiple Solids. While this made sense to me - it isn't consistent with how the brep is exported, so I changed it to just toss the whole compound as a single object onto the workplane. A comment in the importer explains how to get the previous behavior.

[brhubbar]

Hey @adam-urbanczyk - just checking if there's anything more you would like to see from me on this - as far as I can tell, tests are passing now (assuming they test the actual behavior you'd like to see)

[jmwright]

Thanks @brhubbar

@adam-urbanczyk Do you know what is causing Python 3.12 on Windows to hang on Azure? It hangs on the first Bash step.

[adam-urbanczyk]

I think it works now.

[jmwright]

Looks good, merging.