Comments (9)
Hey all, sorry to dig up such an old issue, but I'm interested in being able to install openvdb's python bindings as a package from PYPI as well. I'd be happy to submit a PR with the packaging necessary to publish on PYPI, if the maintainers would accept it. I can also write the github workflows to automate building and publishing the releases. Would this be something the maintainers be okay with?
from openvdb.
Hi @peytondmurray - I think this would be great to see! I'm just not sure what exactly this looks like as I haven't worked too much with PYPI. My understanding is that you would be contributing a bunch of scripts to allow us to automate and test the publishing process of a PYPI package from within the OpenVDB repo? I see a number of pyopenvdb
packages already published by the community - do you see any issues with us publishing our own with the same name?
I'll speak to the other maintainers to confirm we'd be happy to support this.
from openvdb.
My understanding is that you would be contributing a bunch of scripts to allow us to automate and test the publishing process of a PYPI package from within the OpenVDB repo?
Yeah, that's right. Actually, I think there's a way to set up Github actions to automatically publish (not just test) a new version of pyopenvdb on PYPI whenever you make a new release. If we can get that working then the process of publishing to PYPI won't require any extra effort at all when it comes time to make new releases of OpenVDB.
I see a number of
pyopenvdb
packages already published by the community - do you see any issues with us publishing our own with the same name?
There are indeed issues with publishing our own with the same name, but I think the effort in overcoming them will be worth it. For reference, there are currently two separate projects on PYPI which show up if you search "pyopenvdb", but they're both really the same:
- pyopenvdb 0.1.4 is a project for building and packaging pyopenvdb in a docker container. There's a github page which has commits from January 2021, but no PYPI release has been made in 2 years.
- pyopenvdb-3.8 0.1.5 has a link to the same github page as the first result.
I'm guessing the author made both projects in the course of figuring out how to publish packages to PYPI (definitely done this myself before...). In any case, the rules governing PYPI package name transfers are clear: the first thing to do is just try to talk to the owner of the packages. There haven't been any releases on either of these projects in two years; if we email the author three times, and we don't get a response within six weeks, then the projects already meet all the requirements for being considered "abandoned." At that point I think we have a good case for transferring ownership of those PYPI packages to the official OpenVDB project maintainers.
Of course, all of that won't be necessary if we can get a hold of the owner of the projects. I hope they'll be willing to give up those projects, especially if we publish the officially supported python packages in their place.
I'll speak to the other maintainers to confirm we'd be happy to support this.
Thank you! I'd also be happy to contact the owner of the existing packages that we'd need to remove on behalf of the OpenVDB project to get the process started, but I'll leave the decision to do that up to you. Let me know how you'd like me to proceed.
from openvdb.
Hey @peytondmurray - sorry for the delayed reply. Thanks a lot for outlining the process, this all sounds good to me! I confirmed today with the other maintainers that it would be great to pursue this and we'd happily support your proposal of an automated/CI based system for building and publishing pyopenvdb
.
If you're still interested in looking at this please feel free to start the process and e-mail the author of those other published packages on our behalf. We have a public e-mail/lists [email protected]
which you can include us on (all messages available here https://lists.aswf.io/g/openvdb-dev/topics) but please let me know if you need anything else!
from openvdb.
Awesome, I'll get started on this. Thank you! π
from openvdb.
If you need any help I have lots of experience setting this type of thing up, hit me up! I'm also keen on getting my hands on openvdb in the python ecosystem. :)
from openvdb.
An update on progress so far, since I know some other people have expressed interest here:
- Contacted the current owner of the
pyopenvdb
package on PyPI (Alex). Alex was super nice, very responsive, and excited that there are other people interested in python packaging for OpenVDB. He agreed to transfer ownership of thepyopenvdb
package name to the OpenVDB maintainers, on the proviso that he is credited with writing the original packaging for the python bindings. I said that I thought that this would be fine - we can credit him in theREADME.md
for the python bindings or some other appropriate place (CONTRIBUTORS.md
or something, maybe?), as long as the maintainers agree - Fork the repo and started a new branch for python packaging development
- Add
README.md
explaining installation, dependencies, and build toolchain - Add
pyproject.toml
: specifies python build-time dependencies and options for builds
triggered by CI - Add
setup.py
, which makesopenvdb/openvdb/python
a python package that can be installed withpip
. I've configured it to usescikit-build
as a way of runningcmake
automatically during the build process, andsetuptools_scm
to set the appropriate package version string based on the current state of the git index - Set up github CI to build and publish an sdist for the package. I'm still in the process of testing this by uploading a package to https://test.pypi.org/legacy, but I think this is basically complete. I'm still trying to get wheels to build as part of the same CI pipeline, so I've left this unchecked for now
- Set up
cibuildwheel
to automatically build wheels for python 3.8, 3.9, and 3.10 with manylinux images. This is in progress, and a bit fiddly to get right. Unfortunately I think I'll have to build Boost 1.70 inside the container (which will be slow; there is a github action to do this, but it doesn't support Boost 1.70, our minimum version) before building OpenVDB. Only then will I be able to build pyopenvdb. If wheels are too much work to generate, we can always just distribute an sdist which should cover pretty much everyone's use case - the only advantage of distributing wheels is that they're smaller and faster to install.
Currently the github workflow on the fork is configured to trigger in two ways:
- By a release, in which case it will build wheels and a source distribution for the released tag before uploading to PyPI
- Manually, in which case the person who triggers the build can specify a git ref for the build
As it stands, you can go to my fork, go to the python directory and run pip install .
and it should build as long as you have the correct dependencies - including Boost, OpenVDB, CMake, and the python build dependencies specified in pyproject.toml
.
from openvdb.
Hello, Has there been an update on this? Very interested in being able to install OpenVDB bindings with pip
from openvdb.
No, sorry. I've been out of the loop and have passed off my previous work on this. Please see the associated PR for additional context.
from openvdb.
Related Issues (20)
- [BUILD] pyopenvdb install locatiion HOT 1
- [BUILD] Python bindings fail to build for version 3.11 HOT 3
- [BUILD] OpenVDB fails to build with LLVM 18 HOT 1
- [BUILD] OpenVDB fails to build HOT 1
- [REQUEST] Make it possible to have a subset of externally built libraries for Blosc in FindBlosc.cmake
- [BUG] Square/Planar Artifacts While Volume Rendering NVDB Files Using Optix HOT 1
- [BUG] include/openvdb/TypeList.h uses std::tuple_size_v that isn't defined in C++ standards HOT 6
- meshToVolume slowdown? HOT 1
- [REQUEST] Link against specific Boost libraries rather than Boost::headers and Boost::boost
- [BUG] NanoVDB NanoGrid returns incorrect voxel size when initialized from VDB with transform
- [BUG] NanoVDB math::ZeroCrossing with ray producing incorrect results HOT 1
- [BUG] Unable to load plugin: USD.plugin
- [BUG] Unable to run nanovdb on cuda
- [BUILD] Can't build on Windows 11 CMake 3.30
- [BUG] NanoVDB `GridHandler` error HOT 1
- Link broken HOT 1
- [BUG] NanoVDB Example : openvdb_to_nanovdb_cuda Unexpected Behaviour.
- How to maintain hollowness when constructing from a hollow meshοΌ[REQUEST]
- How does FVDB average pooling work? HOT 2
- [Question] How to use customized grid type with PNanoVDB?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openvdb.