Distribution Package with two Import Packages: Install only one Import Package

[buhtz]

I have a Distribution Package named bit_demo containing the two Import Packages bitcli and bitgui.

bit_demo
├── pyproject.toml
├── src
│   ├── bitcli
│   │   ├── __init__.py
│   │   └── __main__.py
│   └── bitgui
│       ├── __init__.py
│       └── __main__.py
└── tests
    ├── integration
    └── unit

When I install it via python3 -m pip install bit_demo I do have the two import packages in my system.

Would it be possible to install bit_demo but only with bitcli?
Can I install a distribution package excluding some of its import packages?

For example

python3 -m pip install bit_demo.bitcli

python3 -m pip install bit_demo  --exclude bit_demo.bitgui

Background of my question

I think about the distro maintainers (e.g. Debian, Arch) who need to create a deb file of my upstream repo.
There need to be two packages in the distro. When users only want to use the CLI interface without GUI (e.g. on a headless server) they would do apt install bitcli. But when they need it with GUI they would do apt install bitgui (and bitlic comes in as dependency).

Technically bitcli can live alone. But bitgui is useless alone because it use a lot of bitcli code. Because of that I don't think it would be a good idea to create two separate git repositories. I would prefer to keep them together as one repo/distribution package.

[webknjaz]

No, it's not possible out of the box. Maybe, you could implement a way to only include/exclude the gui one in the wheel conditionally, like through an in-tree PEP 517 back-end and config_settings but I doubt this will facilitate the downstream packages. FWIW the downstreams usually patch out what they need on their side and you should really focus on including everything necessary in the sdist which is what downstreams often use as the source (unless it's incomplete and they have to resort to using Git).

But if you do foresee a CLI-only app being useful, then maybe the PyPI users would feel the same. In this case, I'd recommend splitting that into two dists, one depending on the other. Don't reinvent the wheel. (pun intended)

[buhtz]

Thank you very much for your feedback.

Splitting into two dist/repositories is the last option I need to discuss this in the maintainer team.

But your PEP517 sounds like a possible solution to my problem. But I lack of background understanding about build-frontend/-backends etc to understand all of PEP517 and transform it into a practical solution.

I update my initial posting with the link to my demonstrator project where I could test things like this.

[buhtz]

Looking into the docu of pip I also couldn't find an option to make pip use of an alternative toml file instead of pyproject.toml. "Nice" idea of mine. 😆

As more as I think about it I become warm with the idea to skip the 1-distro-with-2-import-packages-approach and just make two distro-packages.

Maybe I can keep two distro-packages in one git repo?

bit_demo
├── bitcli
│   ├── pyproject.toml
│   ├── src
│   │   └── bitcli
│   │       └── __init__.py
│   └── tests
├── bitgui
│   ├── pyproject.toml
│   ├── src
│   │   └── bitgui
│   │       └── __init__.py
│   └── tests
└── README.md

Technically it seems possible but isn't it wired/hacky? Ever seen a project structure like this?

[abravalheri]

Looks to me like a standard Python monorepo. I would not say it is hacky...

You might want to add a README.md into each package folder to serve as a description text in PyPI (I believe that most build tools will not allow you to reach out to a parent directory for security reasons, e.g. readme = "../README.md" is not allowed).