3# Weekly Report [2011/06/06 – 2011/06/12]

The biggest news of this week is that my code of ‘develop’ command in packaging can work now, though in a very simple way. Until now, I can feel a bit good because future work have a good fundation stone to go more future way. But I still want to admit here, my code is still a little messy , there are many commented lines and much should be improved and enhanced, so some careful work should be needed in future. Anyway, it’s a meaningful thing to annouce in this weekly report.

During coding, I’m still considering that how to let others get my snippet of code and if there are some good advices about workflow of this summer, esp. between python students and its member organization groups. Thanks for Eric’s good work, his suggestions of  contribution workflow for packaging have offered a good reference for us new bies in packaging.

I have also tried to contact with my mentor and have created a repository on bitbucket.org, from which interested persons can get to know my work on ‘develop’ command. The needed work is to push all of my changesets to this repository. But, Mercurial will push all of the outgoing changesets to it, which means not only my work, but other contributors’ huge work will be pushed, then doesn’t it look strange(to get to know my work, they must clone/download so many unrelated files), do all other one the similar things like this, and is it ok for me to just push my hacked/coded ‘Lib/packaging’ directory to the remote repository?

Before getting the final answer, I still tried to push all the changesets on my local repository to the remote one. But there is an error when pushing, and I also tried to look for help in Mercurial’s devel mailing list and ask for mentor’s help. It seems that my local repository is corrupt, but I still don’t know how to fix it, even though have looked into the tech support page about repository recovery from corruption – http://mercurial.selenic.com/wiki/RepositoryCorruption . Interested person can take a look at the detail error msg when verifying my repository via this link – http://paste.lisp.org/+2ML9  . I think I should reclone a new copy from hg.python.org tommorow and then import all my changesets.

OK, let me talk about important things done in this week, in a list format:

1) construct two files instead of only one: develop.py is a building blocks when excuating ‘develop’ command(looks like the install.py), develop_source.py is the develop command class which is the one doing real work (looks like the install_dist.py)

2) complete the ‘update_path_file‘ function which can create or update the .pth file

3) for backwards compatibility, realize two kinds of ‘develop’ methods: def _run_packaging_develop(path) and def _run_setuptools_develop(path), like what install.py has done – there are three installing methods in packaging , def _run_distutils_install(path), def _run_setuptools_install(path), def _run_packaging_install(path)

4) integrate all work and do some test work, and now ‘develop’ command can work in pakcaging, although in a little simple way and should be improved a lot in future. The current ‘develop’ command do the three following things:

a) create .pth file on install_dir, default path is Lib/site-packages (‘imort’ kind of magic lines will not be used)

b) create the .dist-info directory on source directory, like the way of setuptools’ installing .egg-info directory

c) create a .dist-link file, just like setuptools’ creating .egg-link file; and the content of this file is just the absolute path of .dist-info directory

Next week, three main things should be focused on:

1) push all of my work to remote repository on bitbucket.org

2) focus on intended commented strings on the source code, do improvement work and enhance all the imperfect code

3) test, fix, test, fix…

That’s all, thank you for your reading!

Best wishes and have a good day!

Advertisements
This entry was posted in Distutils2, GSOC2011, Python. Bookmark the permalink.

2 Responses to 3# Weekly Report [2011/06/06 – 2011/06/12]

  1. Éric Araujo says:

    > But I still want to admit here, my code is still a little messy […]
    > Anyway, it’s a meaningful thing to annouce in this weekly report.

    I agree, congrats on having a working proof of concept!

    I’m glad you’ve sorted out the repository corruption problem. To enable meaningful review of your code, you should follow the instructions at , especially in the section “Sharing your work”. Creating a new repo containing only the packaging module will not work; you need a clone of CPython default. Thanks to the server-side clone feature of bitbucket, you should be able to make this clone without being blocked by your badwidth.

    Your remarks about Mercurial make me wonder if you’ve misunderstood the tutorials and guides you’ve read:
    > then doesn’t it look strange(to get to know my work, they must clone/download so many unrelated files),
    > do all other one the similar things like this
    Yes, Mercurial works with a graph of changes made in a tree of files; you cannot share only part of the history or part of the files.

    I’d like you to give more information about your changes.
    > construct two files instead of only one
    Why?

    > develop_source.py is the develop command class which is the one doing real work
    A develop command should live in a file named develop.py.

    > for backwards compatibility, realize two kinds of ‘develop’ methods
    You should focus on packaging-based projects for now. If it is needed to support legacy setup.py, we can add it later.

    > The current ‘develop’ command do the three following things:
    > a) create .pth file on install_dir, default path is Lib/site-packages
    On other OSes than Windows, this won’t be possible: see http://bugs.python.org/issue12260

    > b) create the .dist-info directory on source directory, like the way
    > of setuptools’ installing .egg-info directory
    Why not in the build directory, like I recommended?

    > c) create a .dist-link file, just like setuptools’ creating .egg-link file; and
    > the content of this file is just the absolute path of .dist-info directory
    Why is this needed?

    > Next week, three main things should be focused on:
    > 1) push all of my work to remote repository on bitbucket.org
    Yes, getting a usable repo is top priority.

    > 2) focus on intended commented strings on the source code, do improvement work
    > and enhance all the imperfect code
    > 3) test, fix, test, fix…
    You should start small, have very good tests, and then improve things. For example, the multiple-versions/requires stuff is not needed right now (and maybe never will).

    Keep going on!

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