Q: how to bootstrap whey?

[kloczek]

Hi,

Looks like it is some chicken and egg issue with building from scratch whey.
It is possiblet obuild whey however to install it you need dom-toml, domdf-python-tools, consolekit and shippinglabel and all those modules needs whey to build.

How can I boostrap whey?

[domdfcoding]

Hi @kloczek, sorry about that. I didn't intend to use whey as the build backend for any of its dependencies but must have forgotten that at some point. I have updated the dependencies to use a different build backend so there shouldn't be any issues building whey from source now.

Let me know if you're still having issues.

[kloczek]

As nothing has changed in code of any of those modules which I've listed still I cannot boostrap whey and all necessary modules.
FYI I'm building ~90% of all my rpm packages with python modules from VCS tart balls (most of the sdist archive have missing documentation or test suites).

If you know how to build some exact modules without whey (from source code trees) using alternative pep517 backends please let me know.

[kloczek]

I'm in the middle of moving all my python packages (+12.4k) from python 3.8 to 3.9 and found another loop in build dependencies.

It is possible to build whey because it uses setuptools as pep517 build backend and there is no any problems with building dom-toml, natsort. Strange thing is that whey has on its install time dependencies setuptools which is a bit odd.

I've stumped on issue with build/install dependencies of coincidence.
This module to build needs shippinglabel. There is no problem with building this module however it has install-time dependency. It depends on apeye which is possible to build as well without any issues. Now generated apeye needs apeye-core.
To build apeye-core I must have already build hatch-requirements-txt. To build hatch-requirements-txt I must have build already coincidence.
Any advise what I cam do? 🤔

BTW I think that modules like sphinx-pyproject, shippinglabel and whey-pth and probably few other should be integrated into whey directly forming kind of single module tool belt.
All because fragmentation in tis case creates almost instantly build/install dependencies loop(s).

[kloczek]

No advice? 🤔

[kloczek]

I think that I found kind of solution for how to solve build dependencies loop.
Looks like biggest knot in that loop is around hatch-requirements-txt modules.
Using special and external module to load list from file seems is like a bit to big stone to kill that bird.
If whey would be able to do something which setuptools is able to do with:

[build-system]
requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "myproject"
version = "0.1.0dev1"
dynamic = ["dependencies"]

[tool.setuptools.dynamic]
dependencies = { file = ["./requirements.txt"] }

that would solve issue with build dependencies.

Comments? 🤔

[kloczek]

Other thing is that separating those dependencies in file seems is another layer of slight overkill.
I think that for myself I'll try to move content of the requirements.txt files straight into pyproject.toml.
It could make sense to separate those dependencies if they would be generated dynamically or processed by something external however looks like it is not the case.