[pganssle]

Sorry, I could have been more clear there, and I've updated the post. I have the "curse of knowledge" and took is as assumed that you can only do this if your particular build configuration fits in setup.cfg. For me, the fact that you have the option to use a setup.py is one of the biggest selling points of setuptools. For other build backends, it's common to have a great experience when you are on the "happy path" and then have no options when you have any of a million exceedingly rare deviations. So if I had a complicated build like you have (and I do have some mildly complicated builds where this is the case), I'd look at that bullet point and think, "Ah, that doesn't apply to this, but it's good to know for my simpler projects".

That said, it would be really nice if at least the C-extension part of this worked with the declarative format. My OSS time has been severely curtailed lately and I'm spread way too thin, so I probably won't be able to execute on this, but my long term vision for setuptools has always been that most common build configurations should be achievable using declarative config only, and everything else has setup.py as an escape hatch. This is similar to the way almost all Rust projects are configured with Cargo.toml, but in rare cases you can use build.rs to execute some Rust code as part of the build.

[eesmith]

The thing is, I don't think I have an option to use anything other than setup.py. For example, I read:

> and as part of the deprecation of distutils, having setuptools installed at all even when you don't import it can change the behavior of import distutils.

How am I supposed to replace the following (a modified version of https://stackoverflow.com/questions/724664/python-distutils-... ):

  from setuptools import Extension, setup
  from distutils.command.build_ext import build_ext

  copt =  {'msvc': ['/openmp', '/Ox', '/fp:fast','/favor:INTEL64','/Og']  ,
     'mingw32' : ['-fopenmp','-O3','-ffast-math','-march=native']       }
  lopt =  {'mingw32' : ['-fopenmp'] }

  class build_ext_subclass( build_ext ):
      def build_extensions(self):
          c = self.compiler.compiler_type
          if copt.has_key(c):
             for e in self.extensions:
                 e.extra_compile_args = copt[ c ]
          if lopt.has_key(c):
              for e in self.extensions:
                  e.extra_link_args = lopt[ c ]
          build_ext.build_extensions(self)

If distutils is deprecated, and setuptools causes problems ... what should I do?

I know setuptools is a "hot mess". It took hours of puzzling to figure out how to compile things correctly, and includes input from other people who spent hours puzzling things out.

So I am ... sad isn't quite right. Depressed? Down? Feeling like and outsider? .. every time I am reminded that I am not one of the "most people" in "works for most people".

While I (and you) are here, is some way to distinguish between "developer" build environments and "deployment" build environments?

I was looking more at the general topic, trying to figure out how to migrate. I saw this example:

  [build-system]
  requires = ["setuptools >= 40.6.0", "wheel"]
  build-backend = "setuptools.build_meta"

I have two build environments. A development build environment requires Cython (I have hand-written Python/C extensions and Cython extensions). On the other hand, source distributions include the "cythonized" C code from Cython, so people who install and deploy from source don't need Cython. [1]

In my setup.py I say:

  try:
    from Cython.Build import cythonize
  except ImportError:
    def cythonize(x):
        return x
    def rename(filename):
        return filename.replace(".pyx", ".c")

  else:
    def rename(filename):
        return filename
   ...
     = cythonize([Extension("spam", sources = [rename("foo.pyx"), "bar.c"])])

Is there a way to distinguish these two environments in pyproject.toml?

[1] Other than 'setuptools' and the need for a C compiler, my package has no dependencies when building from a source distribution.

EDIT: P.S. A reason to stick with "python setup.py develop" instead of "pip install -e ." is to avoid that frequent nag to "consider upgrading" pip. ;)