Best practices for separating build requirements and run requirements

Packaging
1

A little hunting didn’t turn up anything on this, though I recall reading something of the like recently that I now can’t find.

I’m working on a project that has no runtime dependencies, Python’s stdlib is sufficient. But to build the package, there are external requirements - most notably sphinx (and the cascade of things that come with it) and lxml for the relatively complex documentation build. Is there some accepted practice to separate the description of these? If the package-build requirements are dumped into requirements.txt, then various things make assumptions based on that being found in the github top directory - IDEs, automated scanning tools, etc. and I’m not really fond of that.

2

Not sure about “best” practice, but it’s common to see documentation-build requirements go in to dev-requirements.txt or docs-requirements.txt. For many of my projects I actually put them in the documentation directory itself, ie docs/requirements.txt.

For specifically build requirements, both setuptools and PEP 517 support this:

  • You can set setup_requires in your setup.cfg or setup call
  • You can add requirements to build-system > requires in pyproject.toml
3

I would not go the setup_requires way. It is deprecated, isn’t it?

Better look into using PEP517/PEP518/pyproject.toml, which allows to specify build-time requirements specifically:

4

Thanks - both of these help. (yes, it’s setuptools, fwiw). Will look into whether a further transition to pyproject.toml for this makes sense (I’ll have a maintainer to convince :slight_smile: ).