Aahz wrote: > On Mon, Oct 16, 2006, "Martin v. L?wis" wrote: >> Greg Ewing schrieb: >>> Unless the basic structure is so far from what's needed that it can't >>> be reasonably fixed. >> See, and I believe this isn't the case for distutils. > > Can you suggest a good mechanism for resolving the deadlock? We have the > primary maintainer (and some other users) claiming that distutils is a > mess that needs rewriting. You think it doesn't, but based on other > comments you've made, I believe you don't have available time. I haven't > seen anyone else agreeing with you.
One thing that I think would be helpful is if there were a requirements doc for distutils. Any attempt to refactor distutils is going to fail IMHO, unless the person doing the refactoring knows exactly what it needs to accomplish, and as we all know, its not always possible to infer from an existing system (even a documented one) what its *supposed* to do, as opposed to what it actually does now. I know that in my case, I have a hard enough time even understanding the existing distutils docs - if I were to foolishly attempt to create a replacement, what would happen is that I would end up solving my specific problems and no one else's. I would suggest perhaps a wiki page or discussion devoted to collecting requirements and use cases for a new distutils. This should incorporate not only the existing distutils requirements, but should also incorporate lessons from the creation of setuptools, and an awareness of what's going on in the refactoring of the import machinery. One thing to discuss would be how to handle backwards compatibility; I see three alternatives: (1) Make the APIs of the new system match the old one, (2) Make a "compatibility module" that plugs in to the new system, allowing development of a new API while maintaining the existing one, and (3) leave the existing distutils system in place, but deprecated in favor of the new one. If the new system is enough better than the previous one, I don't see that there will be a huge problem getting people to migrate over, as long as the new system supports older versions of Python as well as Py3k. Given that many distutils scripts are generated from boilerplate or templates, automatic conversion may also be possible. Once the requirements are in place and there is rough consensus on what the tool actually needs to do, we can start generating PEPs that attempt to meet those requirements. -- Talin _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
