Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add example pyproject.toml using poetry instead of setuptools #1

Open
FedericoStra opened this issue Feb 9, 2022 · 4 comments
Open
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@FedericoStra
Copy link
Owner

Take inspiration from:

@FedericoStra FedericoStra added enhancement New feature or request help wanted Extra attention is needed labels Feb 9, 2022
@FedericoStra
Copy link
Owner Author

The state of the art best practices for packaging python modules with compiled extensions is just a desolate land of pain and suffering.

The crucial detail to defeat python-poetry/poetry#1516 appears to be to require setuptools and Cython in the build system defined in pyproject.toml:

[build-system]
requires = ["poetry-core>=1.0.0", "setuptools>=57.0.0", "Cython>=0.29.27"]
build-backend = "poetry.core.masonry.api"

@FedericoStra
Copy link
Owner Author

There is an initial implementation in the branch poetry. One of the downsides is that installing with pip install . leads to the following folder structure

cypack/
├── answer.c
├── answer.cpython-310-x86_64-linux-gnu.so
├── answer.pyx
├── data
│   └── zen.txt
├── fibonacci.c
├── fibonacci.cpython-310-x86_64-linux-gnu.so
├── fibonacci.pyx
├── __init__.py
├── __pycache__
│   └── __init__.cpython-310.pyc
├── sub
│   ├── helper.c
│   ├── helper.h
│   ├── helper.pxd
│   ├── __init__.py
│   ├── __pycache__
│   │   └── __init__.cpython-310.pyc
│   ├── wrong.c
│   ├── wrong.cpython-310-x86_64-linux-gnu.so
│   └── wrong.pyx
├── utils.c
├── utils.cpython-310-x86_64-linux-gnu.so
├── utils.pxd
└── utils.pyx

instead of the cleaner and intended

cypack/
├── answer.cpython-310-x86_64-linux-gnu.so
├── data
│   └── zen.txt
├── fibonacci.cpython-310-x86_64-linux-gnu.so
├── __init__.py
├── __pycache__
│   └── __init__.cpython-310.pyc
├── sub
│   ├── helper.h
│   ├── helper.pxd
│   ├── __init__.py
│   ├── __pycache__
│   │   └── __init__.cpython-310.pyc
│   └── wrong.cpython-310-x86_64-linux-gnu.so
├── utils.cpython-310-x86_64-linux-gnu.so
└── utils.pxd

@rnestler
Copy link

I found this issue via search. I'm trying to cytonize parts of a package and also face the problem, that the resulting package will include the original Python, the C-source and the compiled binary.

My target is, that the wheel only contains the compiled binary.

@surya-sigtech
Copy link

@rnestler Any update to the issue you were facing (i.e, the resulting wheel also includes the original Python code)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants