I've been working on a prototype Python packaging system powered by SCons called enscons. https://bitbucket.org/dholth/enscons . It is designed to be an easier way to experiment with packaging compared to hacking on distutils or setuptools which are notoriously difficult to extend. Now it is at the very earliest state where it might be interesting to others who are less familiar with the details of pip and Python package formats. Enscons is able to create wheels and source distributions that can be installed by pip. Source distributions built with enscons use pyproject.toml from PEP 518 ( https://www.python.org/dev/peps/pep-0518/ ) to install enscons before setup.py is run, and since pip does not yet implement PEP 518, include a setup.py shim for PEP 518. The same pyproject.toml includes most of the arguments normally passed to setuptools.setup(), which are used to create the metadata files needed by pip. Enscons converts pip's setup.py arguments to SCons ones and then invokes SCons, and the project's SConstruct does the rest. For a normal from-pypi installation, enscons generates just enough egg_info to let pip build a wheel, then pip builds and installs the wheel which has more complete metadata. Of course SCons is more interesting for more complicated projects. I've been working on building my pysdl2-cffi binding with SCons. It includes a custom Python code generation step that distutils knew nothing about. It's practically a one-liner to add my custom build step to SCons, and it knows how to rebuild each part of the project only when its dependencies have changed. I don't know how to do that with setuptools. It is still a very early prototype. Don't expect it to be very good. Here are some of its limitations: - There is no error checking. - The sdists can only be built inside virtualenvs; otherwise pip complains that --user and --target cannot be used together. - It also doesn't work if one of the pyproject.toml build requirements conflicts with something that's already installed. - 'pip install .' doesn't work; it still tries to invoke 'setup.py install', which is not implemented. - 'setup.py develop' is not implemented. Try PYTHONPATH. - I am not an experienced SCons user. It also relies on what I'm sure will be a short-lived repackaging of SCons called 'import_scons' that makes 'python -m SCons' work, and includes a Python 3 version of SCons from github.com/timj/scons that seems to work well enough for my purposes. On the plus side, it's short. If you're interested in implementing Python packaging in SCons, or are interested in the straightforward but tedious task of copying just enough distutils trickery to implement a robust Python C extension compiler in SCons, then perhaps you should check out enscons. Here is a SConstruct for enscons itself: import pytoml as tomlimport ensconsmetadata = dict(toml.load(open('pyproject.toml')))['tool']['enscons'] env = Environment(tools=['default', 'packaging', enscons.generate], PACKAGE_METADATA=metadata, WHEEL_TAG='py2.py3-none-any', ROOT_IS_PURELIB=True)py_source = Glob('enscons/*.py') sdist = env.Package( NAME=env['PACKAGE_NAME'], VERSION=env['PACKAGE_METADATA']['version'], PACKAGETYPE='src_zip', target=['dist/' + env['PACKAGE_NAME'] + '-' + env['PACKAGE_VERSION']], source=FindSourceFiles() + ['PKG-INFO', 'setup.py'], ) env.NoClean(sdist) env.Alias('sdist', sdist)env.Whl('purelib', py_source, root='.') Thanks!