Noooooooo This is a really terrible suggestion. The last thing we need is another way to do things, that only takes care of, say, 70% of the functionality. A

Noooooooo This is a really terrible suggestion. The last thing we need is another way to do things, that only takes care of, say, 70% of the functionality. All that will happen is, someone now has to look through the simple interface, and decide oh wait, I need one feature this doesn't provide. Now your "solution" has made the problem worse, not better. If you're going to provide this sort of simplified interface, you need to make damn sure a super majority of users never need to look past it. Otherwise you've done much more harm than good, by providing yet another competing alternative. The real problem with packaging in Python is that users are asked to write this program, setup.py, that by itself should not be a very difficult program to write. Its tasks simply are not that complicated. What makes it complicated is that they're then told that their program should consist of a single function call --- a call to this monstrously complicated setup() function, with a confusion of conflicting arguments. This is a stupid way to write a program! This design decision is at the heart of the whole problem. The interface to setuptools, distribute, distutils etc is fucked and always will be fucked, because there's no way to provide a good interface to the functionality via a single function call. That's why every semi-complicated setup script ends up having to monkey patch the internals of setuptools or distutils, to say, replace some of the Extension class machinery, or try to correct a compiler flag. It's because the design is fundamentally a failure. The whole idea does not work. Things would be much easier if we had direct, simple control. You can provide a default fall-through, but it should be easy to route the "build_ext", "install", "sdist" etc commands to your own function. Just tell us what our program needs to do and provide us a nice library of building blocks to do it, and we will write this program. Simple. By far the majority of my tickets for my NLP library, spaCy, are related to packaging and installation. Why should putting some files onto a user's computer and zipping up some files on my machine and calling out to a compiler and specifying some dependencies be harder than understanding natural language?