pythonocc-core
pythonocc-core copied to clipboard
tpaviot
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.
@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.
@jf--- @tpaviot Friendly ping. :innocent:
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.
@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.
Just convince me.
@tpaviot In an attempt to do so... :innocent:
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. :crossed_fingers:
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 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.
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.
Another reason for supporting pip: Read the Docs. When you host documentation on Read the Docs, you can choose your build system: either pip xor conda. Locally, on your system, you can of course use both. But not RTD.
So what is the problem with conda and RTD that would be solved by pip?
@adam-urbanczyk More packages are available on PyPI. In my project, there are packages that can only be installed through pip.
Well, you can use conda+pip (also on RTD), take a look e.g. here:
https://github.com/CadQuery/cadquery/blob/2d721d0ff8a195a0902eb9c3add88d07546c05b1/environment.yml#L23 https://github.com/CadQuery/cadquery/blob/master/.readthedocs.yaml
Thanks! I didn't know about the pip: directive in conda environment files.
So the main reason why you should support pip is so that I can add pythonocc-core to my python project's requirements. Where as if this project uses conda, well anything built on top of it is forced to use conda as well.
That's a pretty big difference, and opens up the potential for this to work with projects like python-appimage and pyinstaller.
What's more, the conda package manager is often extremely slow and unsuccessful in resolving dependencies, in which case it does not allow installing the other packages either.
It also doesn't seem to work with existing virtualenvs? Or at least I can't get it to work. So that means no pipenv, no poetry, no pipx, etc.
Using conda locks you out of a lot of a lot of the python ecosystem, and I think that's only going to get worse over time.
I don't know about python-appimage, but you can definitely bundle packages with pyinstaller from a conda env. I used it to build a pythonocc based app with success.
If this is so important for you, you should consider contributing to e.g. conda-press (see above).
There are good reasons to support pip, without any doubt!
But there are currently technical limitations or at least difficulties that makes the creation of wheel packages very hard.
So instead of focusing on the pip vs conda discussion, the discussion should be more on how to actually make pip packages!
@traverseda Feel free to contribute!
Each package management system is very specific, and require strong technical skills as well as a long experience. Nobody here has ever decided to drop pip support in favor of conda. Five years ago, it was easier to get done with conda, that's all. And then we had to maintain the package, and everybody lived happy untill @roipoussiere open this issue :blush:
There are plenty of cool package management systems: pip, apt, yum, brew, choco etc. Impossible to provide packages for all of them. I hope someday someone will try to standardize this mess, but in the meantime indeed anyone is invited to contribute a pip/anything else package.
Right, so I don't have a lot of experience with build systems, aside from occasionally changing a few flags here and there. My day job and my failing business keep me pretty busy these days, but it's great to know that's something the maintainers here are interested in.
Looking through the install directions I notice that it relies on particular libraries installed on the host OS? Most of the time with wheel packages I've seen them pull down all the sources and build them. Basically do a static build and not rely on the OS package manager at all. It's my understanding that that makes the whole thing a whole lot easier to work with, once you actually get it running.
Does that make sense? Having the install download/include all it's dependencies? Or is that going to end up being too much? Basically I'm imagining that if we can get cmake to build the whole thing as a completely static library, not really link against any host packages, that should be most of the battle.
Anyone following this issue with significant cmake experience? Because that's where I'm going to struggle the most.
Other than that, I'm not sure what technical limitations you're expecting, like I say I don't really have experience with conda or what problems it's solving. I think if we can get the cmake stuff working I should be able to get it building/packaging from the setup.py, and therefore working as both a source (for the more exotic architectures) and binary package.
But like I say, I don't really know what I'm talking about here, so please feel free to correct me if I'm oversimplifying or misunderstanding anything.
There should be one-- and preferably only one --obvious way to do it.
I think pip is probably a good option, I don't think anyone is going to be concerned about you not providing apt or yum packages, that's a job for distro maintainers. 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? Maintaining both seems like it would be a pain.
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? Maintaining both seems like it would be a pain.
Avoiding making monolithic packages like this is exactly why conda was invented. With conda you can pull OCCT from e.g. conda-forge and just use it as your dependency. I imagine some of the current users will be worried, because such a monolithic pip package will possibly break their env.
What do you mean by monolithic? You saying that we'd need to also make gmesh a package, and link against that?