lockfile blocking other projects on one server

Possible ways to solve this (feedback welcome):
 * include current zope user in lockfilename
 * include current path in lockfilename
 * include current mailserver in lockfilename (maybe you don't want to stress your mailserver with multiple projects sending the their newsletters the same time)
 * include a optional request parameter which you append in your clockserver-configuration to modify your lockfile dynamically.

Perhaps store the lockfile in the client home. Use:

os.environ.get('CLIENT_HOME')

In my case that gives '/Users/mauritsvanrees/buildout/singing-dancing-dev/var/instance'
I'm not sure if we mind that this means that two zeo clients could start sending out a newsletter at the same time, as they will have two separate lock files.

Including the current zope user (e.g. with os.getuid(), which in my case returns 501) in the lock file name sounds fine too. It does not solve the case of one zope user running multiple buildouts that use S&D, but that seems okay to me, though it may need a mention in some documentation, even if only in the HISTORY.txt

Current path might be tricky. At least os.getcwd() returns different directories, depending on where you are when you start the instance. And in a cron job, e.g. to restart the instance at reboot time, the current working directory is probably the root of the file system.

We have the same problem with collective.singing.message.lock which is also placed in /tmp directory and blocking other S&D installations in other projects on the same server.

@maurits: i tried the os.environment.get('CLIENT_HOME') but it seems to be different when running the tests...

Strange, with "os.environment.get('CLIENT_HOME')" I always get <buildout directory>/var/instance
It's the same whether I do 'bin/instance fg' or 'bin/instance test -s collective.dancing' in collective.dancing/trunk-buildout or 'bin/instance fg' or 'bin/test' in collective.dancing/trunk

At least, this is when putting that "os.environment.get('CLIENT_HOME')" line near the top of collective/dancing/browser/utils.py

i'd go for the last propsed option "include a optional request parameter which you append in your clockserver-configuration to modify your lockfile dynamically."

its relatively easy to implement and works on all OS. in addition developers and admins can configure whether two instances with different newsletters use the same lockfile (might be useful if they use the same smtp-server) or not.