Make CLI-only features optional #62
Conversation
nyurik
force-pushed
the
make-cli-optional
branch
from
59831e2
to
009e2e7
Compare
This greatly speeds up build for the users of the lib when CLI is not needed. Sorry forgot to include it in the previous round.
nyurik
force-pushed
the
make-cli-optional
branch
from
009e2e7
to
3bd9627
Compare
Dynamically create image sprites for MapLibre rendering, given a directory with images. ### TODO * [x] Work with @flother to merge these PRs * [x] flother/spreet#59 (must have) * [x] flother/spreet#57 * [x] flother/spreet#56 * [ ] flother/spreet#62 (not required but nice to have, can upgrade later without any code changes) * [x] Add docs to the book * [x] Add CLI param, e.g. `--sprite <dir_path>` * [x] Don't output `.sprites` in auto-genned config when not in use ### API Per [MapLibre sprites API](https://maplibre.org/maplibre-style-spec/sprite/), we need to support the following: * `/sprite/<sprite_id>.json` metadata about the sprite file - all coming from a single directory * `/sprite/<sprite_id>.png` all images combined into a single PNG * `/sprite/<sprite_id>@2x.json` same but for high DPI devices * `/sprite/<sprite_id>@2x.png` Multiple sprite_id values can be combined into one sprite with the same pattern as for tile joining: `/sprite/<sprite_id1>,<sprite_id2>,...,<sprite_idN>[.json|.png|@2x.json|@2x.png]`. No ID renaming is done, so identical names will override one another. ### Configuration [Config file](https://maplibre.org/martin/config-file.html) and possibly CLI should have a simple option to serve sprites. The configuration may look similar to how mbtiles and pmtiles are configured: ```yaml # Publish sprite images sprites: paths: # scan this whole dir, matching all image files, and publishing it as "my_images" sprite source - /path/to/my_images sources: # named source matching source name to a directory my_sprites: /path/to/some_dir ``` Implement #705
There was a problem hiding this comment.
Just a small change required before this is merged (see suggestion below).
Besides that, it would be nice to add tests to check that Spreet still works with the CLI disabled. It doesn't seem like that's something Cargo supports particularly well, so my best idea is to mark existing tests as CLI-feature only, add tests to check use of Spreet as a library, and run cargo test --no-default-features during CI. I'm happy to try that out after this is merged, but if you have any better ideas let me know
|
Good point about the |
|
Thanks for your extra work in sorting out the tests. I've added a commit to add the docs you suggested on using the crate in I'll merge this now and flesh out the library-based tests in |
This greatly speeds up build for the users of the lib when CLI is not needed. Sorry forgot to include it in the previous round.
spreet = { version = "...", default-features = false }assert_fsdependency seemed not to be needed by the primary code, only by the testsclifeature