sync-engine setup.py

[Jonny Lamb]

Hi.

I just committed a fix to sync-engine's setup.py[0] to find the right
OpenSync plugin directory using "pkg-config opensync-1.0
--variable=plugindir", or complain with a message if that fails.

First of all, any objections, questions, things I may have overlooked?

Next, this is primarily for John Gow: Both opensync plugins go into the
same directory, and looking at them both, one can see that they are both
named "synce-plugin". Therefore, with them both present, "msynctool
--listplugins" will come up with two entries for "synce-plugin".
Therefore, I am proposing their names are changed to
"synce-plugin-pre-0.30" and "synce-plugin-0.30", or something like that.

Agreed?

Thanks,

[1] r3146

[Dr J A Gow]

Post by Jonny Lamb
Next, this is primarily for John Gow: Both opensync plugins go into the
same directory, and looking at them both, one can see that they are both
named "synce-plugin". Therefore, with them both present, "msynctool
--listplugins" will come up with two entries for "synce-plugin".
Therefore, I am proposing their names are changed to
"synce-plugin-pre-0.30" and "synce-plugin-0.30", or something like that.

In general disambiguation is a good thing. But why should both of them
be present in the same directory? Surely we should only copy/symlink the
appropriate plugin for the particular installed version of OpenSync -
not copy them both over (and thus have an unused module in OpenSync's
plugin directory)?

If we do copy/symlink them both over, and then disambiguate them, there
is potential for someone to select the wrong plugin. If we detect the
installed version of Opensync and install only the right one - there is
less margin for error.

John

[Jonny Lamb]

Post by Dr J A Gow
In general disambiguation is a good thing. But why should both of them
be present in the same directory? Surely we should only copy/symlink the
appropriate plugin for the particular installed version of OpenSync -
not copy them both over (and thus have an unused module in OpenSync's
plugin directory)?

Well, you talk about copy/symlinking the appropriate plugin, but from
where? I think the days of running SyncEngine from the directory you
checked it out from are gone. I'm not sure what's the problem with
having two opensync modules in the folder -- it's not as if they're are
very big:

reger:~/sync-engine% du -hs opensync-plugin*.py
16K opensync-plugin-0.30later.py
12K opensync-plugin.py

Post by Dr J A Gow
If we do copy/symlink them both over, and then disambiguate them, there
is potential for someone to select the wrong plugin. If we detect the
installed version of Opensync and install only the right one - there is
less margin for error.

Well, this is a fair point. Check out the attached patch and tell me
what you think.

[P.S. I subscribe to all lists I post to, so I need not be CC'd on
responses]

[Dr J A Gow]

Post by Jonny Lamb

Post by Dr J A Gow
In general disambiguation is a good thing. But why should both of them
be present in the same directory? Surely we should only copy/symlink the
appropriate plugin for the particular installed version of OpenSync -
not copy them both over (and thus have an unused module in OpenSync's
plugin directory)?

Well, you talk about copy/symlinking the appropriate plugin, but from
where? I think the days of running SyncEngine from the directory you
checked it out from are gone. I'm not sure what's the problem with
having two opensync modules in the folder -- it's not as if they're are

I think we may have been talking at cross-purposes. I was referring to
the proposal to copy both plugins to the OpenSync plugin directory. In
this case there will always be one of the two plugins that will be a
redundant module that should _not_ be used with the particular version
of OpenSync - but both will be visible on an msynctool --listplugins.
This would be bad.

John.

[Jonny Lamb]

Post by Dr J A Gow
I think we may have been talking at cross-purposes. I was referring to
the proposal to copy both plugins to the OpenSync plugin directory. In
this case there will always be one of the two plugins that will be a
redundant module that should _not_ be used with the particular version
of OpenSync - but both will be visible on an msynctool --listplugins.
This would be bad.

Well, okay, the patch I just sent in this thread only installs the
relevant plugin, so surely it solves your issue?

It has, however, one issue: Assume someone installs this with pre-0.30
OpenSync, uses that for a while, and then upgrades OpenSync.. He will
have to reinstall SyncEngine for it to detect the newer version. Is
there an easy way to get around this?

[Dr J A Gow]

Post by Jonny Lamb
Well, okay, the patch I just sent in this thread only installs the
relevant plugin, so surely it solves your issue?
It has, however, one issue: Assume someone installs this with pre-0.30
OpenSync, uses that for a while, and then upgrades OpenSync.. He will
have to reinstall SyncEngine for it to detect the newer version. Is
there an easy way to get around this?

I think this issue may always be a problem unless we provide a script in
the sync-engine distribution, something like 'install-plugins.py' which
will (re)generate the appropriate file/symlink in the OpenSync plugin
directory. We could run this post-install, and instruct users to run
this file if they delete and reinstall OpenSync.

John.

[Jonny Lamb]

Post by Dr J A Gow
I think this issue may always be a problem unless we provide a script in
the sync-engine distribution, something like 'install-plugins.py' which
will (re)generate the appropriate file/symlink in the OpenSync plugin
directory. We could run this post-install, and instruct users to run
this file if they delete and reinstall OpenSync.

What do you think of the attached?

I feel the opensync-plugin*.py files should be renamed to something
better too -- synce-opensync-plugin*.py even?

[Dr J A Gow]

Post by Jonny Lamb

Post by Dr J A Gow
I think this issue may always be a problem unless we provide a script in
the sync-engine distribution, something like 'install-plugins.py' which
will (re)generate the appropriate file/symlink in the OpenSync plugin
directory. We could run this post-install, and instruct users to run
this file if they delete and reinstall OpenSync.

What do you think of the attached?
I feel the opensync-plugin*.py files should be renamed to something
better too -- synce-opensync-plugin*.py even?

All done in the latest batch of commits. Note that I modified your patch
to copy the plugins, rather than move them. This prevents the possible
loss of the plugin when a user nukes their OpenSync install for any
reason (could happen when using experimental versions particularly). All
they have to do now is re-run synce-install-plugins and all will be
well. I have tested with OpenSync 0.3x and will test with OpenSync 0.2x
tomorrow when I get back to work.

Setup.py will need updating as I have cleaned up the sync-engine root
somewhat. Both plugins will need copying across during installation of
the archive and they should reside in the sync-engine distribution
somewhere (not just in the OpenSync dir) to avoid the above problem.


John.



Other changes (excerpt from changelog):

07/12/2007 - 204100 Dr J A Gow
------------------------------

Changed plugin names to a more sensible scheme and moved them to a
'plugins' directory from which they can be copied to the OpenSync
working directory. Had to use 'synce-opensync-plugin-2x' etc, as the
OpenSync plugin architecture can not handle periods in the filenames.
Removed dependency of file-sync code on absolute paths and modified
the base config.xml file to include sensible defaults. Moved the config
file to a subdirectory 'config' as sync-engine root was getting
cluttered. Applied patch from Jonny Lamb including new
synce-install-plugins. Modified this script to move rather than copy (in
case a user hoses their OpenSync installation we then do not lose the
plugin as well). Also corrected the python plugins directory (appears as
opensync-1.0/python-plugins not opensync-1.0/plugins/python-plugins).
The script can be re-run at any time to refresh the plugins in the
OpenSync directory.

Setup.py needs updating to reflect these changes.

[Vasco Steinmetz]

Hi,

the latest commit broke setup.py.

It compiled an hour ago, so I suppose it's related to your commits.

Error log below.


Cheers,
Vasco

Emerging (1 of 1) app-pda/synce-sync-engine-9999 to /

* checking ebuild checksums ;-) ... [ ok ]
* checking auxfile checksums ;-) ... [ ok ]
* checking miscfile checksums ;-) ... [ ok ]

Unpacking source...

* subversion update start -->
* repository: https://synce.svn.sourceforge.net/svnroot/synce/trunk/sync-engine
At revision 3166.
* working copy: /usr/portage/distfiles/svn-src/synce-sync-engine/sync-engine

Source unpacked.
Compiling source in /var/tmp/portage/app-pda/synce-sync-engine-9999/work/synce-sync-engine-9999 ...

Traceback (most recent call last):
File "setup.py", line 4, in ?
from synce_install_plugins import get_plugindir, get_opensync_version
ImportError: No module named synce_install_plugins
*
* ERROR: app-pda/synce-sync-engine-9999 failed.
* Call stack:
* ebuild.sh, line 1701: Called dyn_compile
* ebuild.sh, line 1039: Called qa_call 'src_compile'
* ebuild.sh, line 44: Called src_compile
* synce-sync-engine-9999.ebuild, line 33: Called distutils_src_compile
* distutils.eclass, line 48: Called die
* The specific snippet of code:
* ${python} setup.py build "$@" || die "compilation failed"
* The die message:
* compilation failed
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/tmp/portage/app-pda/synce-sync-engine-9999/temp/build.log'.
* This ebuild is from an overlay: '/pub/users/vasco/Projekte/SynCE-Gentoo/'
*

[Vasco Steinmetz]

Post by Dr J A Gow

Post by Vasco Steinmetz
Hi,
the latest commit broke setup.py.
It compiled an hour ago, so I suppose it's related to your commits.
Error log below.

I have made a further small change to setup.py that should stop it
failing. It probably still needs updating to match the changes in
sync-engine. I am not familiar with the vagaries of setuptools (don't
have it installed here) so I am hoping someone with better knowledge of
setuptools than I will update it - otherwise I will have to do some
reading.
John.

Still fails to compile.
Obviously it still calls opensync_version() from synce-install-plugins.py.
I guess the small change you made removed the plugin detection and copy part.

Lines 5-10 seem superfluous now.


Cheers,
Vasco

[Dr J A Gow]

Post by Vasco Steinmetz
Still fails to compile.
Obviously it still calls opensync_version() from synce-install-plugins.py.
I guess the small change you made removed the plugin detection and copy part.
Lines 5-10 seem superfluous now.

Yes. They will probably need restructuring in some way but without
research I am not sure how setuptools needs to handle this.

Basically what should happen now is as follows (if you can make this
happen setuptools-friendly it would be a great help :)

In the sync-engine sources, the two plugins now reside in
sync-engine/plugins and both should be copied to the target system on
install - but held with the package and not deposited in the user's
OpenSync plugin directory (If we do this, we run the risk of losing the
plugin should the user destroy the OpenSync install for whatever reason,
and we also need OpenSync to be installed before the sync-engine).


Now, when the user has installed Opensync, we need to run
synce-install-plugins.py in order to copy the appropriate plugin to the
OpenSync plugin directory. Note this is a copy, not a move (as Jonny
Lamb originally suggested). This way a working copy of the plugin is
placed in the OpenSync plugins directory, but we retain a copy of all
plugins with the sync-engine install. We can run
synce-install-plugins.py automatically on the install of sync-engine if
we detect that OpenSync is already installed - but we should not make
OpenSync a dependency of sync-engine (we may support targets other than
OpenSync one day)

Should the user then either hose their OpenSync install, or choose to
upgrade it, no plugins are lost and they do not need to reinstall
sync-engine. All they need to do is re-run synce-install-plugins.py, and
the correct plugin will be (re)inserted.

Hope this makes sense - please ask if you need clarification.

John.

[Vasco Steinmetz]

Post by Dr J A Gow

Post by Vasco Steinmetz
Still fails to compile.
Obviously it still calls opensync_version() from synce-install-plugins.py.
I guess the small change you made removed the plugin detection and copy part.
Lines 5-10 seem superfluous now.

Yes. They will probably need restructuring in some way but without
research I am not sure how setuptools needs to handle this.
Basically what should happen now is as follows (if you can make this
happen setuptools-friendly it would be a great help :)
In the sync-engine sources, the two plugins now reside in
sync-engine/plugins and both should be copied to the target system on
install - but held with the package and not deposited in the user's
OpenSync plugin directory (If we do this, we run the risk of losing the
plugin should the user destroy the OpenSync install for whatever reason,
and we also need OpenSync to be installed before the sync-engine).
Now, when the user has installed Opensync, we need to run
synce-install-plugins.py in order to copy the appropriate plugin to the
OpenSync plugin directory. Note this is a copy, not a move (as Jonny
Lamb originally suggested). This way a working copy of the plugin is
placed in the OpenSync plugins directory, but we retain a copy of all
plugins with the sync-engine install. We can run
synce-install-plugins.py automatically on the install of sync-engine if
we detect that OpenSync is already installed - but we should not make
OpenSync a dependency of sync-engine (we may support targets other than
OpenSync one day)
Should the user then either hose their OpenSync install, or choose to
upgrade it, no plugins are lost and they do not need to reinstall
sync-engine. All they need to do is re-run synce-install-plugins.py, and
the correct plugin will be (re)inserted.
Hope this makes sense - please ask if you need clarification.
John.

Well with Gentoo adding OpenSync support could be realized either by introducing a use-flag for the sync-engine package (if
necessary at all) and copying the plugin file accordingly during the build (that is, outside of setup.py).
Since the ebuild knows which version of OpenSync is installed it can copy the proper plugin depending on the installed OpenSync
version to its correct location.

Installing it on other distros (APT, RPM) may be a bit more complicated - going through setup.py would be more feasible there.

Are those OpenSync plugins actually an integral part of sync-engine?

There are still packages named 'synce-multisync-plugin-0.9.0' and 'libopensync-plugin-synce-0.20' in the main gentoo tree.
I suppose the latter, being unmaintained and hardmasked though, provided the plugins for earlier versions of opensync.

Sticking to that scheme would mean splitting/forking the opensync plugins off the sync-engine directory into a separate package, one
for opensync 0.2x and one for 0.3x+ that could be downloaded/installed accordingly.

I don't know anything about the dependency graph of OpenSync, sync-engine and the plugins though.

Just trying to get my WM6 Hermes/TyTN/Trion/Vario synced to Kontact with KitchenSync... ;)


Cheers,
Vasco

[Dr J A Gow]

Post by Vasco Steinmetz
Well with Gentoo adding OpenSync support could be realized either by introducing a use-flag for the sync-engine package (if
necessary at all) and copying the plugin file accordingly during the build (that is, outside of setup.py).
Since the ebuild knows which version of OpenSync is installed it can copy the proper plugin depending on the installed OpenSync
version to its correct location.

This sounds right - I think.... - I don't use Gentoo so I'm guessing a
little. However, all the ebuild needs to do is run
synce-install-plugins.py to copy the plugins once the files are copied.

Post by Vasco Steinmetz
Installing it on other distros (APT, RPM) may be a bit more complicated - going through setup.py would be more feasible there.
Are those OpenSync plugins actually an integral part of sync-engine?

Yes. They are OpenSync plugins, but will not function without
sync-engine.

Post by Vasco Steinmetz
There are still packages named 'synce-multisync-plugin-0.9.0' and 'libopensync-plugin-synce-0.20' in the main gentoo tree.
I suppose the latter, being unmaintained and hardmasked though, provided the plugins for earlier versions of opensync.

I think these are the pre-WM5 packages and plugins - incompatible with
WM5/6.

Post by Vasco Steinmetz
Sticking to that scheme would mean splitting/forking the opensync plugins off the sync-engine directory into a separate package, one
for opensync 0.2x and one for 0.3x+ that could be downloaded/installed accordingly.

Probably best not to split the plugins from sync-engine. They won't work
without each other.

Post by Vasco Steinmetz
Just trying to get my WM6 Hermes/TyTN/Trion/Vario synced to Kontact with KitchenSync... ;)

Does KitchenSync use Opensync? Just wondered - I use KDE as a work
environment but do all my syncing from the command line with msynctool.

John.

[Vasco Steinmetz]

Post by Dr J A Gow

Post by Vasco Steinmetz
There are still packages named 'synce-multisync-plugin-0.9.0' and
'libopensync-plugin-synce-0.20' in the main gentoo tree. I suppose the
latter, being unmaintained and hardmasked though, provided the plugins
for earlier versions of opensync.

I think these are the pre-WM5 packages and plugins - incompatible with
WM5/6.

Since they are unmaintained they should be either upgraded or removed.

Post by Dr J A Gow
Does KitchenSync use Opensync? Just wondered - I use KDE as a work
environment but do all my syncing from the command line with msynctool.

Works pretty well, though.
Still using OpenSync-0.2x with KitchenSync-3.5.7.
Seeking to upgrade too OpenSync-0.3x soon.

If Sync-Engine would start automatically via udev/hal/dbus or by any of the
Tray-tools, I'd have a complete control to my MDA (Software, File-Sync,
Contacts/Tasks/Calendar-Sync) without any manual command-line interaction...
hope to see it soon!


Cheers,
Vasco

[Dr J A Gow]

Post by Vasco Steinmetz
If Sync-Engine would start automatically via udev/hal/dbus or by any of the
Tray-tools, I'd have a complete control to my MDA (Software, File-Sync,
Contacts/Tasks/Calendar-Sync) without any manual command-line interaction...
hope to see it soon!

Just in case you missed it, it is possible now to run sync-engine in two
different modes. This may help when running sync-engine from hal/udev.

If you pass the --detached option to sync-engine, it will run in the
background (use --logfile=<filename> to dump the sync-engine log to a
file).

If you pass the --once option to sync-engine, it will exit when the
device is disconnected. If you write a hal/udev rule to run 'sync-engine
--detached --once' on device connection, then sync-engine will be
started as the device is connected, and will shut down when the device
is disconnected ready for the next connection.

John.

[Mark Ellis]

snip detail

Post by Dr J A Gow
Hope this makes sense - please ask if you need clarification.
John.

Can I approach this from another direction.

I know we like to make things as easy as possible for everyone we can
possibly think of, but most users that install from source aren't too
concerned about a little manual setup, and could probably keep an eye on
which plugin they need at any particular time, if it's in a README.

Distros and their packages, on the other hand, are there to make life
easy for users who don't do tarballs, and have features to make this
stuff easy. For instance, I'd build 3 debs from sync-engine, the core
engine and 2 plugins, and use dependencies and conflicts to manage them.

Mark

[Vasco Steinmetz]

Post by Mark Ellis
I know we like to make things as easy as possible for everyone we can
possibly think of, but most users that install from source aren't too
concerned about a little manual setup, and could probably keep an eye on
which plugin they need at any particular time, if it's in a README.

Correct.

Post by Mark Ellis
Distros and their packages, on the other hand, are there to make life
easy for users who don't do tarballs, and have features to make this
stuff easy. For instance, I'd build 3 debs from sync-engine, the core
engine and 2 plugins, and use dependencies and conflicts to manage them.

Would be 3 ebuilds for Gentoo then:

app-pda/libopensync-plugin-synce-0.2x depending on <app-pda/libopensync-0.30
app-pda/libopensync-plugin-synce-0.3x depending on >=app-pda/libopensync-0.30

app-pda/synce-sync-engine-0.1x requiring any version of
libopensync-plugin-synce if libopensync is installed, or when a
local "opensync" use-flag is specified.


Any comments from Gentoo users?


Cheers,
Vasco

[Vasco Steinmetz]

Post by Vasco Steinmetz
app-pda/libopensync-plugin-synce-0.2x depending on
<app-pda/libopensync-0.30 app-pda/libopensync-plugin-synce-0.3x depending
on >=app-pda/libopensync-0.30
app-pda/synce-sync-engine-0.1x requiring any version of
libopensync-plugin-synce if libopensync is installed, or when a
local "opensync" use-flag is specified.
Any comments from Gentoo users?

That's crap. Dr. Gow pointed out in an earlier post, that the plugins require
both libopensync and sync-engine.

The correct dependency would be:

app-pda/libopensync-plugin-synce-0.2x depending on <app-pda/libopensync-0.30
app-pda/libopensync-plugin-synce-0.3x depending on >=app-pda/libopensync-0.30
and both depending on app-pda-sync-engine.


Cheers,
Vasco

[Richard Alimi]

Post by Vasco Steinmetz
app-pda/libopensync-plugin-synce-0.2x depending on
<app-pda/libopensync-0.30 app-pda/libopensync-plugin-synce-0.3x depending
on >=app-pda/libopensync-0.30

I'm wondering about version numbers for our opensync plugin here. Since we
don't really release in parallel with the rest of opensync, should we really
assume that our releases will have version numbers that match up with theirs?

I honestly don't know what makes the most sense in this case - I'm just
pointing out one possible issue with that approach. It certainly might be
the case that we align our version numbers for the plugin with opensync's
version numbers. However, this diverges from the version numbering schemes
for the rest of our stuff.

[Dr J A Gow]

Post by Richard Alimi
I'm wondering about version numbers for our opensync plugin here. Since we
don't really release in parallel with the rest of opensync, should we really
assume that our releases will have version numbers that match up with theirs?
I honestly don't know what makes the most sense in this case - I'm just
pointing out one possible issue with that approach. It certainly might be
the case that we align our version numbers for the plugin with opensync's
version numbers. However, this diverges from the version numbering schemes
for the rest of our stuff.

The version numbers on the plugins reflect not so much the Opensync
_version_ as the Opensync _API_. Opensync made significant changes to
the API across the 0.2x/0.3x boundary. So we have two plugins, one for
0.2x, and one for the new API in OpenSync 0.3x and later. As far as I
can tell, the API is not scheduled to change again so radically.

The versions on the plugin filenames are not related to the SynCE
version.

John.

[Richard Alimi]

Post by Dr J A Gow
The version numbers on the plugins reflect not so much the Opensync
_version_ as the Opensync _API_. Opensync made significant changes to
the API across the 0.2x/0.3x boundary. So we have two plugins, one for
0.2x, and one for the new API in OpenSync 0.3x and later. As far as I
can tell, the API is not scheduled to change again so radically.
The versions on the plugin filenames are not related to the SynCE
version.

Yes, I understand that there were lots of API changes between OpenSync
versions. I'm wondering about how to encode _our_ version number as well.
Isn't it certainly possible that our opensync 0.3x plugin can change between
0.10 and 0.11, or between 0.11 and 0.12?

--
Richard Alimi
Department of Computer Science
Yale University

[Dr J A Gow]

Post by Richard Alimi
Yes, I understand that there were lots of API changes between OpenSync
versions. I'm wondering about how to encode _our_ version number as well.
Isn't it certainly possible that our opensync 0.3x plugin can change between
0.10 and 0.11, or between 0.11 and 0.12?

It will undoubtedly, but then why do we need to encode our version
number in the plugin file any more than we do in any of the other
components of sync-engine?

John.

[Richard Alimi]

Post by Dr J A Gow

Post by Richard Alimi
Yes, I understand that there were lots of API changes between OpenSync
versions. I'm wondering about how to encode _our_ version number as
well. Isn't it certainly possible that our opensync 0.3x plugin can
change between 0.10 and 0.11, or between 0.11 and 0.12?

It will undoubtedly, but then why do we need to encode our version
number in the plugin file any more than we do in any of the other
components of sync-engine?

Not in the plugin file - the version number would be in the ebuild file name.

--
Richard Alimi
Department of Computer Science
Yale University

[Dr J A Gow]

Post by Richard Alimi
Not in the plugin file - the version number would be in the ebuild file name.

Ah, I see - so the actual file copied to the target system would be the
same as we have in the source tree - this is just a packaging issue?

John.

[Richard Alimi]

Post by Dr J A Gow

Post by Richard Alimi
Not in the plugin file - the version number would be in the ebuild file name.

Ah, I see - so the actual file copied to the target system would be the
same as we have in the source tree - this is just a packaging issue?
John.

Exactly :)

--
Richard Alimi
Department of Computer Science
Yale University

[Dr J A Gow]

Post by Richard Alimi
Exactly :)

Forgive my ignorance, I've never been involved with packaging.

John.

[Richard Alimi]

Post by Dr J A Gow

Post by Richard Alimi
Exactly :)

Forgive my ignorance, I've never been involved with packaging.
John.

No problem at all - I am by no means an expert on it either :) I just
happened to become a bit familiar with Gentoo's way of doing it, but I'm sure
many others know far more than I about best practices and such. I'm not
quite sure what the "right" approach is in this case really. Just trying to
throw out ideas.

--
Richard Alimi
Department of Computer Science
Yale University

[Dr J A Gow]

Post by Vasco Steinmetz
Hi,
the latest commit broke setup.py.
It compiled an hour ago, so I suppose it's related to your commits.
Error log below.

I have made a further small change to setup.py that should stop it
failing. It probably still needs updating to match the changes in
sync-engine. I am not familiar with the vagaries of setuptools (don't
have it installed here) so I am hoping someone with better knowledge of
setuptools than I will update it - otherwise I will have to do some
reading.

John.

[Jonny Lamb]

Post by Dr J A Gow
I have made a further small change to setup.py that should stop it
failing. It probably still needs updating to match the changes in
sync-engine. I am not familiar with the vagaries of setuptools (don't
have it installed here) so I am hoping someone with better knowledge of
setuptools than I will update it - otherwise I will have to do some
reading.

I will have a look at this tonight, as I want this fixed for 0.11.

Thanks,

[Dr J A Gow]

Post by Jonny Lamb
I will have a look at this tonight, as I want this fixed for 0.11.

Please do - I am not (yet) sufficiently familiar with setuptools to make
any but the most simple changes here. Hope my description of how the
plugin install should work in another post helps.

John.

[Jonny Lamb]

Post by Dr J A Gow
Please do - I am not (yet) sufficiently familiar with setuptools to make
any but the most simple changes here. Hope my description of how the
plugin install should work in another post helps.

Okay, so I just tagged SyncEngine 0.11. Unfortunately I couldn't think
of an elegant and fail-safe way of installing the plugin on
installation, so the synce-install-plugin.py script works fine, but it
must be called after installing. I have documented this:

http://www.synce.org/moin/SynceInstallation/Source

I don't think that's such a bad solution in the end, do you? It'll
probably be a bit nicer for packagers anyway, perhaps.

Thanks,

[Dr J A Gow]

Post by Jonny Lamb
Okay, so I just tagged SyncEngine 0.11. Unfortunately I couldn't think
of an elegant and fail-safe way of installing the plugin on
installation, so the synce-install-plugin.py script works fine, but it
http://www.synce.org/moin/SynceInstallation/Source

Those docs look nice and clean! I don't think anyone will have problems
following them, but it may be worth adding a line or two just noting
that if you trash/upgrade your Opensync install, you will need to rerun
synce-install-plugins.py to ensure that you have a valid plugin
installed.

Post by Jonny Lamb
I don't think that's such a bad solution in the end, do you? It'll
probably be a bit nicer for packagers anyway, perhaps.

RPM'ers will be OK as they can run a post-install script. I have never
used a non-RPM distro so can't speak for them but I would be surprised
if they couldn't do the same with their specific installation system. I
agree this is probably the best solution - at least we keep a 'master
copy' of the plugin files with the sync-engine install and allow the
appropriate one to be copied to the OpenSync directory at any time when
needed, rather than having the only copy of the plugin on the target
system residing in the Opensync directory, where it might get lost.

John.

[Jonny Lamb]

Post by Dr J A Gow
Those docs look nice and clean! I don't think anyone will have problems
following them, but it may be worth adding a line or two just noting
that if you trash/upgrade your Opensync install, you will need to rerun
synce-install-plugins.py to ensure that you have a valid plugin
installed.

Okey dokey.

Post by Dr J A Gow
RPM'ers will be OK as they can run a post-install script. I have never
used a non-RPM distro so can't speak for them but I would be surprised
if they couldn't do the same with their specific installation system. I
agree this is probably the best solution - at least we keep a 'master
copy' of the plugin files with the sync-engine install and allow the
appropriate one to be copied to the OpenSync directory at any time when
needed, rather than having the only copy of the plugin on the target
system residing in the Opensync directory, where it might get lost.

Actually, what I meant was that the script could be ignored, and two
more packages for the two plugins could be created, which would depend
on the correct version of OS.

[Vasco Steinmetz]

Post by Jonny Lamb

Post by Dr J A Gow
RPM'ers will be OK as they can run a post-install script. I have never
used a non-RPM distro so can't speak for them but I would be surprised
if they couldn't do the same with their specific installation system. I
agree this is probably the best solution - at least we keep a 'master
copy' of the plugin files with the sync-engine install and allow the
appropriate one to be copied to the OpenSync directory at any time when
needed, rather than having the only copy of the plugin on the target
system residing in the Opensync directory, where it might get lost.

Actually, what I meant was that the script could be ignored, and two
more packages for the two plugins could be created, which would depend
on the correct version of OS.

And which could contain more than just one plain py sourcefile per plugin.

Letting the distro's packet manager handle the dependency
calculation/check is favorable too.


Cheers,
Vasco