Additional command line options via python -mbuild?

Python Help
1

I am now in the process of rewriting my setup.py build building to using python -mbuild (or python -mpip wheel) and I don’t how to push information from the command line to my setup.py. I have two additional options created via subclassing build_ext.build_ext (and build.build), which used to work perfectly well with Windows, where I need to let the build process know where OpenSSL libraries and header files live. Also, I need to support Python 3.6, so keeping my setuptools somewhere around 40.5.0 seems prudent.

However, whether I use --build-option, directly my options, or even the weird construct somebody promoted (which seems to work the best) --config-settings=--build-option=--bundledlls still the log doesn’t seem to show any value. See AppVeyor for an example.

Any ideas how to get the value there?

2

I think nowadays a common suggestion is to use environment variables instead of command line options. Something like:

MY_PROJECT_SETUP_PY_BUNDLE_DLLS=1 python -m build

And in the setup.py:

import os
import setuptools

BUNDLE_DLLS = os.getenv('MY_PROJECT_SETUP_PY_BUNDLE_DLLS')

# Do something with `BUNDLE_DLLS`

setuptools.setup(
    # ...
)

I have not had to deal with something like this personally so I will not risk providing possibly incorrect details. I am quite sure there have been a couple of similar questions on this forum before, maybe they can provide accurate details. Maybe these ones:

1 Like
3

That’s actually a great idea. Thank you.

4

An env-var solution is definitely exactly where we ended up in order to condition options for our TypeScript build (we had previously used command line flags)

5

I’m sure you saw it as you replied there, but for others’ benefit, this was one of the issues brought up in the recent User experience with porting off setup.py thread and the latter sections of the linked blog post. The general consensus there as well was in favor of environment variables.

Not sure if there’s something motivating supporting that specific version, but for reference:

  • Python 2.7 support was only dropped in Setuptools 45
  • Python 3.4 support dropped in Setuptools 44
  • Python 3.5 support dropped in Setuptools 51
  • Python 3.6 support dropped in 59.7.0.

And in terms of features and fixes:

  • Setuptools 40.8.0 is the minimum that properly supports PEP 517 (as it adds the build_meta:__legacy__ fallback backend)
  • 40.9.0 adds support for setup.cfg-only projects
  • 42.0.0 has more or less complete support for declarative metadata in setup.cfg
  • 43.0.0 adds pyproject.toml to the sdist by default
  • The intervening versions between 40.5.0 and 43 fix numerous PEP 517/pyproject build related bugs and issues

Therefore, using Setuptools 43.0.0 as a minimum has basic support for modern standards and workflows, while still fully supporting as early as Python 2.7 and 3.4. In fact, you could get all the way to 59.6.0 while still support Python 3.6 (though unfortunately that doesn’t quite get you pyproject metadata support).

1 Like