On 23 October 2015 at 23:12, Nick Coghlan
The core problem is that the status quo is merely clumsy and inelegant, rather than completely unusable. For all their flaws, both hobbyists and professional developers *can* use the current tools to distribute software (and they're still easier to deal with than writing directly for the native installer toolsets on each target platform), while in any organisation that uses Python heavily, setup scripts for new projects are likely to be either generated from templates or copied from those for old projects, rather than needing to be written from scratch each time.
And now that I've got my "Mr grumpy pants" reaction to the earlier parts of the thread out of my system (sorry about that), I'd like to revisit Chris's idea of having a *simple* replacement for setuptools as a build system. In particular, what if there was a build system aimed specifically at beginners that, at least initially, *only* supported the creation of sdist's and wheels for pure Python source publication (no "install" or "upload" commands), without support for binary extensions, and defaulted to publishing everything in the current directory and below, while relying on twine to actually do the uploads to PyPI? Folks dealing with C extensions (including via cffi or Cython), using pkg_resources for plugins, installing command line wrappers, or otherwise doing something more than publishing a pure Python library would still need to "graduate" to dealing with the complexities of setuptools or one of its competitors, but we could potentially get it out of the initial learning curve for students publishing list-of-list printers :) One particularly nice aspect of that is anyone interested in working on it could potentially pitch it to the PSF's Education Working Group as a project worth investigating as part of the Education bundle. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia