[Calendarserver-discuss] imip-agent 0.2 (iMIP capabilities for mail servers)

[Paul Boddie]

Just replying again to give some progress updates...

On Friday 27. January 2017 16.36.43 Jonas Smedegaard wrote:
> Quoting Paul Boddie (2017-01-27 13:25:38)
> 
> > On Friday 27. January 2017 11.11.46 Jonas Smedegaard wrote:
> > > 
> > > [Python modules symlinked from /etc] is unusual but not sure it is
> > > outright wrong in debian: It triggers a warning about scripts below
> > > /etc due to the hashbang of the file...
> > 
> > I would be interested to know about alternatives that work. My only
> > previous experience with Debian packaging and things in /etc was for
> > Kolab, where various PHP settings files lived in /etc/kolab (and maybe
> > a directory for Roundcube as well).
> 
> Please - I am allergic to PHP... ;-)

Me too, practically, but it was the presence of files in /etc/kolab that was 
of interest.

What I've done now is to make my own configuration file a text file 
(config.txt) that just happens to have Python syntax and that gets loaded and 
parsed by the config module (config.py), which can now live in the appropriate 
place and not need to be symlinked to. This doesn't even use the run-time 
evaluation support in Python: it uses the Python parser to recognise settings 
and to define them in a dictionary/hashtable/mapping.

So, this avoids putting importable modules in /etc and that hashbang warning.

> > Given that my configuration files are just Python syntax but need not
> > be Python modules, they could actually be loaded and evaluated in a
> > safe way, never being considered as executable either by the system or
> > by Python. I might even have code lying around to perform this because
> > it's something I did for another project of mine a few years ago.

So, it's similar to this, except that the other project used Python's 
evaluation function, whereas this actually visits the syntax tree and extracts 
the values instead.

> Perhaps look at how Radicale handles plugins: It seems to me that it
> supports _either_ probing (touching multiple files - although here with
> only "files" and "SQL" I cannot imagine it being very expensive) or
> explicitly declared choice.

Well, Radicale's plug-in mechanism, which was the other problem, uses Python's 
__import__ built-in. I'm not really a big fan of that, but if there's no other 
acceptable alternative, I guess I could use something similar.

Paul