G. Milde wrote: My mail reception system changed last week and for some reason I never saw this message. :-(
I am answering this using gmane. > On 20.05.05, Jose' Matos wrote: >> On Friday 20 May 2005 10:04, G. Milde wrote: > >> Now a serious question: is this [__init__.py] a trivial (empty) file or >> do you have any initialization step going inside? > > Currently, its just > > """Package of scripts for the LyX Document Processor (www.lyx.org) > """ > # we might need __all__ on Windows (update and comment out in this case) > # __all__ = ['bindings' > # 'lfuns', > # 'lyxclient', > # 'lyxserver', > # 'pyfuns', > # ] > > At some stage, there might be code to add a directory with user-provided > python scripts to the packages __path__, so the package becomes > extensible. (Remember, my main concern is a scripting support for LyX.) I am not sure if it is worth to have a local script directory. In most of the points bellow this is my main objection. --------------------------------------------------------------------------- > >> 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. > > So do I. We still need some nice place (and name) for the "python LyX > library" in the CVS, so my idea was to keep the files at this place and > symlink to the python site-library (or use a pth file) at install time. I am not sure if every platforms we support have symbolic links. For cvs a python directory (called python naturally seems a good bet). :-) >> Why not to use distutils? >> This allows us to install the package in any platform, no need for this >> file. > > I do not insist on my idea, and have no objection to move the library > files to the site-library with distutils at install time. Distutils comes with the more modern python versions. If we ship this for 1.5 the python requirements will guarantee us that this is not a problem. >> The python scripts should go in lyx. (the /usr/share/lyx above) > > Yes, end-user scripts (like lyx2lyx, lyx-Mx or lyx-remote) should go to > /usr/share/lyx/scripts. Good. ---------------------------------------------------------------------------- > > >> > In the long run, however, I would like to merge lyx2lyx into the LyX >> > package (as ...LyX/lyx2lyx sub-module). > ... >> But that is already done. :-) > > Unfortunately, I can not see it. > >> 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. > > Another problem is the different organization of the CVS tree and the > final layout. > >> 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. > > We cannot have both, LyX.py and a LyX package inside the python library > path. Now it was my time not to be clear. ;-) If we have a LyX package we should split LyX.py content into separate files. >> 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. > > With a LyX *package*, at least one change to lyx2lyx is > needed. > > With /lyx2lyx/ -> <site-lib>/LyX/, and LyX/__init__.py the minimal change > is > > - import LyX > + from LyX import LyX > > (untested, I don't know whether there is a name conflict) No this remains the same. The python directory will then be: <site-lib>/LyX/File.Py and <site-lib>/LyX/NewFile.Py > or > > + from LyX.lyx2lyx.LyX import * > (and change of all "LyX." to "") > > or (I do not like the idea of a LyX module in a LyX package, so I suggest > renaming the LyX.py module to the more specific lyxfile.py) Yes, something like that. > + from LyX import lyxfile > (and change of all "LyX." to "lyxfile.") > >> Not only that but I propose to move the lyx2lyx script from >> its present location to share/scripts. > > This is something we can agree on easily :-) > > >> 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 > > In the CVS, lyx2lyx (or pyLyX) is still a more transparent name than > "lyx-cvs/devel/lib/LyX/". Once installed, <python-site-lib>/LyX/ is > preferable. I agree. >> when you say a LyX/lyx2lyx sub-module, there is no need for it, we >> already have a LyX.File that does all the work for you. > > With a LyX package this would become LyX.LyX.File As I have told you I would remove the need for the middle LyX > I do not like the idea of a module LyX in package LyX. My suggestion is > to rename LyX.py to lyxfile.py. > > Also, I would like to "hide" lyx2lyx specific files (at least the > lyx_*.py version info files) in a subdirectory <site-lib>/LyX/lyx2lyx/ or > <site-lib>/LyX/format-info/. It is a question of internal organisation, but again I do agree with you. >> So clearly what we have to do is to agree on the python api to be used. > > Which means class names, file names and placement of files and > sub-directories (== sub-modules) under the <site-lib>/LyX/ package > directory. Yes. :-) >> 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. > > Or to do this transformations on the currently open document. > > from LyX import lyxfile, lfuns > > fname = lfuns.server-get-name") # get the current file's name there is an error somewhere, probably fname= lfuns.server_get_name() > lfuns.buffer-write() # save > > doc = lyxfile.File(fname) >> >> # transform it >> > # save it > > # Relaod the file (do not use "reload", as this is in reality a "restore") > lfuns.file-open(fname) The python names can not have - in name. >> Is this clear now? > > It is getting clearer and clearer. I hope we will finally sort out all > misunderstandings. Thanks for your patience. As soon as the code starts to get shape those issues will be solved easily. :-) >> This thread has expanded to some topics that are more >> appropriately discussed in the developers mailing list. > > Ok, so my answer goes there... Thanks. > Günter > -- -- José Matos
