Update pip package

The pythonocc-core pip package has not been updated since Dec 4, 2014 and use pythonocc-core v0.16. It should be updated to the last version v0.18.1.

we should remove this package indeed, or update it with a message suggesting to install via conda instead.

Please update instead of removing it ;)

@jf---

@jf--- @tpaviot is there actually any plan to update the pip package (or provide access to .whl files)? It would be incredibly helpful for a project I am currently developing where I can't use Anaconda packages.

would indeed be nice to update the pypi package instead of removing it :-)

@jf---

@jf--- @tpaviot Friendly ping. 😇

Do not know how hard it would be, but would you accept a PR to fix this? Or is it simply that you do not want to support non-Conda installations at all? If so, is there a technical reason/limitation?

It seems to me like Python wheels could help nowadays distributing the package through PyPI, but I do not know much about them, so I may be missing something.

Hello, does Python OCC work in python 3.7 or 3.8?

Why doesn't it have been updated?

I'm not a conda user, is there any benefit to making something a conda package instead of a pip package? I've honestly never seen that done before.

Related to Azure/azure-functions-core-tools#796

@traverseda

@traverseda a bit of history. When I started pythonocc, in 2008 (12 years ago !!), pip was only able to install 100% pure python packages. It was not able to install precompiled binary packages that contain c or c++ code. At that time, pip used to download the source code and launch the build process on your machine. It was perfect on Linux, where a c/c++ compiler is installed by default, but not for Windows users: Windows users usually don't have a c/c++ compiler installed. Most of the questions I had were : "How to I install mingw32 on my machine ?". A nightmare.

In 2010, when the project started to spread, the question was not "pip" or "conda" or whatever, but: "what's the best way to distribute precompiled binaries for each platform ?". conda was born to solve this issue. It saved many packages maintainers life. Later, python egg/wheels provided the same solution. It became possible to easily install pythonocc using conda, everybody was ok with that. Nobody asked for another solution, since this one does the job.

Now, here is the point: creating/maintaining a pip package is a dozens-of-hours commitment per year. I have serious doubts that this investment would bring any valuable improvement, compared to the same amount of time I could spend on other issues. Just convince me. Or take the lead on this topic.

@tpaviot

Just convince me.

@tpaviot In an attempt to do so... 😇

PyPI packages are more accessible, and I think that is a pretty good reason. If you have Conda, you can install packages with pip, but it is not possible the other way around. Some people may not have Conda.

You could argue that those people can install Conda, but sometimes that is not possible. Nowadays many people deploy projects to the cloud and many cloud services do not offer Conda-based images (at least not in their "free" tiers"). Some offer Docker-based images (which allows you to use Conda or whatever you want), but at a different price (usually higher of course). This can hurt even toy projects. I have been in a situation where I did not deploy a toy project simply because it was going to cost me money if deployed with the Conda requirement (and I was of course not going to make any money out of it).

You do have a maintenance burden when adopting pip, but maybe it is not much more than the burden you have for Conda (I may be wrong here though, since I have no real experience packaging wheels). What I would suggest is not to have both packages, but only the wheels, since that works for both pip and conda users. Hopefully the hours you spend packaging for pip are compensated by the hours you do not spend packaging for conda. 🤞

@tpaviot

The main argument against wheels is, that you can't bundle binary only packages.

Conda allows this and this is the reason why we started creating conda packages.

Also, conda provides a nice build infrastructure to create packages, which is not given otherwise (especially compiled packages).

One other issue is the maintenance overhead @tpaviot already mentioned. Building 1 pythonocc configuration already takes an hour. Adding another hour for occt. Multiply this with the number of python versions, architectures and operating systems.

It could be possible to combine the occt and pythonocc conda packages into a wheel, avoiding recompilation. This is IMHO the only practical way for a small team of maintainers with limited compute resources and spare time.

@rainman110

@rainman110 Thanks for the clarification. Being an OSS project, did you have a look at GitHub actions to maybe take care of that building process for you? Limits seem to be generous.

We're already running on azure which is pretty similar to Github Actions.

@scopatz

Interesting talk related to conda-press here https://www.youtube.com/watch?v=ovMqBLspkK4 @scopatz

Hi there. I tried to use conda-press for building whl from conda packages. Firstly, keep in mind this issue about Python38. Also, if you use --fatten option to glue packages up into single whl, pip will not be able to install this package because there is several *.dist-info in single whl. If build it without --fatten, you will get the separated whl s for each of sub-packages (fontconfig, vc, freetype, tbb, etc.) but in this case you will not be able just run pip install pythonocc_core-7.4.0-0_*.whl, because pip is not able to search in the current folder for different dependencies (of course), so you should done it manually in specific order. Then, after manual installing of all packages from whl's you will get the errors about missed DLL's such as TKernel and so on, that's because all of this libs was placed in the venv/Lib/site-packages/Library/bin and by default venv doesn't looks in this place. So what's your thoughts about it?
P.S. I wasn't able to run conda-press with installed CPython... by default, in active conda env when you call conda press it looks this script in your CPython folder... It's very annoying.

That could result in issues if I used another pip package that also distributes (possibly incompatible) OCCT.

I mean obviously it wouldn't install the compiled OCCT to the same place on the OS as the native package manager. It would install it into a folder belonging to that particular package, meaning you could have different versions of the library in different virtual-envs and all that stuff.

At no point should a pip package be installing statically-compiled files anywhere but into their own package namespace.

My understanding is that the conda package is already distributing it that way, and it's only the compile step that relies on the native package manager (apt/yum/whatever) having OCCT/SMESH installed? That's what I understood from going through install.md.

I'm not referring to the OS but to a different python package depending on OCCT. On linux you can use rpath for isolation, but what do you intend to do on win? Static linking or adding UUIDs to the DLL names? I'm just trying to point out that it will likely become a mess rather fast.

Conda BTW is not working like that - it has a separate package for OCCT and a separate packages for PythonOCC which depends on the former. The compile step (conda build) actually uses conda to fetch the deps, so you can rely on other people providing OCCT builds.

On 10/2/20 6:48 PM, traverseda wrote: <snip> .... I also don't imagine anyone would be too worried about you not providing conda packages if a pip package is available? The goal here would be to try and replace the conda package with a pip package? ..

I, for one, would be *very* unhappy to have a pip package instead of a conda package. Conda is far superior to pip, especially in managing complex packages with C, C++, and other libraries, which is the main motivation for developing conda in the first place: scientific and engineering packages often involve complex library dependencies that pip is not good at managing. If you don't know about that, you should read some of the history of conda -- it would be worth your time, especially if you are going to continue editorializing about it. Steve

If you don't know about that, you should read some of the history of conda -- it would be worth your time, especially if you are going to continue editorializing about it.

Can you explain a bit more about how not providing a conda package would impact your workflow? Does your environment not use any pip packages? As an end-user of the library, how does not packaging via conda actually change anything? Are you swapping out the shared libraries each package depends on? I get that for a long time it was pretty much the only way to distribute binary packages but other than that I'm having a hard time finding any advantages for end users, other than it being an alternative/wrapper for virtualenv's.

One of the big advantages of pip for binary packages is that you can have a binary distribution (wheel) and source distribution (sdist) in one pip package. So that means if I wanted to install a package on a weird CPU architecture, it will just build the package for that architecture. I've found that very useful when working on projects in the embedded world, particularly using buildroot-based linux distros with AArch64 numpy.

I mean before you're too dismissive about the pip ecosystem you should take a moment to understand why a lot of users want it, aside from just not wanting to be forced into the conda ecosystem.

Static linking or adding UUIDs to the DLL names?

How does this conda package solve that problem? It does allow you to install different versions of the package into different environments right? Is it bundling it's own linker?

CMake is definitely an area I'm weak in, but I'd probably try to follow along with something like this. Most of these presume a single shared-library per python package. Not sure if that would be a deal breaker, as I'm still having trouble understanding what advantages the conda package provides, aside from being easier on the maintainers.

A lot of bigger packages do have a conda package and a pip package, I think it's a lot easier to go from wheel to conda than the other way around. I agree that for a package like this it would probably be a lot of work. Basically it would mean maintaining two completely different build systems, which is not something I think anyone would want.

On 10/3/20 12:50 PM, traverseda wrote: If you don't know about that, you should read some of the history of conda -- it would be worth your time, especially if you are going to continue editorializing about it. Can you explain a bit more about how not providing a conda package would impact your workflow? Does your environment not use any pip packages? As an end-user of the library, how does not packaging via conda actually change anything? Are you swapping out the shared libraries each package depends on? I get that for a long time it was pretty much the only way to distribute binary packages but other than that I'm having a hard time finding any advantages for end users, other than it being an alternative/wrapper for virtualenv's.

I do not use any pip packages, I exclusively use conda. The conda package manager comes with its own "pip", so you /can/ do "pip install" inside a conda environment. However, if you want to build a conda package that has dependencies for which conda packages are not available, you will want to create conda packages for them -- fortunately, if they are pure python packages that is almost trivially easy: conda has a command "skeleton" that can create a conda "recipe" from a PyPI package, and then just run "conda build [package]" on the recipe, done. I have done that many times, since I use only conda to build my packages.

One of the big advantages of pip for binary packages is that you can have a binary distribution (wheel) and source distribution (sdist) in one pip package. So that means if I wanted to install a package on a weird CPU architecture, it will just build the package for that architecture. I've found that very useful when working on projects in the embedded world, particularly using buildroot-based linux distros with AArch64 numpy.

I don't find that to be an advantage, but then I do not work in the "embedded world", so I can't speak to that. I only deploy my apps on Linux, Windows, and OSX.

I mean before you're too dismissive about the pip ecosystem you should take a moment to understand /why/ a lot of users want it, aside from just not wanting to be forced into the conda ecosystem.

I understand a lot about the pip ecosystem, since I have been programming in Python for more than 20 years so I only used pip until a few years ago when conda was invented.

Static linking or adding UUIDs to the DLL names? How does this conda package solve that problem? It does allow you to install different versions of the package into different environments right? Is it bundling it's own linker?

It does bundle a lot but if you are interested in that level of detail you need to consult the docs. Conda is quite powerful and can isolate its virtual environments (which are different from pip's) extremely well.

CMake is definitely an area I'm weak in, but I'd probably try to follow along with something like this <https://martinopilia.com/posts/2018/09/15/building-python-extension.html>. Most of these presume a single shared-library per python package. Not sure if that would be a deal breaker, as I'm still having trouble understanding what advantages the conda package provides, aside from being easier on the maintainers. A lot of bigger packages do have a conda package /and/ a pip package, I think it's a lot easier to go from wheel to conda than the other way around. I agree that for a package like this it would probably be a lot of work. Basically it would mean maintaining two completely different build systems, which is not something I think anyone would want.

Actually I think it's easier to go from conda package to wheel -- earlier in this thread, Thomas included a link to Anthony Scopaz's excellent presentation on "conda press", I strongly recommend watching it if you are interested in this level of detail! https://www.youtube.com/watch?v=ovMqBLspkK4

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#667 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFNJEPFSJAVKDJTLX24ECLSI5I4BANCNFSM4IJHZ7OA>.

I do not use any pip packages, I exclusively use conda.

I mean that's just not how 99% of the python world operates.

Are there any end user features you'd be missing if this was a pip package? Are you like dynamically swapping out shared libraries? Are you linking directly to specific shared libraries from c/cpp programs embedded along side the python code?

@scopatz

I will give @scopatz talk a watch when I have a moment later tonight. I'm a big fan, "xonsh" is my primary shell.

Static linking or adding UUIDs to the DLL names?

How does this conda package solve that problem? It does allow you to install different versions of the package into different environments right? Is it bundling it's own linker?

CMake is definitely an area I'm weak in, but I'd probably try to follow along with something like this. Most of these presume a single shared-library per python package. Not sure if that would be a deal breaker, as I'm still having trouble understanding what advantages the conda package provides, aside from being easier on the maintainers.

A lot of bigger packages do have a conda package and a pip package, I think it's a lot easier to go from wheel to conda than the other way around. I agree that for a package like this it would probably be a lot of work. Basically it would mean maintaining two completely different build systems, which is not something I think anyone would want.

I'm not referring to how conda is isolating envs, I'm asking you how do you want to isolate different packages (say NetGen and PythonOCC) that depend on OCCT (shared lib) installed in the same env. To my understanding there is no good way of doing this with pip, because it is not (does not want to be?) a "general" package manager. Conda, on the contrary, is and allows to just install an OCCT package.

In my company we use databricks as a Ai Development enviornment and in the newer versions of databricks conda got completly removed and replaced with virtualenv and pip. The only way to work around this is to use some custom docker containers, but that is not a very good solution cause some features then dont work anymore. So is there a way to use python occ with databricks without using a custom dockercontainer ?

Hi there. I tried to use conda-press for building whl from conda packages. Firstly, keep in mind this issue about Python38. Also, if you use --fatten option to glue packages up into single whl, pip will not be able to install this package because there is several *.dist-info in single whl. If build it without --fatten, you will get the separated whl s for each of sub-packages (fontconfig, vc, freetype, tbb, etc.) but in this case you will not be able just run pip install pythonocc_core-7.4.0-0_*.whl, because pip is not able to search in the current folder for different dependencies (of course), so you should done it manually in specific order. Then, after manual installing of all packages from whl's you will get the errors about missed DLL's such as TKernel and so on, that's because all of this libs was placed in the venv/Lib/site-packages/Library/bin and by default venv doesn't looks in this place. So what's your thoughts about it? P.S. I wasn't able to run conda-press with installed CPython... by default, in active conda env when you call conda press it looks this script in your CPython folder... It's very annoying.

We use Azure Functions on Python, so we're limited to only pip in remote builds. Microsoft kind of swept under the rug the possibility of a separate package manager.

I tried to conda-press the pythonocc-core package into a wheel, but got to the point of missing DLLs and left it at that.
Made a working linux-64 environment locally, used pip and conda to install all necessary dependencies, and made it work locally. Deployed to remote linux-64 environment with a --no-build option (function + all the dependencies as a single standalone package) only to find that it still doesn't work on the remote environment, because I cannot guess the exact agent architecture and configuration in a consumption plan (I build on Ubuntu 20.04 and the agent is of an unknown linux-64 arch).

How would one approach the task of building a standalone wheel for pythonocc-core for all of the existing linux-64 packages available on conda-forge? I'm at my wit's end here.

Just want to point out that cadquery-ocp is now published on PyPI: https://pypi.org/project/cadquery-ocp/

If this is published and used by cadquery package, is there a limitation of also publishing pythonocc-core?

I'm joining the request to have the package on pypi.

I get that back then conda was the best choice to distribute binary packages, but this is not the case anymore.
Also, with the advent of uv, project dependencies and environment management is "blazingly fast" as they say...
I'm using it to create docker containers in a fraction of time compared to the other package managers.

But it uses pypi, so trying to install pythonocc-core fails miserably.

Just want to point out that cadquery-ocp is now published on PyPI: https://pypi.org/project/cadquery-ocp/

They have a repository with the build system to generate the wheels, maybe it can help.

BTW: there are other issues that can be closed as duplicates of this...

#1082
#1150
#1156
#1286
#1378

I get that back then conda was the best choice to distribute binary packages, but this is not the case anymore.

Honest question: why is it not the case anymore? Are the issues mentioned here https://pypackaging-native.github.io/ solved?

I get that back then conda was the best choice to distribute binary packages, but this is not the case anymore.

Honest question: why is it not the case anymore? Are the issues mentioned here https://pypackaging-native.github.io/ solved?

Sorry for my bad wording. Yes they are still issues.
But many projects mentioned have solved those and provide wheels with all the dependencies needed, at least for what I see (using pandas/geopandas and IfcOpenShell daily on both windows and wsl ubuntu).

#1502

Navigation Menu

Repository navigation

Update pip package #667

16 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Update pip package #667

Description

Activity

jf--- commented on Aug 5, 2019

giuliobrugnaro commented on Aug 6, 2019

giuliobrugnaro commented on Aug 10, 2019

sim0nx commented on Aug 19, 2019

Peque commented on Sep 24, 2019

ANGEL1303 commented on Sep 30, 2019

traverseda commented on Mar 31, 2020

tpaviot commented on Apr 1, 2020

tpaviot commented on Apr 1, 2020

Peque commented on Apr 1, 2020

rainman110 commented on Apr 1, 2020

Peque commented on Apr 1, 2020

rainman110 commented on Apr 1, 2020

tpaviot commented on Apr 4, 2020

Dogrtt commented on Aug 28, 2020

16 remaining items

traverseda commented on Oct 3, 2020

adam-urbanczyk commented on Oct 3, 2020

waterbug commented on Oct 3, 2020

traverseda commented on Oct 3, 2020

waterbug commented on Oct 3, 2020

traverseda commented on Oct 3, 2020

traverseda commented on Oct 3, 2020

adam-urbanczyk commented on Oct 3, 2020

muhmuhhum commented on Jun 29, 2022

YaroslavKormushyn commented on Jul 18, 2022

lypwig commented on Sep 12, 2022

sanzoghenzo commented on May 22, 2025

adam-urbanczyk commented on May 22, 2025

sanzoghenzo commented on May 23, 2025

tpaviot commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions