Integration As Third Party Library

Figured I’d start an issue for this because I’m sure I’ll have multiple questions before this integration is done.

Background

I’m working on including cqparts with the CadQuery module for FreeCAD. One of the core philosophies of that module/workbench has always been that it’s batteries included. This means that I include copies of all the required libraries and then manipulate the Python path so that FreeCAD’s Python interpreter can find them.

Question

For cqparts I’ve added a ThirdParty directory, and I’ve cloned the entire repo there. Right now I set the Python path so that ThirdParty/cqparts/src is searched. However, I noticed there was a gitignore file in the src directory. Do you have a mechanism already in place that would allow me to just grab the contents of the src directory, and skip all the higher level items (like docs)? I can look into partial checkouts, but I’m not sure they’re the answer.

[dcowden]

i like the clarity of the above, when the part in question is going to be used from somewhere else. One of the goals of the original cqgi spec was to reduce boilerplate to a minimum. This resulted in removing the imports and, also allowing the author to create just a plain old python file, not a file that declares a function.

Early cqgi designs had scripts that looked like:

import cadquery
from cadquery import cqgi

def build(**kwargs):
    obj = cadquery.Workplane('XY').box(size, size, size)
    cqgi.debug(cube.faces(">Z").workplane())
    return obj

This is extremely similar to the proposal above, with the exception of using a pre-defined method name instead of an arbitrary one with a decorator. Of course it is limited because one python file cannot contain > 1 function. What motivated the move away from that was that it seemed bad to have so much boilerplate for a simple thing. Maybe that was the wrong idea,because the average person interested in cq has been much more ‘geeky’ than i originally intended/hoped. I think clearly the community doesn’t like the magic of the current way of working.

Another motivating factor originally was that I wanted it to be possible to run a cq script from the command line. the above would have to have an additional invocation of the function at the end to actually run it, which is kind of annoying. But, at some point along the way I lost this functionality anyway by removing the need to import show_object. I’d like to recover this ability as a part of the solution.

I could get behind the above @zwn’s proposal above. We would accept that a cadquery script MUST be executed by a cqgi compliant container. To retain the ability to run cq scripts from the command line, I could implement a main function in cqgi that runs a script, such as:

python cqgi.py /usr/src/cube.py

So we’d have the above interface exposed by scripts, and then we’d have the following cqgi executors:

• command line
• sphix doc
• cadquery freecad module
• adam’s new gui
• zwn’s new gui

And then we’d need to go through all of the examples and change their syntax.

I’m ok with this direction but I need a +1 from a lot of folks-- that’d include @fragmuffin @gntech @fragmuffin and @adam-urbanczyk

[fragmuffin]

The typical pattern followed for creating a parametric model is

• define parameters
• build model (with optional paths, like debug)
• display model

However, the problem with this method is that the request to display is done after the model has been made. Therefore the only way to change parameters is to intervene at a higher level (ie: higher than the Python interpreter running it, which is what cqgi does now). So I think there is no clean solution if everything is run in __main__.

However… does everything have to be run in __main__?

The above steps to create a model look a lot like any function:

• define parameters
• process parameters
• output

So if a cube in the current cadquery mindset is made with:

import cadquery

# define parameters
size = 10

# build model
cube = cadquery.Workplane('XY').box(size, size, size)

# display model
show_object(cube)

Instead, could it be:

import cadquery
from cadquery.cqgi import debug, show_object

def cube(size=10):
    obj = cadquery.Workplane('XY').box(size, size, size)
    debug(cube.faces(">Z").workplane())
    return obj

show_object(cube)

now show_object takes in a function that:

• defines only named parameters, all with default values
• returns a cadquery.Workplane instance

show_object can use inspect to look at the function’s parameters and their default values.

I know this is one step toward cqparts, but I don’t see any other way that keeps the code strictly python.