Message213443
> 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.) |
|
Date |
User |
Action |
Args |
2014-03-13 19:17:03 | eric.araujo | set | recipients:
+ eric.araujo, barry, ncoghlan, pitrou, tarek, Arfrever, piotr, Natalia, DLitz, samuel.lai |
2014-03-13 19:17:03 | eric.araujo | set | messageid: <1394738223.05.0.983248069504.issue14894@psf.upfronthosting.co.za> |
2014-03-13 19:17:03 | eric.araujo | link | issue14894 messages |
2014-03-13 19:17:02 | eric.araujo | create | |
|