20131125 (Monday, 25 November 2013)

Continued to move to GitHub

Moved also atelier, site and north to GitHub.

• Created a new repository “atelier” on github, this time without the “Initialize this repository with a README” option checked.

• $ cd ~/hgwork
  $ deactivate
  $ mv atelier atelier.hg
  $ git init atelier
  $ cd atelier
  $ ../fast-export/hg-fast-export.sh -r ~/hgwork/atelier.hg
  $ git checkout HEAD
  $ git remote add origin git@github.com:lsaffre/atelier.git
  $ git push --mirror https://github.com/lsaffre/atelier.git
  
  
  
  $ git mv README.txt README.rst
  $ git mv .hgignore .gitignore
  $ echo 'env.use_mercurial = False' >> fabfile.py
  $ . ~/pythonenvs/py27/bin/activate
  $ fab ci
  

• Adapted links.html and layout.html in docs/.templates to link to GitHub instead of Google Code.

Repeated the above for atelier, djangosite and north.

Some notes:

• The commit message generated by fab ci now points to the “real” blog entry at docs.lino-framework.org/blog/yyyy/mmdd.html, no longer to the source .rst file. It builds the address using the intersphinx_url attribute of env.blogger_project.

  Note that my self-designed “blogging system” is open to discussion and critics. It works for me, but I never had feedback from other developers about it. Since I have always been working as an independant developer, my workflows differ from those of a team project. Atelier tries to build a bridge between the systems. The basic difference is that I don’t always want to select or create a ticket before starting to do changes.

• The git remote commands are use to manage the “set of tracked repositories” attached to this.

Once I mistakenly push –mirror`ed the *djangosite* repository to *atelier*. Github accepted this. Result was that https://github.com/lsaffre/atelier then showed the same content as https://github.com/lsaffre/djangosite. I “repaired” that by doing another `git push –mirror from my atelier repository. The reference documentation explains git push –mirror as follows:

“Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/, refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option remote.<remote>.mirror is set.

I don’t understand nothing of the above sentence and instead believe that git push –mirror simply means “make remote repository forget everything and install content of this one there”.

Fixed some minor problems in cities demo data

After the move I re-ren the test suites and discovered dome problems like the following:

MultipleObjectsReturned: Problem installing fixture '/home/luc/hgwork/lino/lino/modlib/statbel/fixtures/inscodes.py': get() returned more than one City -- it returned 2! Lookup parameters were {'country': <Country: Belgien>, 'name': u'Bl\xe9gny', 'zip_code': u'4670'}

I guess that they came in when I added the lino.modlib.countries.fixture.demo fixture. Didn’t notice until now because I didn’t run fab initdb after this.

Making my code PEP8-compliant

Joe wrote:

I’ve read your blog post about PEP8 and for example the missing spaces after parameters are for my eyes such a pain to look at. Maybe it’s just about habits, but that’s why I find the fact that all the python code i standardized so great - almost all python code is so easy to read.

Would you accept a big pull-request changing for example the whole Lino.core to PEP8 compliant?

Yes I accept and am now waiting for Joe’s first “serious” contribution to the lino.core.

Out of curiosity I also installed autopep8 and had it run over atelier, site and north using:

$ autopep8 -ir atelier

Works like a charm.