Hi David, I have to agree with you on every point.
On Sat, 07 Nov 2009 16:49:12 +0900, David Cournapeau <da...@ar.media.kyoto-u.ac.jp> wrote: > Contrary to other people, I don't think a successor to distutils is that > hard to develop, especially since good designs in other languages > already exist. It would take time, especially to get a transition story > right, but I think it would be worthwhile. That's just so controversial.. But since Guido has asked, lets just have some good old fashioned pragmatic software engineering discussion. Let's toss it around as pure numbers (for what you are suggesting): - how many lines of code would it take ? (500, 5000, 10000, 20000) ? - how much of the existing library could be used ? (10%, 25%, 50%,75%, 90%) ? - how many months would it take ? (3,6,9,12,18,36,72) ? - how many people would it require ? (1,2,3,5,10) ? - Could a PEP be started ? or co-author with somebody else ? Are there existing PEPs? Would a PEP for this have any chance of success? Could Tarek help with a PEP ? He must have some ideas on this.. - What's the risk ? I'd suggest we not call it a distutils replacement system. Lets call it a stripped down simplified package builder. To me, it's either the existing code from distutils that builds what we call a source package. Or it's a new piece of code that builds a 'standard' python package. The end result needs to be oriented to a non-technical audience - so we need to keep it pretty simple - not too many options. >From my current understanding, the keys files in any python package seem to be sources.txt and PKG_INFO. So it could be possible, imo, to prompt for metadata on the console, write it to a PKG_INFO, scan for files and write the sources.txt, and then archive the whole lot up using the standard library. That's ultra simplistic... perphaps too much so. But imo it's worth doing estimations on. David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
