On Friday 20 May 2005 10:04, G. Milde wrote:
> >
> > To be a real package you need the __init__.py file also, I didn't saw
> > it there in your list. :-)
>
> I can assure you that __init__.py is there.
I don't have any doubt about it, or else python would not work the way you
described. :-) I was joking there. ;-)
Now a serious question: is this a trivial (empty) file or do you have any
initialization step going inside?
> > > I currently have it in my PYTHONPATH
> >
> > But we can, and should add it to the sitelib of python. Just like we
> > do with some of the tex related stuff.
>
> That's it. What I meant by PYTHONPATH was not the environment variable,
> but sys.path -- pythons search path for modules (whether it is sitelib or
> local-sitelib or whatever has to be decided by the Makefile or the
> distribution package maintainer)
I see, it was not obvious before. :-)
> > But again due to python multi-platform nature that is not a problem
> > since we can use distutils to install it in the correct place.
>
> Yes. Still it could be nice to have the LyX python files in the "sysdir"
>
> LyX files dir: /usr/share/lyx
>
> under e.g. /usr/share/lyx/pyLyX/LyX/ for all platforms (and user provided
> ones under ~/.lyx/pyLyX/LyX/).
Why?
There isn't nothing special about python here.
I can see the merits of your idea, but then we should extend it to any
script (even shell ;-), no matter what the language used be it perl,
python, lua or any other you choose.
My emphasis is on scripts not the programming language used.
So instead of /usr/share/lyx/pyLyX/LyX/ I speak
about /usr/share/lyx/scripts that we already have in 1.4. No need for
another directory here.
> > With my proposal LyX is again the natural name and there is no need
> > to play with PYTHONPATH, as the package will then be installed in the
> > system. :-)
>
> Yes. If the developers agree to put the LyX python support files in
> pythons standard search path, no additional fiddeling is needed.
>
> The install could either symlink the package dir LyX to the sitelib or
> place a pth (path extension) file there containing simply
>
> # LyX.pth
> /usr/share/lyx/pyLyX
Why not to use distutils?
This allow us to install the package in any platform, no need for this
file.
Clearly we are talking about two different subjects: the python library;
the python scripts that use the library.
I want to place the python library into the place used by python
libraries. The python scripts should go in lyx. (the /usr/share/lyx above)
> I tested this variant yesterday. As this file adds the directory to the
> search path, all python modules in /usr/share/lyx/pyLyX will be directly
> accessible to import and /usr/share/lyx/pyLyX/LyX/ will result in the
> "natural" package name (i.e. LyX), while pyLyX still shows the
> non-pythonic lyxers what is in this directory.
>
> The __init__.py file in LyX/ should add ~/.lyx/pyLyX/LyX/ to the
> _packages_ __path__, so that user added python scripts become part of the
> LyX package as well.
Again here if you are talking about a python library it should go
systemwide. I do not see any interest in supporting a local library.
> > > If you then move LYXDIR/lyx2lyx/ to LYXDIR/pyLyX/lyx2lyx, it becomes
> > > a part of the pyLyX package. Now moving LYXDIR/lyx2lyx/lyx2lyx to
> > > LYXDIR/scripts/lyx2lyx would make the lyx2lyx wrapper easily
> > > available again. Of course this moves would need changes in the
> > > import statements...
> >
> > Again no need to change its place, lyx2lyx should remain where it is
> > and as it does now it is a simple client of LyX.
> >
> > Also with this scheme there is no need to change either yours or the
> > existing code.
>
> You are right. Just now it is easiest to keep the things as-is and try
> whether the LyX package integrates well.
>
> In the long run, however, I would like to merge lyx2lyx into the LyX
> package (as ...LyX/lyx2lyx sub-module). This way it would be importable
> from other python scripts wanting to work with LyX files. Also the import
> statements in lyx2lyx become more clean and natural. (The same holds for
> the auxiliary scripts now under "sysdir"/doc/.)
But that is already done. :-)
Clearly here the problem is that lyx2lyx means two different things
again. :-) One is the directory where the code is present and the other is
the script that converts the lyx files.
lyx2lyx script:
lyx2lyx is a client script with 67 lines (85 if you consider the license).
All the knowledge how to deal with lyx files is inside LyX.py and the
lyx_*.py files, not lyx2lyx.
The only import modules are:
import getopt
import sys
import LyX
As you see if we create a LyX module there is no need to change the
lyx2lyx script. Not only that but I propose to move the lyx2lyx script from
its present location to share/scripts.
lyx2lyx directory:
I have been working on the lyx2lyx directory because cvs looses the
history if you rename a directory. If that was not the case this directory
would have been renamed LyX for more than a year ago.
So at this level, at least for me lyx2lyx == LyX
Not only that but it doesn't even deserve a special place, you alread have
several classes:
grep '^class' lib/lyx2lyx/LyX.py
class LyX_Base:
class File(LyX_Base):
class NewFile(LyX_Base):
class Paragraph:
class Inset:
class Text:
when you say a LyX/lyx2lyx sub-module, there is no need for it, we already
have a LyX.File who does all the work for you.
So clearly what we have to do is to agree on the python api to be used.
To illustrate what I mean imagine that you want to load some document, do
some transformations inside it (for example, to promote every section to a
chapter, every subsection to a section, ...) and the load it into a lyx
window.
import LyX
com = LyX.Pipe(...)
doc = LyX.File("mydoc.lyx")
# transform it
# send it to a lyx instance open
# if lyx is not running then open a new window
com.insert(doc)
> G�nter
Is this clear now? This thread has expanded to some topics that are more
appropriately discussed in the developers mailing list.
--
Jos� Ab�lio
