Here’s a review of your proposal. You can reply to specific issues in comments of the GSoC site or amend your wiki page to address my comments.
- Since 'Packaging' is made after many improvisations and modifications over distutils2, it will prove to be a better utility than the currently existing distutils2 for all the versions of python.
This is a slight misunderstanding: packaging == distutils2. The current status of the merge of packaging can be confused, since new contributors are working on it in new repos, and some feature work has been mixed with the 3.x porting, but in general packaging does not have many improvisations over d2. packaging is the name of the new distutils in the 3.3 stdlib, distutils2 is the name of the same thing as a standalone release.
- The tutorial provided will help in the further development of the project.
That’s a good point in your application: tooling, documentation and blog posts should be helpful to other projects doing 3to2 conversions.
- - Applying 3to2 to 'Packaging' for all the versions of python2.
What about 3.1, which does not have all the features that packaging uses in 3.3?
- - Fixing 'type' issues corresponding to bytes and string.
How? Manual fixes, librefactor fixers, magic comments used with a special fixer, runtime checks (which can be broken by 3to2)?
- - Fixing import errors wherever required.
2to3 fixes imports, 3to2 probably does too, it’s one of the basic and easy things.
- - Few basic modifications in the code to make it compatible with other versions of python.
Precisely?
- Adding and rewriting few tests for the newly made changes.
Why is there a special line for tests? Are they handled differently than the rest of the code?
Also, what about docs?
- Ensure that build and installation process go well for all the versions of python i.e. 2.4 - 3.2
How? You’re not supposed to have everything figured out before GSoC starts, but you have to have a general idea.
- Initial preparations includes the following:
How far are you on those steps? You should also read docs.python.org/devguide
I find your timeline unsatisfying. It’s rather vague, and your approach of ad-hoc fixing of modules does not look sustainable. What we want is a robust, repeatable way of making releases out of the stdlib. Your list of deliverables is incomplete: first, it’s vague (“'Packaging' compatible with 2.4-3.2” should be “sdists of distutils2 for each supported version”), second, it shows that the approach you have chosen is “convert once, document, hope it’s easy too the next time”, which is not the approach I would have taken.
In my opinion, this project is more about 3to2 than packaging. Its deliverable should be a command-line script which copies packaging from a directory, runs 3to2 with a set of fixers and runs sdist commands. The main milestones should involve reading about other projects using 3to2, how to solve difficult bytes/string issues, and writing custom fixers for that. The goal is that we can use that script in six months and a year and three years, with new fixers or minor adjustments to the code, but not just “run 3to2 + fix all the problems”.
What do you think?