feat: set the __file__ variable for scripts loaded from files

[justbuchanan]

Implements #36.

This works by simply prepending __file__ = <path> at the top of the script if it's loaded from an on-disk path (not stdout).

I think it's debatable whether this is the most correct/pythonic approach for importing python modules (outlined in #36) as opposed to doing something like PYTHONPATH=path/to/other/modules cq-cli .... However, I am also using __file__ to find and load resources like stl/step files that exist in the project relative to the model file and PYTHONPATH doesn't really work there.

[justbuchanan]

The tests related to parameter-passing are failing now because __file__ is showing up as a parameter and throwing off the order of the checks. For example, test_parameter_analysis is seeing this as the output parameter list: [{"type": "string", "name": "__file__", "initial": "/home/justin/src/github/cq-cli/tests/testdata/cube_params.py"}, {"type": "number", "name": "width", "initial": 1}, {"type": "string", "name": "tag_name", "initial": "cube"}, {"type": "boolean", "name": "centered", "initial": true}]

[justbuchanan]

Ok, fixed all the tests except the freecad one, which was already failing.

[jmwright]

Thanks @justbuchanan . I will fix the FreeCAD test separately, it does not need to delay this PR.

Are there any cases where injecting __file__ this way can cause issues with Python's built-in mechanism? Should the user have the option to disable this behavior?

[justbuchanan]

Thanks for taking a look!

Are there any cases where injecting __file__ this way can cause issues with Python's built-in mechanism? Should the user have the option to disable this behavior?

Not that I'm aware of. In normal python execution, __file__ is set, so I don't think there's any harm in doing so here. I can put this behind a feature flag if you'd prefer, but I can't foresee any circumstances where the user would want to disable it.

[jmwright]

One drawback I've thought of is that when users get a stack trace, the line number will be one off from their local copy of the code since a line was injected at the start of the script.

[jmwright]

Looks good @justbuchanan . Let me know if you have any thoughts on shifting the stack trace line number down by one. I think we can merge as-is since cq-cli is more of a production tool than a development tool.

[justbuchanan]

That's a fair point about the stack trace line numbers being off by 1. Looking at this again, a better solution would probably be to pass a value for __file__ into cqgi's CQModel.build() so that it gets added to the environment for exec() here: https://github.com/CadQuery/cadquery/blob/471ab6fcc79b6ce64b857d33d06202c030cf5459/cadquery/cqgi.py#L119. I'll take a look and see how difficult it would be to plumb that value through.