Package Details: python-ocp 7.8.1.2+r81.g2dd2ce8a-1

Git Clone URL: https://aur.archlinux.org/python-ocp.git (read-only, click to copy)
Package Base: python-ocp
Description: Python wrapper for OCCT generated using pywrap
Upstream URL: https://github.com/CadQuery/OCP
Licenses: Apache-2.0
Conflicts: python-ocp-git
Submitter: greyltc
Maintainer: greyltc
Last Packager: greyltc
Votes: 1
Popularity: 0.000000
First Submitted: 2020-08-22 14:36 (UTC)
Last Updated: 2025-10-12 18:29 (UTC)

Latest Comments

1 2 3 4 5 6 Next › Last »

greyltc commented on 2025-10-13 09:26 (UTC) (edited on 2025-10-13 09:28 (UTC) by greyltc)

what we have now is a python-ocp package that is ahead of upstream

Indeed. It's ahead of the latest stable upstream release (the code here is still from upstream). I'm just trying to do my best to keep this package (and python-cadquery) working with their pre-built dependencies that come from Arch's official repos. When Arch moves copencascade to a stable release that OCP doesn't support, it's often not easy at all, especially since upstream only supports Anaconda. Compiling a special opencascade just for this package is not fun (I've gone that route in the past), I'm not sure I have the time for that these days.

I'm not sure what version number could really be use

Exactly, I'd have to make one up, which doesn't seem right. Maybe you could try to convince upstream to tag a commit just after the last stable 7.8.x one with 7.9.x or something? Or build123 could enforce a dependency python-ocp <= 7.8.1.2.

s-ol commented on 2025-10-12 20:14 (UTC)

@greyltc: well sure, I bet the build123d folks will be working on that soon, but I don't think they'll start on it until CadQuery/OCP tags a 7.9 release. Essentially what we have now is a python-ocp package that is ahead of upstream (because it ships a OpenCascade 7.9 API) but also mislabelled as version 7.8.

Bumping the version of this package to 7.9.XXX would partially rectify this situation, but I'm not sure what version number could really be use as it will certainly clash with an upcoming actual upstream 7.9 release...

greyltc commented on 2025-10-12 17:42 (UTC)

@s-ol, maybe the best option would be for someone to patch python-build123d so that it works with this package (and Arch's official opencascade 7.9)

s-ol commented on 2025-10-06 10:48 (UTC)

@greyltc: this builds against opencascade now but causes some unexpected dependency problems: the package builds as version 7.8.(…) but wraps the system-provided opencascade 7.9. As a result e.g. python-build123d which depends on python-ocp >= 7.8, < 7.9 builds fine but then doesn't run because the names of some opencascade components have changed. In particular I see:

  File "/usr/lib/python3.13/site-packages/build123d/topology/shape_core.py", line 212, in Shape
    ta.TopAbs_VERTEX: TopoDS.Vertex_s,
                      ^^^^^^^^^^^^^^^
AttributeError: module 'OCP.TopoDS.TopoDS' has no attribute 'Vertex_s'. Did you mean: 'Vertex'?

The options I see are: - use non-system (cadquery/OCP provided) opencascade source - specify depends=('opencascade>=7.8.0' 'foobar<7.9.0') here and downgrade opencascade until upstream updates to opencascade 7.9 (and that propagates to build123d etc)

greyltc commented on 2025-10-04 17:20 (UTC)

I think this should work with the latest opencascade package (1:7.9.1-1) now.

s-ol commented on 2025-08-18 14:48 (UTC)

despite this I'm getting a lot of build errors similar to this:

In file included from /home/s-ol/.cache/paru/clone/python-ocp/src/OCP/OCP/AdvApp2Var_pre.cpp:114:
/home/s-ol/.cache/paru/clone/python-ocp/src/OCP/OCP/NCollection_tmpl.hxx:866:85: error: expected unqualified-id before ‘>’ token
  866 | template <typename TheKeyType,typename Hasher=NCollection_DefaultHasher<TheKeyType>>>
      |                                                                                     ^

There's also deprecations etc. For the moment I've downgraded opencascade to 7.8.1-3 and will keep using my python-ocp build from january.

s-ol commented on 2025-08-18 14:30 (UTC)

a solution for the MPI::MPI_C error is to add mpi to the COMPONENTS list in OCP's CMakeLists.txt. I imagine this was caused by an update to vtk, but I'm not sure if it is to be resolved in OCP or VTK - for the time being I've opened a PR to the ocp repo.

The fix can be applied by adding the following line below the other changes to CMakeList.txt in prepare():

  sed "/freetype/a    mpi" --in-place CMakeLists.txt  # fix vtk MPI dependency

greyltc commented on 2025-07-15 15:21 (UTC)

CMake Error at /usr/lib/cmake/vtk/VTK-targets.cmake:1897 (set_target_properties):

My builds are failing like this too.

greyltc commented on 2025-07-15 03:50 (UTC)

Yeah, it takes forever to build. You can speed up the build by increasing _n_parallel_build_jobs but beware doing that might cause the build to fail while linking (at the end) when it runs out of RAM quite late in the job which is really frustrating. I recommend leaving _n_parallel_build_jobs = 1 and starting the build before you go to sleep.

I recall patching out the progress bars because they were making the build logs difficult for me to read.

rmsc commented on 2025-07-14 18:48 (UTC)

Sadly not building... :('

CMake Error at /usr/lib/cmake/vtk/VTK-targets.cmake:1897 (set_target_properties):
  The link interface of target "VTK::mpi" contains:

    MPI::MPI_C

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
  /usr/lib/cmake/vtk/vtk-config.cmake:147 (include)
  CMakeLists.txt:8 (find_package)

1 2 3 4 5 6 Next › Last »