[Mailman-Developers] Mailman 3.0 fresh install - problems from python interpreter

[Jessy Kate Schingler]

hello again, and thanks for the response.

What I've always thought is that overview, architectural, and other useful
> higher level documentation should go in src/mailman/docs.  Still using the
> reST format, but they needn't necessarily be doctests.  So I think an
> overview
> page about "interacting with Mailman through the Python interpreter" would
> make a great page for this directory, and if you want to do a branch/merge
> proposal on that, I would gladly review it.
>

ok. i'm not totally familiar with the what/where/why of the different doc
locations. the docs that get built with sphinx (ironically, the docs about
building the docs are actually not quite right :)) are the same as the ones
at http://packages.python.org/mailman/, and seem to be a
somewhat-overlapping set with those in src/mailman/docs? i am happy to
contribute to whichever location you all think is best.


> One of the principles I've tried to hold to (successfully or not ;) is that
> the edges of the system, e.g. the shell scripts and the REST API, should
> have
> very little logic outside of managing that edge.  So for example, the
> cli_*.py
> modules should do little more than parse command line options, massage data
> into the right format, and then call into the core API, by using the
> zope.interfaces.  By organizing things this way, a Python program could
> conceivably add the proper directory to its sys.path and just 'import
> mailman'
> and various submodules to do exactly the same operations.
>

now that's i'm getting a tiny bit more familiar with the system, i can see
how this makes sense with so many different interacting components.

the zope interfaces seem to be a conceptually distinct part of the system
but i can't see where their role is documented. am i missing that?
(apologies for asking questions that i'm sure have been answered before,
feel free to just point me to a url).


> So, I would say that if you're interacting with MM3 across process
> boundaries,
> e.g. Django on one machine with the core on another, the REST API is the
> best
> way to go.  If you're interacting with MM3 on the same machine, within
> process, then 'import mailman' could be a good way to go (but of course the
> REST API still works), or you could use withlist scripts, or just script
> the
> cli.
>

great, yes, this makes sense. it seems like the REST interface is designed
to be the primary interface to the system, which is logical given that MM3
would in general be running as a remote service. i was originally thinking
of it more like this:

MM3 -> exposes python packages and connectors -> my code
      |--> rest interface (optional)

sort of like hooking into, say, mongodb or a remote mysql instance. whereas
IIUC the design is intended to be used more like this:

MM3 -> rest interface -> official/unofficial MM3 rest bindings
(mailman.client) -> my code (or, alternatively, postorius goes here, etc.)

in this interpretation, it's not that hooking right into MM3 is a bad thing
per se, but is kind of missing the point, and doing additional work to
route around the effort that's been made to provide a simple interface.


> I hope the above explains things, if not just ask!  Note that if you go the
> 'import mailman' route, you will need to initialize the system.  A good
> model
> for how that's done is src/mailman/bin/mailman.py which is what implements
> the
> 'bin/mailman' uber-command.  Other than doing fancy things to get --help
> looking decent, it's almost ridiculously simple.
>

thank you! i think the picture is coming together. i'll keep documenting
what i'm doing and hopefully will provide some good install/setup/testing
documentation...

-- 
Jessy
http://jessykate.com