2009/3/27 Guido van Rossum <gu...@python.org>: > - keep distutils, but start deprecating certain higher-level > functionality in it (e.g. bdist_rpm) > - don't try to provide higher-level functionality in the stdlib, but > instead let third party tools built on top of these core APIs compete
Please don't move bdist_wininst out of the core, though! I'd argue that Windows is a special case, as many Windows users don't have the ability to build their own extensions, so they rely heavily on binary installers. And there's no "Windows packagers" organisation to produce such things in the way that Linux has people building debs, rpms, etc. Making it as easy as possible for a random developer to build a Windows installer (by including bdist_wininst or equivalent in the core) is therefore significantly more beneficial than doing the same for a Linux/Mac/Solaris/... installer (Mac users or anyone else speak up here if I'm misrepresenting you!) >From what I understand of the issues, the problems with bdist_rpm/deb/etc have always been the need to conform to externally defined standards such as the Linux filesystem policy, or Debian's policies. As Windows has no such policies (or any that do exist are routinely ignored :-)) there is no pressure to "fix" bdist_wininst as policies change. Sorry if this was discussed at the session already. Paul. PS I'm using bdist_wininst as an example here. If someone were to come up with an alternative (core) means of building Windows installers for Python packages (maybe based on a common binary format such as eggs) that would be equally good. It's having no way in the core of building Windows installers that I'm arguing against. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
