Faster startup: ezdxf and vtk imported on use

[kimstik]

import cadquery loaded ezdxf and vtk although most sessions never touch a DXF or a render window. They are now imported by the functions that use them, and a test in a fresh interpreter keeps them out.

Here the import drops from 1.50 to 1.10 seconds - 0.35 for ezdxf with fontTools, 0.15 for vtk - and loads 417 modules instead of 693.

Annotations that name vtk types are forward references now; typing.get_type_hints() on those five functions resolves them once vtk is imported.

[kimstik]

The rest is OCP: registering 321 packages on import, which costs about a second.
Cadquery needs half of them.
Lazy registration in the generator would recover about 0.5 seconds.
Nanobind would go further I guess.

upd:
lazy registration shows 0.16 sec instead of 0.79 on import OCP
requires basic OCP patching CadQuery/OCP#226

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.81%. Comparing base (cb26a27) to head (02a0aa3).
⚠️ Report is 4 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2097      +/-   ##
==========================================
+ Coverage   95.76%   95.81%   +0.05%     
==========================================
  Files          30       30              
  Lines        9584     9609      +25     
  Branches     1437     1444       +7     
==========================================
+ Hits         9178     9207      +29     
+ Misses        250      247       -3     
+ Partials      156      155       -1     

☔ 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.

[adam-urbanczyk]

Thanks, but with the exception of shapes, I'd like those files not to be touched. E.g. it does not make sense to me to make the dxf module lazy when its main dep is ezdxf. I'd rather have the top level CQ modules import them inside of the relevant methods (Sketch.export, Workplane.export, Assembly.export, ...).

[kimstik]

My reasoning was to put each import next to its only use, so that the change stays small and no caller of dxf.py can bring ezdxf back by accident - two files, a dozen lines. Your split reads better in the package, though: the core does not import the I/O modules until it exports, and dxf.py stays a plain module about ezdxf. Agreed.

To keep vtk out of import cadquery as well, toVTK() in occ_impl/assembly.py needs its import moved inside - two lines.

OK to touch that one, or ezdxf only for now @adam-urbanczyk ?

[adam-urbanczyk]

Yeah, not problem with changing toVTK