Your search query "linkto%3A%22SummerOfCode%2F2011%2Fpkumar%2FPackagingPy2Porting%2Freview%22" didn't return any results. Please change some terms and refer to HelpOnSearching for more information.
(!) Consider performing a full-text search with your search terms.

Clear message

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.

  1. 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.

That’s a good point in your application: tooling, documentation and blog posts should be helpful to other projects doing 3to2 conversions.

What about 3.1, which does not have all the features that packaging uses in 3.3?

How? Manual fixes, librefactor fixers, magic comments used with a special fixer, runtime checks (which can be broken by 3to2)?

2to3 fixes imports, 3to2 probably does too, it’s one of the basic and easy things.


Why is there a special line for tests? Are they handled differently than the rest of the code?

Also, what about docs?

How? You’re not supposed to have everything figured out before GSoC starts, but you have to have a general idea.

How far are you on those steps? You should also read

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?

Second review

Are you talking about manual edition to the code after running 3to2? That’s the ad-hoc approach I speak against in the end of my review.

This does not answer my question. Tests may exercise code that returns different values, but that’s not specific to tests.

Manually? Can 3to2 convert Python code in docs?

Ah, writing a build_3to2 class is an interesting idea.

  1. 'Packaging' compatible with python2.4 to python3.2.

Again, please be precise: say whether this will be a VCS branch, or an sdist, etc.

  1. A automated system of 'packaging' to govern the porting process for different specified versions of python.

I see you’ve taken my suggestion. Just a note about the wording: “a automated system of packaging” is not clear at all, maybe say “a script running 3to2 with custom fixers for each support Python version”.

Can you go through my first review again and reply to the things that you’ve left out in your first reply?

I recommend you to remove the bits of discussion from your wiki page and amend it quickly (today or tomorrow) to integrate the result of our discussion: reworked list of deliverables (script and 3to2 fixers needed for each version) and adapted timeline (esp. with time allotted to research whether fixers can fix everything or if you’ll have to develop a magic comment system to have version-specific code in comments to be uncommented for the right version).

Unable to edit the page? See the FrontPage for instructions.