Add Tuple support to CQGI

[jmwright]

Closes #1370

Missing Tuple support was mentioned in this commit. @lorenzncode Are there changes that need to be made in this PR to recapture your original intent from #1367 ?

[lorenzncode]

@jmwright I'm new to CQGI. I expected the default value of the parameter to match the value of the script.

model = cqgi.parse(user_script)
params = model.metadata.parameters
for p, v in params.items():
    print(v.name, v.default_value)

I get 'pnt (0, 0, 0)' instead of 'pnt (0.5, 0.5, 0.5)'

user_script is the example from the assy docs:

cadquery/doc/assy.rst

Line 786 in 76dbeef

pnt = (0.5, 0.5, 0.5)

[codecov]

Codecov Report

Merging #1373 (f4cd9b2) into master (f467ac9) will increase coverage by 0.04%.
The diff coverage is 100.00%.

❗ Current head f4cd9b2 differs from pull request most recent head 9dfd0d1. Consider uploading reports for the commit 9dfd0d1 to get more accurate results

@@            Coverage Diff             @@
##           master    #1373      +/-   ##
==========================================
+ Coverage   94.24%   94.29%   +0.04%     
==========================================
  Files          28       28              
  Lines        5790     5804      +14     
  Branches      987      991       +4     
==========================================
+ Hits         5457     5473      +16     
+ Misses        199      198       -1     
+ Partials      134      133       -1     

Files	Coverage Δ
cadquery/cqgi.py	81.53% <100.00%> (+1.86%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[jmwright]

@lorenzncode That should be fixed now.

[lorenzncode]

Thanks @jmwright. Should tuples of arbitrary length be supported? Say I have a parameter used with pushPoints or Sketch push.

[jmwright]

@lorenzncode Tuples of varying length are supported now.

[lorenzncode]

@jmwright I tried another tuple case with CQGI.

import cadquery as cq

pts = ((0, 0), (0, 10))
result = cq.Workplane().pushPoints(pts).box(1, 2, 3, False)

show_object(result)

This results in Unable to handle assignment for variable 'pts'.

[jmwright]

@lorenzncode How much tuple nesting should we allow?

[lorenzncode]

@jmwright A few thoughts on the CQGI input parameter issue:

1. Extend the CQGI supported types to include additional commonly used types.

   It's difficult to predict what might be commonly used such as the tuple nesting level. Perhaps the new types would be something like:

   • 'VectorLike type': as in geom.py line 28

   • 'Sequence of points type' Along the lines of the pushPoints argument type: Iterable[Union[VectorLike, Location]]

   • pros:

     • Straighforward for CQGI to validate input parameters

   • cons:

     • User script must conform to the supported input parameter types

       Say my script defines a sequence of float, string pairs. I can try to redefine the script to use the CQGI types, else I am out of luck.

2. (or) Provide a mechanism to define custom input parameter types

   • pros:

     • More flexibility in defining input parameters

   • cons:

     • I assume it might require additional boilerplate?

[adam-urbanczyk]

@lorenzncode are you actually using it? Maybe it is not the best thing to work on in terms of ROI?

[lorenzncode]

@adam-urbanczyk No, I'm not. Agree, this was hypothetical based on my understanding of the purpose of CQGI.

[jmwright]

@lorenzncode My suggestion would be that we move your thoughts above into another CQGI issue, and I'll see about supporting a tuple of (vector-like) tuples via the ast.tuple class.

[jmwright]

@lorenzncode @adam-urbanczyk This PR does not have all the extra features mentioned above, but it seems work solve the immediate problem of CQGI not handling tuples at all. Please review when you have time.

[lorenzncode]

Thanks @jmwright. Here is a friendly reminder to squash if you end up doing the merge.