Hi Abdel, On Tue, Sep 15, 2009 at 2:21 PM, Abdelrazak Younes <[email protected]> wrote: > Technically speaking, I will just say that either this bridge is bundled > with the Windows installer or the full elyxer is bundled with LyX together > with the other python scripts.
The Windows issue (which I will comment below) is only one half of the integration problems that have reached me recently. The other one was a problem on Mac OS X. Despite being Unix-based (*BSD-based to be precise) on the inside, the system is quite different on the outside: installation for a single user does not often require administrative (root-like) privileges, or going near the console, and you only have to copy a "file" (really a folder) to your hard disk. This folder contains the executable, but it may also contain libraries and configuration files and everything else. The logical thing to do for a packager is to bundle eLyXer with LyX and distribute both together. But until this is accomplished this is not the only situation that eLyXer has to work in; those users that choose to download eLyXer on their own and try to integrate it currently have to copy elyxer.py into the LyX folder and reconfigure LyX. When it's time to upgrade LyX again, users have to substitute the old folder with the new one, losing eLyXer in the process. Then they have to download elyxer.py again, put it in the LyX folder again and reconfigure. Hardly convenient. It seems best to place eLyXer somewhere that LyX can find it, e.g. in the path. But this apparently requires admin privileges again and is bothersome for users. Instead, Python has its own way to distribute software: distutils. Since standard mechanisms are generally better and since eLyXer has used its own distribution methods for too long I thought that it was best to use distutils, thus solving three separate issues at a time: a single command $ python setup.exe install would suffice. But having elyxer.py in the Python library directory would not make it any easier for LyX to find it when it needs to convert a file; LyX needs an executable or at least a script. So a script elyxerbridge.py had to be supplied; unfortunately it was bigger than necessary because I moved there a few things which the library needed. A one-liner file would have been enough, and this can be corrected. > It makes absolutely no sense to me to put a > bridge in LyX for a tool that is only used together with LyX. Let me point out that LyX already has a bridge for eLyXer, in the form of a few lines of detection code in configure.py; so it makes sense. Adding a few more lines should not be a big deal. I didn't think that putting a script in the scripts folder was such a big deal since Uwe had committed a patch that required elyxer.py to live in the scripts folder (on configure.py) and nobody had complained. Apparently I was wrong. If these two issues (Windows and Mac OS X) can be solved in other ways then there is no need for elyxerbridge.py. But having to distribute this file with eLyXer so that both maintainers can pick it up and bundle it makes no sense to me. Better to have the software integrated as smoothly as possible. I am sorry to have explained myself so poorly the first time, but as an excuse: it took me considerably longer to write this explanation than the glue code. > And if elyxer > is integrated in LyX, you will of course have to promise to maintain it > Alex. I know I have committed to do this in the past, but after a lot of discussion I withdrew my offer. Now I am not so sure -- your development community sure is not very welcoming, and it has a few strident members which are apparently no fun to work along with. I would never promise to work in such conditions in my spare time (I already have to deal with enough jerks in the job that pays for my extravagant way of life), and that is unfortunate because it means that the bullies have won the day. For that I am sorry. I have of course committed to work on my project eLyXer, just for the sake of the hundreds of users which find it useful (and because it is fun). Joint distribution is, as we agreed the last time around, a good compromise -- only packagers and integrators have to worry about the integration, and they can drop eLyXer the moment they see that my support goes below their standards. Thanks, Alex.
