One question about this, Matthew: should I ensure that all of the data files have distinct collection-relative paths, instead of making them all cldr2/data/json.zip?
On Fri, Mar 4, 2016 at 6:33 PM, Jon Zeppieri <[email protected]> wrote: > This sounds like a good approach. Thanks, Matthew! -J > > > On Fri, Mar 4, 2016 at 6:19 PM, Matthew Flatt <[email protected]> wrote: > >> Things that you want to access from a program should be based on >> collection, based on packages. In principle, packages don't exist at >> all at run-time --- and they really don't exist at run-time for a >> program bundled with `raco exe`. >> >> A good way to register extensions via the collection layer is to use a >> new "info.rkt" field. Each package can supply a "cldr2/data" collection >> directory, with an "info.rkt" file defining a field that lists the >> provided data files. Then you can use `find-relevant-directories` to >> find all the relevant directories (i.e., all the "info.rkt" files that >> define your new field). >> >> Another possibility is to use `copy-shared-files` in "info.rkt" to >> instruct `raco setup` (and `raco pkg install`) to install files in the >> "share" directory. In this case, I think the strategy that uses a new >> "info.rkt" field is probably better. >> >> One more piece of the puzzle: in the code that accesses the data files, >> use `define-runtime-path-list` to build a list of all the currently >> installed files. That way, `raco exe` will know to perform that >> computation at build time and pull along the relevant files. >> >> At Fri, 4 Mar 2016 16:58:15 -0500, Jon Zeppieri wrote: >> > I'm working on a new version of the CLDR (localization data) packages, >> with >> > the goal of reducing the amount of data that most installations will >> need. >> > >> > The packages are broken up into: >> > cldr2: provides functions for accessing the data and resolving locale >> names >> > cldr2-data-core: provides the data from >> > https://github.com/unicode-cldr/cldr-core >> > cldr2-data_<locale name>: one per locale, provides data from the rest of >> > the unicode-cldr repos, but only for the locale in the package name >> > >> > The cldr2 package depends on cldr2-data-core, but a user is free to >> install >> > as many or as few locale-specific packages as desired. >> > >> > The problem I've run into is how, at runtime, to find the data files I >> need >> > in a way that works during development. >> > >> > Each of the cldr2-data-* packages has a data archive at >> cldr2/data/json.zip >> > from the package root directory. So, if someone wants data from the core >> > package, we could do: >> > >> > ``` >> > (define dir (pkg-directory "cldr2-data-core" #:cache PKG-CACHE)) >> > ... [raise an exception if the package isn't installed] ... >> > (define zip-path (build-path dir "cldr2" "data" "json.zip")) >> > ... [open the archive and extract the relevant data] ... >> > ``` >> > >> > And that's fine, except that it doesn't work in development when using >> raco >> > link, because raco link manages collections, not packages. And I don't >> > think that collection-file-path is useful here either, since all of >> these >> > json.zip files have exactly the same collection-relative path. >> > >> > What's the best way to handle this? Should I just give the zip files >> > distinct names and use collection-file-path? Or is there a better way to >> > handle this situation? (I'm a bit reluctant to use collection-file-path, >> > since I think it searches the file system and so would be a bit >> expensive. >> > pkg-directory needs to parse the package catalog, but it allows the >> results >> > of that parse to be cached.) >> > >> > -Jon >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Racket Developers" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to [email protected]. >> > To post to this group, send email to [email protected]. >> > To view this discussion on the web visit >> > >> https://groups.google.com/d/msgid/racket-dev/CAKfDxxxywSUuR0j%3DM1sgU3foezz_jt3 >> > %2BAChNEqCO3SuqYtffRA%40mail.gmail.com. >> > For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAKfDxxxvT4ah_kq4g088_bGz7D%2BWUSDrhiSY1eqbr_%3D44kA%2B0A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
