Because I was on moving out home last week , I didn’t spend much time on my summer work and may fall a little behind the schedule. This week I have gotten away from all the busy things , then can spend a good time on my working stuff to catch up with the timeline.
Things done this week:
1 retrieve the recent emails again to get to know what I may miss , forget to reply , or should do
Thanks to Eric’s valuable comments on my weekly report and detailed reviews against my patches, I can always get to know whether I make some mistakes in current solution or fall
too deep in reading the source code of setuptools. But I’m still sorry that I was a little
busy , did not spend much time on my work, and didn’t reply the emails in a responsive
time. So, at the beginning of this week, I spend some time on reading the emails, among
which some are direct emails from my mentor, some are discussing emails on the bug tracker, some are messages from the reviews against my patches. For a good starting up in future days, I think it’s worthwhile.
2 improve corresponding code on which mentor has made reviews
I noticed the reviews about the bug “Add **kwargs to get_reinitialized_command”, but I have spent almost the most of coding time on the ‘develop’ command, so I just can spare alittle time this week to improve my code corresponding with this issue. Thanks to Thomas’s improvements work, I can continue with the ‘develop’ work now.
Eric has made many comments in the review about my ‘develop’ command, so it takes me
several day hours to fix problems and make improvements. Anyway, if there are not things missed, I think I have finished the majority of improvements work and replied to every review line.
3 write two posts when reading the source code about auto script generation of setuptools
To make things more clear, I just wrote two posts to talk about what setuptools has done when execute auto script generation. One is titled “[Automatic Script Creation] ‘console_scripts’ on POSIX”, and the other is titled “[Automatic Script Creation] the
entry_points on Windows”. Although it may seems a little deep for me in reading the source code, but it still help a lot when I coding to implement auto-script-generation
functionality for packaging.
4 begin to write code about auto-script-generation and already write a simple test
After improving ‘develop’ command in a deep way, I can have time writing code to implement auto-script-generation, even though in a very simple way. As mentor said, it’s a good starting point to firstly implement for a simple entry like “sphinx-build = sphinx.build.main”. In addition, the tests take me a little time, but there are also some
problems in my tests and I will try to improve them asap.
1 keep enhancing ‘develop’: functions, docs, tests
2 keep developing ‘scripts’