poetry inclusion demo

.gitigore

src/dlls
venv
.idea
*.egg-info
poetry.lock
dist

pyproject.toml

[tool.poetry]
name = "poetry_demo"
version = "0.1.0"
description = ""
authors = ["Arne <[email protected]>"]
license = "MIT"

include = ["src/dlls/*"]  # if this line is omitted, wheel and source distribution won't include the "ddls"

[tool.poetry.dependencies]
python = "^3.8"

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

src..dlls..a.dll

"I am a binary file"
001010111010101
001010100001011
111011101110001

src..poetry_demo..__init__.py

from importlib import metadata

__version__ = metadata.version("ultimate")

filenames in gists can't include slashes, so double-dots denote going down the folder hierarchy. Or, as a tree:

$ tree .
poetry_demo
├───src
│   ├───dlls
│   │   └───a.dll
│   └───poetry_demo
│       └──__init__.py
├───.gitignore
└───pyproject.toml

If both poetry and python3.8 are present on the system, the following should set up the project and build two distributions, one wheel and one source, which both include a.dll despite it not being part of the source tree and in the .gitignore:

$ git init  # might not be necessary, I tested it only with git set up
$ poetry install

Updating dependencies
Resolving dependencies...

Writing lock file

No dependencies to install or update

  - Installing poetry_demo (0.1.0)

$ poetry build
Building poetry_demo (0.1.0)
 - Building sdist
 - Built poetry_demo-0.1.0.tar.gz

 - Building wheel
 - Built poetry_demo-0.1.0-py3-none-any.whl

Open either with an un-zipper to check if the a.dll is in there. If you remove the include specification from the pyproject.toml and rerun the build, a.dll should not be part of the packages any more.

Just as a side note, it is a bad idea to have non-code files such as binaries or configurations not under the source tree, it makes finding them after installation unnecessarily tough. If you can, always put them next to the package's code. The only exception are things like README or CHANGELOG, which are more along the lines of package metadata and not something you'd want to refer to during runtime.