Tuesday, June 10, 2014¶
atelier¶
The commondata
, commondata.ee
and commondata.be
projects don’t have a separate projects_info.py
file because
I wanted to keep them as simple as possible.
Already yesterday I thought what a pity that I cannot simply run
ci
on them! And that they won’t get included when I do pp
fab ci
or pp fab test
!
But now atelier
can handle projects like these! The drawback
(or in fact a new requirement which I dare to consider an improvement
after reading a question setup.py should use if __name__ ==
‘__main__’, right?
asked 07 Apr 2014 by Asheesh Laroia in distutils-sig and answered by
Carl Meyer) is that every atelier project must now protect it’s
setup.py
file using an if __name__ == '__main__':
construct.
TODO: fab summary
reports the wrong description for
commondata
. That’s because the PROJECTS variable used by
atelier is simply a list of Python module names. Atelier then imports
these projects and uses their __file__ attribute. This trick does
not work for namespace packages since these are defined at more than
one place. Their __file__ attribute is unpredictable:
$ pywhich commondata
/home/luc/hgwork/be/commondata/__init__.pyc
davlink¶
DavLink is now again with a codegears-signed DavLink.jar.
Release in Eupen. Or rather “upgrade” than “release”. This was mainly to re-get the signed version of the davlink applet. I made a general pull for all repositories because it is in general recommended to pull all projects together. Because I still don’t have a strict procedure for managing “releases”. It would be overhead to impose a stricter procedure as long as I am the only person who does data migrations and upgrades. The application’s version is the only version number that is actually being used. For example Lino Welfare has been at version 1.1.13 for more than a week now, and I have even been working on the data migration for chatelet. This is okay as long as I have no changes in the database schema.