1# weekly report [2011/5/23 – 2011/5/29]

I think the main topic of this week is preparation, and it’s very important for a newbie as me before actual coding for a project with more than thousands of lines of code. During this week, all we need is the patience to read the source code of old distutils module if wanting to know the mechanism of the commands, and it also takes a bit of our carefulness to get the right working copy of current distutils2. Though problems are sometimes occured to me in this week, it’s worth mentioning that I still had some important finds and got some achivements in this difficult time.

The following sentences talk about my work/problems/finds in a more detail way:

1 Things I did

1) read the source code of distutils to get to know what the ‘develop’ command actually does

I have already read the source code of Cmd.py, dist.py, Develop.py, install.py, install_lib.py, and all the code corresponding with ‘develop’ and ‘install’ commands, which I can get the leason from to fulfil ‘develop’ command for future distutils2. Actually, it takes amount of time and work, but it did help me know more about what I should do in future and learn more from previous contributors’ excellent code.

Red herring here. I’ve also set up a good environment to read and write the python code for current project- read the souce code by Source Insight, write the source code within Ulipad, which is a wonderful Python editor written by a Chinese guy.

2) tried to get the right working copy of distutils2

It maybe not worth mentioning here, and one may think it’s just easy to clone the repository from a specific url. But when I updated my working version to the default CPython 3.3 – hg.python.org/cpython#default, it’s strange that I could not find the ‘distutils2’ or ‘packaging’ directory in the /Lib of my copy, then I could not start my future work.

Then I tried to look for other clues talking about the right repository path which I may miss, by searching the mails, asking questions in irc, looking into repository information on distutils2 online documents. And as said in my previous emails, there are three urls about distutils2 or packaging repository, or even more, then my question here is which is the right one for me to clone, since that I can not find the ‘packaging’ directory by cloning from http://hg.python.org/cpython.

3) restudying the tutorials of Mercurial on hginit.com

Thanks to my mentor Eric, it’s really a good place for me to prepare Mercurial knowledge. More reading makes me understand more better.

2 Achievement

In the process of trial work of distutils commands, I found a bug of setuptools about the case problem of ‘egg-path’ option, which I have talked about on my last post. I’m not sure it’s worth fixing this bug, because it seems that the setuptools is not maintained now.

3 Finds/Thoughts

setuptools features should be implemented basing on current latest apis which distutils2 offers, while distutils2 is implemented in a totoal completed way, so previous discussing in MLs and bug tracker should be considered carefully. You know, our current thought in a very big extent still stays at such kind of position: use ‘install_lib’ kind of commands with ‘skip-build’ kind of opitions of old distutils module, to implment ‘develop’ feature for complete new packaging module- distutils2, and you may show me a smile which means we did trap in a wrong place.

So, I think more important things we should focus are the following two aspects:
a) how setuptools implement ‘develop’ feature by using old distutils apis
b) how to implement such feature by using new apis instead of old apis

At last, I still want to make a plan of next week here:
1) get the right working copy of distutils ASAP, thus I can start actual coding work
2) get myself familiar with distutils current apis and its framework
3) write empty functions and tests against them
4) start actual coding

Hey, MR. NEXTWEEK, see you tomorrow! 🙂

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to 1# weekly report [2011/5/23 – 2011/5/29]

  1. Éric Araujo says:

    Last year I spent two weeks to understand the code, it’s real work. I chatted about it with Alexis once, and he told me I should write up what I’d learn about dist and commands. I’ll try to do it this week so that the new students have a map to the code 🙂

    > 1) read the source code of distutils to get to know what the ‘develop’
    > command actually does
    I assume you mean you read basic code in d2 and the code for develop in setuptools (or its fork distribute).

    > I’ve also set up a good environment to read and write the python code
    A nice thing with Python development is that an IDE is not required to read or edit code: any text editor is enough.

    > 2) tried to get the right working copy of distutils2
    Sorry about that; it’s the sort of technical details that should have been addressed in the bonding period, but we were in the middle of the merge to CPython and your setup of a distutils2 clone did not prepare you to work from the CPython repo with the new module name “packaging”.

    hg.python.org/cpython#default does contain Lib/packaging; maybe you’re not used to Mercurial yet, and you pulled without updating? Use “hg update default” to update your working copy, “hg branch” to see whether you’re on 3.1 or 3.2 or default.

    I’ll try to write a detailed version of the workflow we discussed on the ML this week.

    > it’s really a good place for me to prepare Mercurial knowledge. More
    > reading makes me understand more better.
    Sure, reading helps understanding the tool, and then you need practice to make it sink deep 🙂

    > it seems that the setuptools is not maintained now.
    This is FUD, and a very touchy subjects on mailing lists. setuptools gets irregular bug fixes and releases, as does its fork distribute.

    > a) how setuptools implement ‘develop’ feature by using old distutils apis
    Agreed; don’t forget to document your findings on a wiki page or blog post.

    > b) how to implement such feature by using new apis instead of old apis
    New APIs are concerned with metadata, installation from the network, PEP 376, new commands; I think you’ll end up using mostly old APIs + build_distinfo (to be written from the current code of install_distinfo).

    > 2) get myself familiar with distutils current apis and its framework
    This is kind of a broad goal 🙂 You should concentrate on understanding the APIs used by the setuptools develop command.

    In your initial proposal, these were the first two items: add a function to create the .pth file, add a function to generate .dist-info dirs in place. These are good starting points. For the first, see http://bugs.python.org/issue8668 and linked bugs in that report; for the second, read install and install_distinfo and extract the code into a new build_distinfo command.

    Cheers

    • higery says:

      I have recloned a complete new copy from http://hg.python.org/cpython#default, so don’t worry much about that.
      For that problem of not finding ‘packaging’ module, I just used the ‘hg update’ command instead of ‘hg update default’, so you are right (I’m not used to Mercurial yet, but I think it’s temporary.) Anyway, work can go on now.

      Thank you for your suggestion, I’ll try to write these two functions.

      Regards,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s