OCP 7.7.2

[adam-urbanczyk]

Move to OCP 7.7.2

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (7bc8c00) 94.32% compared to head (101f893) 94.64%.
Report is 5 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1440      +/-   ##
==========================================
+ Coverage   94.32%   94.64%   +0.31%     
==========================================
  Files          28       28              
  Lines        5813     6530     +717     
  Branches      994     1303     +309     
==========================================
+ Hits         5483     6180     +697     
- Misses        198      220      +22     
+ Partials      132      130       -2     

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

[adam-urbanczyk]

@lorenzncode @jmwright could you tests this locally? If all is fine, I'll release OCP 7.7.2 and update the conda-forge recipe and finally update cq.

[lorenzncode]

It looks good here. All tests with OCP 7.7.2.0dev pass locally on Linux with Python 3.9, 3.10, 3.11 (with the exception of #1441 unrelated to the OCP update).

I checked some of the open kernel issues but did not find any to be closed by the update.

[jmwright]

It looks good to me to, but I'm leaving the KiCAD generator running with 7.7.2.0dev overnight to see if anything strange happens. I should be able to report back in the morning.

[jmwright]

There is a KiCAD model generator that throws a fuse error now that did not before, but it is a model that has always been problemmatic. I am still investigating, but I do not think that should hold up this PR.

[adam-urbanczyk]

Thanks!

[jmwright]

Actually, after digging back through the log I notice a model that is None now that was not on OCP/OCCT 7.7.1. So I will need to look into that. I'll see if I can generate a MRE from what I find.

[adam-urbanczyk]

@jmwright did you manage to find something?

[jmwright]

@adam-urbanczyk There were some KiCAD models that failed to fuse with 7.7.2, but it seems like OCCT just got more picky about fusing. I think it is a problem with the KiCAD models instead of the kernel. Some of the KiCAD libraries have messy models, with placeholder solids floating just a little bit away from the main solid, and things like that. I think it is fine to move to OCP 7.7.2 and I can work on fixing the KiCAD models when I get a chance.

[adam-urbanczyk]

Conda-forge builds ocp7.7.2 also for py3.12, so this PR is in principle ready

[jmwright]

@adam-urbanczyk I'm building an environment to dogfood this for the next couple of days. I will report back.

[jmwright]

@adam-urbanczyk I am having trouble getting a Python 3.12 environment to build successfully with conda. The only thing I've been able to do is mix conda and pip and so I can't tell if the errors I'm getting with cadquery.vis.show are because of that. Can you give me a mamba/conda command line that will successfully build a Python 3.12 environment with OCP 7.7.2?

[jmwright]

@adam-urbanczyk Thanks for fixing that. I have a working environment now. When I open a repl and try to import CadQuery, I see the following.

y$ python
Python 3.12.0 | packaged by conda-forge | (main, Oct  3 2023, 08:43:22) [GCC 12.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cadquery as cq
/home/jwright/repos/cadquery/cadquery/assembly.py:462: SyntaxWarning: invalid escape sequence '\*'
  """

This seems to be the line it is complaining about.

[jmwright]

Also, cadquery.vis.show seems to be broken.

>>> from cadquery.vis import show
>>> res = cq.Workplane().box(10, 10, 10)
>>> show(res)
2023-12-08 08:46:02.814 ( 275.600s) [        96619740]     vtkOpenGLState.cxx:1795  WARN| Hardware does not support the number of textures defined.

Here is the vtk info for my system. It is Ubuntu 22.04 running on WSL2 on Windows.

+ vtk                                   9.2.6  osmesa_py312h1234567_119  conda-forge/linux-64     Cached
+ vtk-base                              9.2.6  osmesa_py312h1234567_119  conda-forge/linux-64     Cached
+ vtk-io-ffmpeg                         9.2.6  osmesa_py312h1234567_119  conda-forge/linux-64     Cached

I can try on a bare metal Linux system if the above error is not reproducible.

When I drop back to Python 3.11, the syntax warning I posted above goes away, but show still does not work (same error). show works with a Python 3.10/OCP 7.7.1 environment in WSL2, so I know it does work in some configurations.

[adam-urbanczyk]

I cannot reproduce on windows. WSL and gl might be tricky. I'll take look on bare linux

[jmwright]

I tried on a separate laptop with Linux running directly on the hardware, and get the same error.

[lorenzncode]

cadquery.vis.show is also not working for me on Linux with the latest env. I tested with Python 3.12, 3.11, 3.10.

2023-12-08 19:53:47.048 (   1.020s) [         F54D740]     vtkOpenGLState.cxx:1795  WARN| Hardware does not support the number of textures defined.

All tests pass with the new envs.

$ conda list 'ocp|occt|cadquery|vtk|python_abi'
# packages in environment at /home/lorenzn/tools/mambaforge_231019/envs/772py310dec8:
#
# Name                    Version                   Build  Channel
cadquery                  2.4.0.dev0                dev_0    <develop>
occt                      7.7.2           all_h4c9f3c6_201    conda-forge
ocp                       7.7.2.0         py310hc0337cc_1    conda-forge
python_abi                3.10                    4_cp310    conda-forge
vtk                       9.2.6           osmesa_py310h1234567_108    conda-forge
vtk-base                  9.2.6           osmesa_py310h1234567_108    conda-forge
vtk-io-ffmpeg             9.2.6           osmesa_py310h1234567_108    conda-forge

show works with my previous OCP 7.7.2 env created Nov. 11:

$ conda list 'ocp|occt|cadquery|vtk|python_abi'
# packages in environment at /home/lorenzn/tools/mambaforge_231019/envs/772py310:
#
# Name                    Version                   Build  Channel
cadquery                  2.4.0.dev0                dev_0    <develop>
occt                      7.7.2           all_h4c9f3c6_201    conda-forge
ocp                       7.7.2.0dev              py310_0    cadquery/label/dev
ocp-stubs                 7.7.0                    pypi_0    pypi
python_abi                3.10                    4_cp310    conda-forge
vtk                       9.2.6           qt_py310h1234567_208    conda-forge
vtk-base                  9.2.6           qt_py310h1234567_208    conda-forge
vtk-io-ffmpeg             9.2.6           qt_py310h1234567_208    conda-forge

[adam-urbanczyk]

Same for me. If I try to run vtk's hello world I also get it. So seems to be a vtk issue, I'll try to ask around.

[adam-urbanczyk]

🤦 osmesa build is for off-screen rendering

[adam-urbanczyk]

I updated the env, it should work now.

[lorenzncode]

Confirmed show is working now.

A double-backslash in the docstring can resolve the Python 3.12 SyntaxWarning.
cadquery/cadquery/assembly.py:462: SyntaxWarning: invalid escape sequence '\*'

cadquery/cadquery/assembly.py

Line 469 in f587438

:param \**kwargs: Additional keyword arguments. Only used for STEP, glTF and STL.

lorenzncode@a5e410e

[jmwright]

Thanks. Give me a a few more days using this environment now that show is working.

[jmwright]

@adam-urbanczyk Did you change the black version because of Python 3.12?

[adam-urbanczyk]

@lorenzncode thanks! @jmwright indeed, I'm converting back to draft to solve the black issue. My angle of attack will be to switch to a different tool (yapf) and try to replicate the current style with it.

[adam-urbanczyk]

OK, I fixed the issue by forking black 19.10b0 and fixing it for 3.12

[lorenzncode]

Thanks @adam-urbanczyk !
I did not find any new issues. Hopefully the black fork will not require much maintenance in the future.

[jmwright]

Yes, thanks @adam-urbanczyk . I have been using this in my main CQ environment and have not found any other issues.

[adam-urbanczyk]

Alright, merging.

[jmwright]

I missed that the Python 3.12 pin was still in environment.yml. Did we mean to leave that in there?

[adam-urbanczyk]

Hm, not sure. I'll revert to >=3.8 for now. We could also consider moving to 3.9+.