Éric Araujo added the comment: > Unfortunately, the current likely answer re updating vanilla distutils to > handle the new > standards is "we won't". The backwards compatibility issues involved are just > too hairy > for us to start enabling by default in the standard library, and I've become > convinced > that coupling the build and installation tools to the language version is > fundamentally a > mistake anyway (hence the bundling approach in PEP 453).
This makes sense. Given that distutils is still a basic packaging solution included in the stdlib, and no longer under a feature freeze, what kind of improvements do you think it can get? * Can we switch to SSL with certificate checking? I think it’s a big yes. * Can we improve the UI of some commands in a backward-compatible way? (Existing example: allowing the upload command to send an existing file, instead of requiring to build and upload in one command line) * Can we add new commands like upload_docs and test (that would just run unittest discovery)? It may be judged wasted time, if the whole world uses setuptools (but does it?). * Can we add support for wheel? Building extensions with the stable ABI? New version or metadata formats? > For this particularly case, I don't see any harm in bringing distutils in Py3 > back in > line with Py2, especially if it's also consistent with setuptools. It’s basically adding code to support comparison of mismatched types, i.e. time and effort to add something similar to a Python 2 design flaw. (setuptools’ version class is different from both distutils’ classes.) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14894> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
