Support for pyproject.toml in Pip 10

[henryiii]

Pip 10.0.0b1 was released, with support for pyproject.toml. This allows a project to specify that it needs scikit-build in the setup phase, allowing for the first time a simple "pip install package" for a scikit-build package. pyproject.tomls should be added to the examples in tests and documentation.

On a related note, cmake could be added as a dependency as well, but since a user may have cmake, that's probably better in setup_requires or maybe not at all. If scikit-build could gain a new require_cmake_version argument, which would then check for the cmake command and ask it's version, then add the python 'cmake' as a requirement if this does not pass, that might be ideal.

[henryiii]

By the way, https://github.com/henryiii/skbuild-hello-cpp/blob/master/pyproject.toml is an example of such a file.

[jcfr]

xref #313

[jcfr]

The basic usage section has been updated accordingly.

See http://scikit-build.readthedocs.io/en/latest/usage.html#example-of-setup-py-cmakelists-txt-and-pyproject-toml

[thewtex]

@jcfr we can close this?

[jcfr]

Not yet:

• add test using pyproject.toml

[stefansjs]

FYI there's a relationship between build-system.requires and setup_requires that's a little less than obvious. For PEP517 builds I noticed that I needed to already have my dependencies installed by declaring them in pyproject.toml, and then setuptools will fail if the setup_requires criteria don't already match the environment.

More specifically, yes you need cmake in build-system.requires. Here's an example of my pyproject.toml and the relevant chunk of setup.py:

[build-system]
requires = [
    "setuptools>=50.0",
    "wheel",
    "scikit-build",
    "cmake==3.14.4",
    "Cython==0.25.1; python_version>='2.7' and python_version<='3.6'",
    "Cython==0.29.19; python_version>='3.7'",
    "cysignals==1.6.5",
    "pycodestyle==2.5.0"  # This is required in order to install avro-python3
]

        setup_requires=[
            'scikit-build',
            'cmake==3.14.4',
            # I tried specifying cython versions with environment markers, but setuptools doesn't respect them.
            # Relying on pyproject.toml to correctly install the right cython for the right python interpreter
            "Cython>=0.25.1",  # This version doesn't work on 3.7+
            "Cython<=0.29.19",
            'cysignals==1.6.5',
            'pycodestyle==2.5.0',  # This is required in order to install avro-python3
        ],

(I had issues with cython). It was interesting that I could use all the environment markers in pyproject.toml, but setup.py just needed me to list the same requirement multiple times.

Just wanted to share my experience so that others don't go through the same painful process I did to figure it out.

[henryiii]

setup_requires is problematic and if you can avoid supporting non PEP 517 builds, you can just delete it, it's deprecated and doesn't really work the way you think. Specifically, if you have something in setup_requires, it only gets downloaded, not installed, so you have to list it in install_requires, even if you don't need it for the installed package (like Cython). It also causes a double pass through the setup.py, and only the second time will you have the contents of setup_requires. The only reason to keep setup_requires is to support non-PEP 517 builds. If you do list both, it might certainly require they match, since I'm not sure it will do the download step if it's already in the PEP 517 environment.

Also, just in case, always list your build backend if you use build-system! The default one is the somewhat broken setuptools __legacy__ builder. See https://scikit-hep.org/developer/packaging#pep-517518-support-high-priority.

[stefansjs]

Oh thanks for the feedback. Those are some good pointers I didn't know.

I have never seen setup_requires install any dependencies. It's a catch-22 that's solved by pep517. You can't successfully run setup.py without having those things installed, which only works if you have some way to declaratively install those dependencies.

That said, I've found that it is useful to fail if the wrong dependencies are installed. In my case cython will produce a binary that doesn't work but which doesn't fail until runtime. Hence failing at build time is an advantage in my case.