[eLyXer-users] Re: Advice for another LyX-oriented project

[Alex Fernandez]

Hi Jack,

On Sat, Mar 27, 2010 at 11:28 PM, Jack Desert <address@hidden> wrote:

> Dear eLyXer users and developers:

I am the only active eLyXer developer, although some people have
provided little patches. So what follows is my personal experience.

> I am developing a tool called LyxBlogger, which allows LyX to post directly 
> to a wordpress blog. LyxBlogger can use either eLyXer or the LyX 2.0 internal 
> LyXHTML format in its converter chain. As LyxBlogger and eLyXer are both 
> complementary tools to LyX itself, and are both written in Python, I would 
> like to gain from eLyXer's pool of wisdom regarding integration with LyX and 
> development in general. Here are a few questions, placed in order of 
> pertinence:

Thanks for your tool, it can can expand the utility of LyX for new
categories of users.

> 1. I notice eLyXer has two methods of installation, known as the easy and the 
> elegant way, respectively. Am I better off keeping LyxBlogger as a single 
> file to facilitate installation via the easy way? Or would it be just as easy 
> to make it a multi-file package and require installation using 'python 
> setup.py install'?

eLyXer uses a mixed approach, which is very much original as far as I
know: the source code itself is divided in modules and files, as is
usual in Python. However, for distribution a single file is coalesced
(using src/coalesce.py) into the single elyxer.py file which is
distributed. Even for the elegant install this single module is used.
This process is similar to a compilation, only here the result is also
(processed) Python code.

The latest version is 6801 lines of code, which would be an
unmaintenable mess if a single file was always used. This arrangement
is convenient and elegant, if not very standard; and it is a solution
to exactly the problem you describe. Feel free to use coalesce.py in
your own developments, if you want.

> 2. If I put a script such as LyxBlogger in ~/lyx/lib/scripts and then compile 
> LyX, will LyxBlogger automatically be installed on the target machine, or is 
> there another file I must edit to make that happen?

If you place it in ~/lyx/lib/scripts, LyX would be able to find
LyxBlogger as $$s/lyxblogger.py. As far as I know LyX takes everything
in that directory and installs it -- the Debian package certainly
contains everything.

By the way, LyX is usually capitalized with an X at the end; wouldn't
it be more consistent to call your tool LyXBlogger? Just curious, most
people will not probably mind.

> 3. Can eLyXer run on the standard vanilla Windows installation of LyX, or are 
> additional libraries required?

eLyXer is in fact contained in the Windows alt installer, without any
further requirements than Python 2.4 or later. It will use ImageMagick
if present for image conversion.

> 4. Is there a fool-proof location on Windows to place a script so that it is 
> guaranteed to be in the system path? For example, is 
> ~\install_dir\lyx\scripts included in the system path when LyX is installed?

I don't know about that. The elegant installation procedure was
designed exactly to address this problem: I don't know where setup.py
will place my script, and I don't want to know!

> 5. In your opinion, what hurdles must be jumped to have a project like 
> LyxBlogger included in a future release of LyX?

The LyX project was unnecessarily hostile to eLyXer and its whole
reason d'être. I have to say that my own attitude didn't help. See
integration rounds one:
  http://www.mail-archive.com/address@hidden/msg150549.html
two:
  http://www.mail-archive.com/address@hidden/msg154647.html
and three:
  http://www.mail-archive.com/address@hidden/msg154749.html
A quick summary: longtime LyX developers were alternatively not
convinced about the necessity of HTML output at all, of good HTML
output, of incomplete HTML output or of integrated HTML output (and
the many combinations). There are a few very friendly and intelligent
developers, but sadly those running the show seem to be a bit
narrow-minded. In the end the "native" LyXHTML was developed, as it
appears out of respite: its main developer rgheck didn't see the
necessity of HTML output and "had no use for it" -- not the best
solution for long-term support.

My optimal solution would have been joint distribution: elyxer.py
would be coalesced and integrated in the LyX repository, at intervals.
LyX developers rejected that; they wanted in any case to have a say in
eLyXer development, which would have made my goals (an independent
conversion engine for the LyX format to HTML) quite difficult to
accomplish. Right now my ideal solution is rather joint distribution,
and  I have to say that we are getting near that goal anyway: eLyXer
is bundled on Debian (+ Ubuntu for the next version), and with the
Windows alt installer. This is what I would recommend at this point.

> 6. Do you have a test suite for unit testing eLyXer? If so, is it available 
> for download?

Again, a custom solution was created for this problem. You have in
fact downloaded it with the package, see the script run-tests in the
root level. A combination of Bash scripts and test files does the
trick: sample files are converted and then checked against test
results using diff. Simple but effective. Test files are in the test/
directory. Again, feel free to reuse the code.

> 7. How did eLyXer come to be a part of nongnu.org, and how do you like having 
> it hosted there? Would you recommend nongnu as a possible hosting place for 
> LyxBlogger?

I just applied for a new Savannah project:
  https://savannah.gnu.org/register/
I would very much recommend their hosting site as the service is
excellent (this mailing list is hosted there by the way). Have I told
you that I love git? On the negative side anything out of what is
provided can take centuries, and they can be too strict in their use
of certain idioms.

> 8. What were your reasons for releasing eLyXer under the GNU General Public 
> License as opposed to the other available open source licenses?

It is a requirement for Savannah (non-GNU) hosting:
  https://savannah.gnu.org/register/requirements.php
I find that it covers very well what I want: that users have available
and modifiable source code, always.

> 9. What percentage of users do you estimate are running on Windows vs. Linux 
> vs. something else.

Hard to say: on Debian there are about 40 users. Judging by mailing
list queries they might be: Windows 50-60%, Mac OS X ~10%, Linux
30-40%.

> 10. Will eLyXer always use the extension .html in its output? (I like this as 
> it differentiates it from the .xhtml extension used by LyXHTML)

eLyXer does not really use any extension, .html or any other; the
output file name is chosen every time by the user. The eLyXer output
format is called HTML in LyX because of historical reasons.

By the way, I also proposed having multiple output formats for HTML
(so that people could try different converters), but it was not
accepted because apparently it added too much clutter. For LyxBlogger
rgheck suggested supporting both LyXHTML and eLyXer, with the default
being his own converter and eLyXer being user-selectable using some
future conversion code. I have to say, I have been waiting for that
code for more than a year and it does not look like it is any nearer.
It is a complex problem and I am not expecting a solution any time
soon.

I think eLyXer is far superior to LyXHTML (more compact output, better
CSS) and that you should enable only eLyXer if it is present, leaving
LyXHTML for those cases where eLyXer is not there. Then again I am the
author of eLyXer and have developed it for my own goals so of course I
prefer it! But be aware that with the proposed solution people will
only be able to use LyXHTML for the foreseeable future.

I hope my answers help.

Alex.