Éric Araujo <mer...@netwok.org> added the comment: There are different kind of files created by write_file:
- PKG-INFO (METADATA in distutil2), that already uses a trick to support Unicode, but your change would replace it in a better way; - MANIFEST, which with your fix would gain the ability to handle non-ASCII paths, which is a feature or a bugfix depending on your point of view; - .def files, used by the compilers for the C linking step; I don’t know if it’s appropriate to allow UTF-8 there. - RPM spec files, which use ASCII or UTF-8 according to http://en.opensuse.org/openSUSE:Specfile_guidelines#Specfile_Encoding but it’s not confirmed in http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html (linked from the LSB site), so there’s no guarantee this works for all RPM platforms. This sort of platform-specific thing is the reason why RPM support has been removed in distutils2. - record and .pth files created by the install command. I agree that there is something to be fixed, but I don’t know if they can be fixed in distutils. Unicode in PKG-INFO is unrelated to files, whereas there are files or directories in MANIFEST, spec, record and .pth. If this is going to be fixed, write_file should not use UTF-8 unconditionally but grow a keyword argument IMO, so that use cases requiring ASCII continue to work. When you say “patch *all* functions reading files”, I guess you mean all functions that read distutils files, i.e. MANIFEST and PKG-INFO. Tarek, is this a bug fix or a feature? Could it break third-party tools? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9561> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com