Am Freitag, 1. April 2016, 10:49:42 schrieb Jean-Marc Lasgouttes: > Le 31/03/2016 23:35, Scott Kostyshak a écrit : > > On Tue, Mar 29, 2016 at 12:53:15PM -0400, Richard Heck wrote: > >>> How about a "LyX layout repository" with supported¹ layouts at an > >>> "official" URL (something like www.lyx.org/ressources/layouts/ or > >>> similar, maybe with subdirs for major LyX versions, ...) as a first > >>> step? > >> > >> Yes, this is exactly what I had in mind, and I've been thinking about > >> how best to do it. We do not want to have to manage that directory > >> manually. The files are in the git repo, so we just have to figure out > >> how to access them. Some trickery using modrewrite might work. Or some > >> PHP code. > > > > Regarding version detection, do you have an idea for the implementation? > > (if you want, you can make a trac ticket regarding versioning and we can > > move the discussion there) > > Here is raw sketch of a possible scheme: > > Create a tree of layouts like > www.lyx.org/ressources/layouts/2.2.1/ > www.lyx.org/ressources/layouts/2.2.2/ > ... > > This tree could be a checkout of a special git tree. > > Each directory will contain the layouts available at current time for > the given version. This means that when we release, say, 2.2.3, we will > run a script that adds the new files to the 2.2.2, 2.2.1 and 2.2.0 > directories. In this way, each directory is self contained. > > Each directory will contain a contents.txt directory, containing lines like > <file name> <hash>
thank you, that goes very much in the direction i had in mind in an earlier
post.
we could borrow from R repos here, which are very similar to debian repos -- a
scheme with a lot of experience. they make a destinction between binary and
source packages:
bin/
windows/
contrib/
3.0/
myPackage1_0.1-1.zip
yourPackage_2.2-3.zip
...
PACKAGES
PACKAGES.gz
3.1/
myPackage1_0.1-1.zip
yourPackage_2.2-3.zip
...
PACKAGES
PACKAGES.gz
.../
src/
contrib/
myPackage1_0.1-1.tar.gz
yourPackage_2.2-3.tar.gz
...
PACKAGES
PACKAGES.gz
the client fetches PACKAGES (or the identical .gz compressed file), which is
similar to "contents.txt" as you proposed. as long as this only deals with
plain text layout files, one wouldn't need the binary branch. instead, all
relevant information could be found in the PACKAGES/contents.txt file. it
could look something like this:
Package: apa6
Type: Layout
Category: Articles
Label: American Psychological Association (APA), v. 6
Depends: apa6,apacite.sty,endfloat.sty,endnotes.sty,flushend.sty,txfonts.sty
Format: 49
MD5sum: f8c4c8727ddc6602cccb54d179704a82
Package: scrreprt
Type: Layout
Category: Reports
Label: KOMA-Script Report
Format: 49
MD5sum: f303b11685174ee0875e2df98b716301
Package: tcolorbox
Type: Module
Label: Fancy Colored Boxes
Description: Adds custom insets that support colored boxes via the tcolorbox
package. See the tcolorbox documentation for details.
Depends: tcolorbox.sty
Format: 48
MD5sum: db072df89a8a6d7cc27ea9e08b242a5f
which is all information that could be automatically extracted from the layout
files themselves. LyX version dependencies and version numbers for each layout
file could be added. i don't know if this would solve all problems, or wheter
adding a version string to each layout file would be an improvement or
introduce too much complexity.
just a suggestion.
viele grüße :: m.eik
--
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d-40204 d"usseldorf
signature.asc
Description: This is a digitally signed message part.
