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/CAKfDxxy4C5m4%2BNE950%2B42HE7MLKDCdHoJKWfREHrAp87Lj%2BSuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to