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!