apply markers from wheelhouse.txt during installation

[addyess]

Encountering a situation where charmtools pushes a package into the built charm (dataclasses) which can't be installed on focal or jammy because its not necessary.

I believed I could limit the install in the environment with wheelhouse.txt like this:

pydantic
dataclasses;python_version<='3.6' and python_version<'3.7'

but discovered that layer_basic ignores wheelhouse.txt completely

So, this PR gives some authority to the wheelhouse.txt to imply markers during the pkg install

[ajkavanagh]

Hi Adam (@addyess).

This is an interesting case. I pondered it over the weekend, and wanted to recap where layer-basic's design fits (fitted?) into the process of building charms, and what the original design of the wheelhouse.txt was.

So (my understanding of the) design is/was:

1. the wheelhouse.txt was a charm-build artefact to control which wheels were downloaded into the wheelhouse/ directory in the built charm.
2. the ultimate wheelhouse.txt is build from the lowest layer and is added to, modified, overridden by any wheelhouse.txt in any subsequent layer.
3. modules in the wheelhouse.txt can be pinned, and (interestingly) controlled by python_version depending on what version of the operating system the charm is being built on.
4. layer-basic installed everything in the wheelhouse/ directory.

In the OpenStack charms, we ran into largely the same problem that you have, and our response was to switch charm-tools to build binary charms. These are controlled by the --binary-wheels and --binary-wheels-from-source and (optionally) --use-python-from-snap options which, when working with charmcraft allow building binary charms for specific series.

Binary charms are thus (mostly) series specific, and are built in a lxd container of the same series. The wheels are binary wheels (i.e. have no build dependencies at all - which is very handy for, say, cryptography, which requires rust as a build-dep!), and thus install quickly.

Therefore, before merging this, I wonder if your use-case might be solved by building binary charms and having per-base charms in the charmhub?

[addyess]

I'm marking this as a draft PR due to it needing to re-considering mis-using the wheelhouse.txt which intends to direct charm build what goes INTO the source charm. Charmed-Kubernetes should really revise it's build process to consider binary wheel charms.

Perhaps there's an alternative file like requirements-install.txt that could be bundled with the charms to put series-like directives to respect during the install phase.