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

[Jonas Smedegaard]

Quoting Paul Boddie (2017-01-26 16:19:42)
> On Thursday 26. January 2017 13.55.02 Jonas Smedegaard wrote:
>> Suggestion: Adapt imiptools/stores/__init__.py to only try import 
>> imiptools.stores.database and run stores.update.  It seems that 
>> change would make it possible to package imiptools/stores/database 
>> separately as an optional addon - avoiding SQL library dependences in 
>> core packages.
>
> I'll take a look at that. The database functionality is supposed to be 
> optional, of course, so it makes sense to explore ways of decoupling 
> it from the basic functionality. One thing I've done for the 
> scheduling extensions is to have a tool that explicitly configures 
> them...
>
> tools/update_scheduling_modules.py
>
> ...which builds the manifest for those extensions:
>
> imiptools/handlers/scheduling/manifest.py

That looks like a bad approach to me: I believe Debian (and any system 
following the FHS - File Hierarchy Standard) must treat /usr as 
write-protected except during package install or removal.

I can add a package install hook which generates that manifest below 
/var and symlink it, but that means the runtime package must depend on 
_development_ packages for Python.  I am not a Python programmer, but 
seems more elegant to me if your code would gracefully handle missing 
"plugin" code dynamically instead (or in addition - if you believe your 
approach has some use for deployments not caring about the FHS).


> This might seem inelegant when Python allows conditional importing and 
> all sorts of other tricks, but I wanted a separation between the 
> configuration of the software and what it does when it runs. When the 
> packaging system is supposed to take care of such things, you don't 
> then want the software failing because it tries to take on the same 
> job at run-time.
> 
> The quick fix here is to do a conditional import, but it does make me 
> think that I could provide a similar configuration mechanism for 
> storage extensions that also has a manifest file. New storage 
> extension packages would invoke a tool to update the manifest.

I would prefer a method that required python development tools available 
only at the build environment (not the target environment).

Is it relevant for speed, or just for coding style?  How do others in 
the Python community handle plugins?


>> Question: is imiptools/config.py meant to be only internal defaults, 
>> or user configurable?
>
> It is supposed to be user-configurable and maybe the documentation 
> should be clearer about that. The tools/install.sh script copies it to 
> /etc/imip-agent (or equivalent) and then makes a symbolic link to it 
> from the normal library location.

You write more documentation than most of the projects that I package.  
Please don't take my question as an indicator that you ought to write 
even more: Sounds sensible for that detail to be implicitly handled by 
your install script.

In fact, the reason I ask is that I noticed and wondered why I my 
packaging already does similar to how you describe that your install 
script does - most likely because when initially packaging I examined 
and mimicked your install script where sensible :-)


> I'm not sure whether that's the right thing to do in Debian, though.

It 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...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/calendarserver-discuss/attachments/20170127/ef5a1401/attachment.sig>