4 ms·

Thanks! Quoting it: > but the purpose of PEP 518 was to come up with a way for projects to specify what build tools they required ... Now a tool like pip can

by dalke 6y ago

Thanks! Quoting it: > but the purpose of PEP 518 was to come up with a way for projects to specify what build tools they required ... Now a tool like pip can read pyproject.toml, see what build tools are specified in it, and install those in a virtual environment to build your project Except, umm, I can't do that? Because I depend on a C compiler, and have optional dependencies on Python packages which aren't in PyPI. And I didn't see anything there about C extensions. I feel like the forgotten child. :( > editable installs Grr, now I have to figure out what an "editable install" means. EDIT: Oh, I see, I think. I work in the top-level directory with the project chemfp/ underneath and symlink to build/lib/_chemfp.so for the C extension, so I've not needed this.

BerislavLopac 6y ago
You are right, building native extensions seems to have been left behind with the whole move to configuration-based builds (using pyproject.toml, as opposed to the "script-based" builds, using setup.py). That said, the configuration format itself is supposed to be universal -- but apparently none of the current tools support building extensions. That means that you are stuck with distutils, which should be available as part of setuptools -- PEP632 offers some migration advice [0]. I'd also recommend asking for advice on the packaging discussion board [1]. EDIT: And there is also the PyPA's official packaging problems tracker, FWIW [2]. [0] https://www.python.org/dev/peps/pep-0632/#migration-advice https://www.python.org/dev/peps/pep-0632/#migration-advice [1] https://discuss.python.org/c/packaging/14 https://discuss.python.org/c/packaging/14 [2] https://github.com/pypa/packaging-problems https://github.com/pypa/packaging-problems
BerislavLopac 6y ago
> Because I depend on a C compiler But do you specify it in the Python build toolchain, e.g. setup.py? If I'm not mistaken, the binary compilation step happens independently, with the Python build packing everything up in a wheel. > and have optional dependencies on Python packages which aren't in PyPI. Such dependencies can still be declared in pyproject.toml, depending on the build tool - Poetry can add them by e.g. a local path, or git repo URL. I'm not sure what happens if you depend on them for the build itself, but it should be possible to add them to the build-system table in the TOML file. But pyproject.toml doesn't change anything compared to the current system; for backward compatibility, PEP 518 assumes this default file if a custom one is missing: [build-system] requires = ["setuptools", "wheel"] Which is enough to execute the standard setup.py. In any case, as per PEP 517, you can define your own custom packaging backend using the build-backend value in the [build-system] table.

by dalke 6y ago

BerislavLopac 6y ago

You are right, building native extensions seems to have been left behind with the whole move to configuration-based builds (using pyproject.toml, as opposed to the "script-based" builds, using setup.py). That said, the configuration format itself is supposed to be universal -- but apparently none of the current tools support building extensions. That means that you are stuck with distutils, which should be available as part of setuptools -- PEP632 offers some migration advice [0]. I'd also recommend asking for advice on the packaging discussion board [1]. EDIT: And there is also the PyPA's official packaging problems tracker, FWIW [2]. [0] https://www.python.org/dev/peps/pep-0632/#migration-advice https://www.python.org/dev/peps/pep-0632/#migration-advice [1] https://discuss.python.org/c/packaging/14 https://discuss.python.org/c/packaging/14 [2] https://github.com/pypa/packaging-problems https://github.com/pypa/packaging-problems

BerislavLopac 6y ago

> Because I depend on a C compiler But do you specify it in the Python build toolchain, e.g. setup.py? If I'm not mistaken, the binary compilation step happens independently, with the Python build packing everything up in a wheel. > and have optional dependencies on Python packages which aren't in PyPI. Such dependencies can still be declared in pyproject.toml, depending on the build tool - Poetry can add them by e.g. a local path, or git repo URL. I'm not sure what happens if you depend on them for the build itself, but it should be possible to add them to the build-system table in the TOML file. But pyproject.toml doesn't change anything compared to the current system; for backward compatibility, PEP 518 assumes this default file if a custom one is missing: [build-system] requires = ["setuptools", "wheel"] Which is enough to execute the standard setup.py. In any case, as per PEP 517, you can define your own custom packaging backend using the build-backend value in the [build-system] table.