Here’s a more detailed review, following my comments on the fellowship mailing list (which you haven’t all addressed in your proposal or wiki page!).

I think there’s still a slight misunderstanding, despite the exchange we’ve had in private and public email. Python does support running uninstalled code; for extension modules, running build_ext --inplace does the trick. In other words, a developer does *not* have to rebuild and reinstall the project to run tests after each change.

The specific feature provided by the develop command is twofold: make the code appear as installed to Python, so that other code can import it, and make the egg-info metadata available to the pkg_resources system (in distutils2, it’s dist-info and pkgutil). Does this make sense now?

Regarding implementation, the easy-install.pth hack used by setuptools is unacceptable for the standard library. Finding a clean way to implement it will be an interesting challenge.

With the advent of “python -m” as a way to run modules as scripts, I think that the part about generating wrapper scripts is not essential, and I’d suggest that it waits for after you’ve completed the feature about script generation, which should let you learn a lot about scripts. It’s only a suggestion, other people in our group more familiar with setuptools may have a different opinion.

You’ll need to learn a bit more about egg-info and dist-info metadata, which are not the same thing. For example, when you say “use PEP376 new apis to read metadata from .dist-info to create wrapper scripts”, you show that you don’t know that scripts are not mentioned in PEP 376 at all.

Here your application shows a (very minor) misunderstanding of the tools: as you’ll be working in a Mercurial repo, creating the final patch will only take seconds, not days. In a similar way, “fixing” a bug is only a bureaucrating task that consists in editing an HTML form. Writing the code is the actual work; closing the bug is just a thing we do to keep track of things, it does not take days. So please edit your timeline to remove those steps and reallocate the days for concrete tasks.

That’s not true. You can call the suppport for Python scripts basic, but it’s a simple and useful system which works. The setuptools feature is just a layer of added convenience and platform-specific workarounds.

To be precise, the “console_scripts” entry point is used to generate scripts. The feature we discuss is to port that thing only, not the whole entry points system: that’s the extensions project.

There is proprietary software that is deployed on many platforms too. Python and distutils don’t take sides about software freedom, they support both worlds.

To make things clear: distutils2 aims to be a better replacement for distutils, and also obsolete setuptools by taking its good ideas and running with it, but it is not a drop-in replacement. Also, perfection is never achieved : )

I like that you plan to review the distutils patches before looking at the setuptools code, it sounds a sane way of diving in.

This is a bit vague. Do you mean function as a Python function or the functionality, which will probably require multiple functions? Also, how will you do it? Are you familiar with writing tests? How about tests that run commands and inspect the file system? Is there already support in distutils2 for that? Again, you are not supposed to master the codebase before the GSoC nor have all the answers, but you have to show that you’ve given thought to it, made a bit of research and have concrete plans.

I’ve read some old messages and blog posts again and found that Tarek explicitly wanted the extensions system to be decoupled from the packaging tool, so maybe my suggestion about it weakens your application. However, you did find a way to show the three tasks as a coherent proposal. I also think that it is a very important part of setuptools which we have to consider, and the knowledge of setuptools and Python that you will acquire during the first two tasks will make you suited to tackle this one. Last summer, a distutils2 student did work on it after all. It may also be that you’re given other tasks after the student selection or after midterm.

Does this mean that you won’t write docs and tests alongside the code?

What does this mean? Why does it take four days?

The patch that we required serves to make sure that this is done ahead of time.

Don’t get too specific about implementation (especially since I don’t want this one detail :–), stay at the user level.

Not all. Multiversion is a whole can of worms in itself, and would require discussion with the developpers of the import system; it’s another topic entirely.

I hope this long message is helpful. To reply to it, please amend your proposal on the wiki (I will get automatically notified) or reply to specific items on the GSoC site.

Second Review

Looks like we’ve already started on that :–)

The first paragraph describing the develop command still says that people run distutils to test changes, which is still not true, but the rest of the paragraph is good, as it says that the feature is to make the code appear as installed (including making egg-info/dist-info metadata available to the system, which you did not explicitly say).

→ This is still true.

Regarding the timeline, I would encourage you to write tests before code. You’ll probably take as much or more time to write tests than code, and writing tests beforehand helps you covering all cases and figuring out the API of the code. It may appear a strange method, but it turns out that it’s really helpful and working. Of course, this being Python, sometimes you just write the code in ten minutes before the tests because it’s too easy :–)

→ Xu edited his proposal to take that recommendation into account.

I wrote this in the first review:

What is your opinion?

→ Reply by private email: I think you are right, future work on script generation will make me more clear about the wrapper scripts functionality, so I removed this task from my application and adjusted the timeline.

I had forgotten gui_scripts, very good catch!

I will create a new bug to track your new work and close the older ones as duplicates (the discussions will still be there to read), it will be easier to use than half a dozen of duplicate bugs.

SummerOfCode/2011/SetuptoolsFeatures/review (last edited 2011-04-21 16:21:08 by 193)

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