This week I spent much time on fixing the repository corruption problem of Mercurial, so I cann’t share my work on develop command of packaging with others as soon as possible. Through communicating with Mercurial developers on its mailing list, I got to know that the reason causing this problem is that I cloned a repository on Win7 and copied it to my WindowsXP machine with a U disk – during copying and pasteing, some files with leading spaces in the .hg directory are stripped. Thanks to Eric’s great work about the workflow of contribution to distutils2/packaging, I can work regularly with a clear mind and a comfortable mood. And finally I can publish my work on bitbucket, then move further.
Things done in this week:
1 create a server-side clone on bitbucket and push all my changesets to this repository
+1 I can work regularly with python bug tracker, bitbucket.org, Mercurial, python language now!: ) It’s great for me and take me enjoyable experiences during this process.
2 report an enhancement bug about adding kwargs to get_initialized_command, and write a patch to fix it
+1 During this process, I think I moved more further in Python’s world, because it doesn’t need me to make a patch and upload it to bug tracker now, and all I should do is just to push changesets to bitbucket and paste the corresponding uri to bug tracker.
3 do some refactor work
As I said in last weekly report, there are still much to improved in my code. So in this week, I did some refactor work, e.g. removing some unnecessary comments, simplifying some code, e.t.c.
Mentor has made some good comments on my work and there is a lot of communication on the bug tracker and in the fellowship mailing list, so I think it will take me some time to make a summary and refactor my code in the following aspects:
1) the role of ‘develop’ places
I agree with Eric’s saying that develop should be a command instead of an action, and it maybe taken as an option of install. But these days I’m wrting tests against current work, so I have not yet changed current develop working way. I will do this work soon.
2) the location that .dist-info directory should be placed in
It’s good that in bug tracker Eric has shown three reasons that we should place .dist-info directory under the build dir. I will make a more better consideration and do some verifying work. It’s easy to change.
3) the use of .distinfo-link file
In setuptools, there is an .egg-link file which is used to let setuptools find the egg of the project in ‘development’ mode, so I also created a .distinfo-link file under the installation directory(defaultly site-packages). Eric has asked me what is this file used for in packaging, but now I have not yet summarized a good saying. So, I’ll construct a good example showing its usage in these two days if it is actually necessary.
4 write tests against current ‘develop’
It’s almost completed with only about one function left. I think I can finish it today and will push it to bitbucket asap.
According to the schedule on my proposal, I should finish the work of ‘develop’ command before June 20, but it seems that it’s a little impossible for me according to current progress. So I’m asking for more 2 days here and will try my best.
Then in next week, I will try to fix the above prolems and make a better ‘develop’, then begin to focus on the next summer task – automatic script creation.