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

[Paul Boddie]

On Friday 27. January 2017 16.36.43 Jonas Smedegaard wrote:
> Quoting Paul Boddie (2017-01-27 13:25:38)
> > 
> > I've sort of avoided that myself by having the software installed in
> > /var/lib/imip-agent, as you probably noticed, because I didn't regard
> > the libraries as being more widely applicable. Thus, it was treated as
> > an application. I'm not sure whether that's the right way in Debian,
> > either. ;-)
> 
> Oh - I might have noticed when packaging initially, but then happily
> forgot again since :-P
> 
> Debian supports "private modules" below /usr but outside default lookup
> paths - but same applies there.

Maybe /usr/lib/imip-agent or /usr/share/imip-agent might indeed be places for 
these private modules, but I'm still not sure where the actual handler 
programs (imip_person.py, imip_resource.py and so on) would reside, or where 
the tools would go. For all of those things, they aren't really general 
programs, so I'm trying not to pollute the /usr/bin namespace.

> Debian possibly also supports dynamically generated/adapted python code
> below /var, but I fear I then need to implement and maintain custom code
> to ensure compliance with e.g. Debian Pyhon Policy §3.7:
> https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packag
> es.html#s-byte_compilation

It should be a simple debhelper command, I would think, perhaps dh_python2 or 
pycompile would do the job. Once upon a time, when I wrote my own packaging 
for Ubuntu and then Debian, a lot of these subcommands were called explicitly, 
but now it's like a one-liner which rewards the common case.

I don't see anything tremendously obvious in the Python policy about where the 
actual applications might live. Of course, I'm taking a Web-oriented 
perspective here somewhat, starting off thinking about /var/www and then 
considering what non-Web applications with their own resources might do. 
Again, keeping programs together in their own common place is the Web way of 
doing things, I suppose.

> > But I accept what you're saying: mutable files in the software regions
> > of an installation are a bad thing for various reasons.
> 
> Sounds like that's exactly my concern (just not fluent in the terms).

I don't think I'm really fluent in them, either. ;-)

[...]

> > But the point about needing python-dev or equivalent is a good one,
> > although I'm not quite sure I understand why you would need the
> > development package to run a Python script that generates a manifest.
> > Could you spell it out to me?
> 
> Uhm, seems I confused stuff: For pure Python code only the Python
> interpreter is needed.
> 
> What distracted me was a) the Perl-based spamassassin optionally doing
> byte-compiling to /var - but since perl byte-compilation is unusual, no
> Policy has evolved governing routines around that.  And b) Debian Python
> Policy mandating byte-compilation during install - which requires python
> development tools when the module links with C.

Right. So, pycompile might need to be available, although that appears to be 
in python-minimal. Meanwhile, dh_python2 appears to be in python. Maybe 
popular demand got the better of the policy maintainers. :-)

[...]

> Regarding how much I use Python: I used it as much as it is imposed on
> me - if I had a choice (read: If you could convince you and other coders
> to switch) then I would uninstall Python from my system, instead using
> Perl (and look forward to Perl6 with its native byte-compilation
> maturing). ;-)

I'm not likely to ever switch (back, after over twenty years) to Perl. I'm not 
too happy with the way Python has changed in the Python 3 era and the constant 
drum beat of persuasion/coercion to get people to drop Python 2, so I have 
been writing my own toolchain for a dialect of Python with its own set of 
characteristics that interest me personally. Perhaps I will switch to that one 
day.

[...]

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

I'll take a look. Thanks for the hint! Of course, Calendar Server is written 
in Python: having repurposed its list for wider discussions, we shouldn't 
forget that!

Paul