Repository navigation
Build recipe for the project #169
Description
✅ Code of conduct checklist
- 🌱 I am using the latest version of the code.
- 📙 I thoroughly went through the README, but could not find the feature I need there.
- 📘 I thoroughly went through the tutorial slides, notebook, and video, but could not find the feature I need there.
- 📗 I thoroughly went through the documentation, but could not find the feature I need there.
- 📜 I went through the docstrings and comments in the source code parts relevant to my problem, but could not find the feature I need there.
- 👩🔧 I searched for similar issues, but could not find the feature I need there.
- ⭐ Since I am showing interest in the project, I took the time to give the repo a ⭐ to show support. Please do, it means a lot to us !
🚀 The feature, motivation and pitch
Installing the project with a simple pip install command would be ideal. Besides, having such build recipe would allow proper automatic CI and CD, which are currently lacking. Ideally, we would have a single pyproject.toml file to cover our needs, combined with a setup.py if using setuptools.
🔀 Alternatives
For now, the reliance on the install.sh script works, but is not ideal. In particular:
FRNNis not pip-installable and requires the execution of a shell script to compile. If this is too much of an issue, we should move away fromFRNNin favor of other radius-NN tools, even if at the expense of a little bit of performance. This would however require a bit of benchmarkingpgeoffails to install properly in a conda environment without an explicit call to a conda-install command (see Install script makes seemingly incorrect assumptions about PGEOF's environment #102)parallel_cut_pursuitandgrid_graphrequire the execution of a python script for compilation
Any attempt to improve the project's installation would need to address these 3 points.
📚 Additional context
No response
Activity
drprojects commentedon Nov 8, 2024
@rjanvier I saw your post sk-build-core issue tracker still did not get any reply. Have you maybe found a workaround for installing
pgeoffrom inside a conda env ? I am starting to look into options for doing proper testing and automated building for superpoint transformer. From my current understanding, the fact that installingpgeofin an environment requires a conda-install call is preventing any pip-only build recipe for the superpoint transformer, correct ?The second limitation I see is the fact that several dependencies currently need to be compiled with shell or python scripts. Not entirely sure how to work around this with a
pyproject.tomlapproach.Any suggestions would be welcome !
gvoysey commentedon Nov 11, 2024
I install all of superpoint transformer with pip; we don't use anaconda at all.
drprojects commentedon Nov 11, 2024
@gvoysey thanks for your reply !
How do you proceed for FRNN installation ? Did you move away from this dependency ? How about the cut-pursuit and grid-graph dependencies ? Did you manage to port the script parts of ìnstall.sh
into asetup.py` managed by setuptools ?gvoysey commentedon Nov 12, 2024
we vendored and packaged all the dependencies -- frnn, prefix-sum, grid-graph, pycut-pursuit, and pgeof are all pip installable.
Installation is managed from a
pyproject.toml, per PEP 517/518. I don't see any utility in new/fancy build backends, so we're using setuptools.drprojects commentedon Nov 12, 2024
Would be quite interested in how you packaged all the dependencies these, in particular FRNN and prefix-sum (all the other dependencies are no on PyPi thanks to @rjanvier). I am fairly new to python project packaging, would you mind sharing how you configured this ?
gvoysey commentedon Nov 12, 2024
I'll see what i can do to get you a PR for the dependencies, as well as spt itself. it'll save my fork some churn if i do the helping, heh. 😇
drprojects commentedon Nov 12, 2024
Don't worry about making a super clean PR ! Basically if you share your recipe for compiling FRNN with setuptools, ruled from a
pyproject.toml/setup.py/requirements.txt, that would be awesome. Unless essential for the packaging, I do not need to know how you reorganizedsrc/to be honest. Then I can capitalize on this 😉gvoysey commentedon Nov 12, 2024
It is essential for the packaging, sadly. I'm happy to do it on the grounds that it improves my ability to stay in step with your upstream remote, which is significant for our team.
i'd like to include some convenience tooling for autoformatting (your template correctly uses pre-commit but i don't think you've run it) and a stab at CI/CD with
nox-- probably as two additional PRs.happy to talk offline about a strategy for this, if you like.
SjoerdAlliander commentedon Aug 29, 2025
Hi! adding to this, I would be quite interested in the .toml as well. This would help adding the project as a packaged dependency to my project.
drprojects commentedon Sep 1, 2025
Hi @SjoerdAlliander this is still on our radar, @rjanvier has worked a possible formulation, but I have not fully tested it yet. FYI we may be able to install from source code with something like
pip install .but it is unlikely that we will be able to distribute he project as a precompiled wheel because of other dependencies such astorch-geometricandFRNN.SjoerdAlliander commentedon Sep 1, 2025
Thanks for the reply!
And what about gvoysey's option to create a pyproject.toml and maybe linking/building specific dependencies in there? Then at least the git repo can be pulled locally and used as a dependency as poetry recognizes the .toml.