On: TOML: Tom's Obvious Minimal Language

[jborean93]

Can you share an actual example where you need to specify requirements twice. With pyproject.toml I know of 3 ways requirements are specified and they are all used by different things:

1. Build requirements - requirements needed to build your package from an sdist

2. Runtime requirements - requirements your library needs at runtime

3. Extra requirements - optional runtime requirements

For example my library pyspnego https://github.com/jborean93/pyspnego/blob/main/pyproject.to... has all 3:

1. Cython for Win32 needed to build the sdist and setuptools as the general build system - https://github.com/jborean93/pyspnego/blob/c3db058b636fc102f...

2. cryptography as a runtime dependency - https://github.com/jborean93/pyspnego/blob/c3db058b636fc102f...

3. optional extras kerberos and yaml - https://github.com/jborean93/pyspnego/blob/c3db058b636fc102f...

Granted the toml format and what is used in pyproject.toml has its warts but I'm curious what your joke and clown_fiesta examples are actually from as from where I am standing each section currently serve different purposes.

[crabbone → jborean93]

Even in your list, there's a problem. I'll describe it first, and then will get to the one I had in mind when I gave my example.

It's common that your build requirements and your runtime requirements have a big overlap that has to iterate together. Here's a realistic example: NumPy comes with various build helpers that you need at build time, if you are making a native module. So, you need to depend on a particular version of NumPy both during the build and at runtime.

In other words, you would want to be able to reference the same package + version in two places.

You could say that this is a problem with "specific" package, where the developers didn't care to separate two kinds of requirements... and in some sense you are right... but: there is a value to having build helpers and the rest of the runtime code in the same package. It's simpler. It prevents those using your package from accidentally messing up.

Finally, it's NumPy we are talking about, it's not a "specific" package... it's like 50% of the entire Python ecosystem.

---

Now, to what I mean in my example.

This is taken verbatim from "real Python" site for the lack of a better example:

    # pyproject.toml
    
    [tool.poetry]
    name = "rp-poetry"
    version = "0.1.0"
    description = ""
    authors = ["Philipp <philipp@realpython.com>"]
    
    [tool.poetry.dependencies]
    python = "^3.9"
    
    [tool.poetry.dev-dependencies]
    pytest = "^5.2"
    
    
    [build-system]
    requires = ["poetry-core>=1.0.0"]
    
    build-backend = "poetry.core.masonry.api"

See how "python = ^3.9" is a dependency of Poetry? But what if I also want to make my project build with setuptools? Setuptools also depends on Python... where would I put that now? Not under [tool.setuptools.dependencies]? What do you think?