Johannes Müller

Yes, I think every non-trivial shard would benefit from using a build system for such tasks. Ideally `make`, because that has most widespread adoption.

It's not super trivial. `shards build` arguments are very simply: any argument starting with `-` is forwarded to `crystal build`, any other argument is treated as target name. If we...

I can't make any sense of that. What would be the use case? The OP mentions the use case of putting build artifacts in a destination directory for a snapcraft...

@luislavena You can already do everything you mentioned. ```console $ shards build myapp --cross-compile --target=aarch64-linux-musl -obuild/arm64-musl/bin/myapp Dependencies are satisfied Building: myapp cc build/arm64-musl/bin/myapp.o -o build/arm64-musl/bin/myapp -rdynamic -L/home/linuxbrew/.linuxbrew/lib -lpcre -lm -lgc...

https://shardbox.org/ has some more statistics, including some of what you're mentioning. There are tons of more metrics available but not exposed in the UI yet. Needs somebody to implement it.

There's no need for a centralized registry to track vulnerabilities. It might actually be even better to have an advisory db separate from package discovery. Essentially, such a db is...

Ah, somehow I missed that. Thanks for pointing it out. The example in the linked comment should also work with `shards version -C __DIR__`, for example. Or maybe just `shards...

For backwards compatibility, it could even treat `` as a path if no dependency with that name is specified (and the path exists, obviously).

I would suggest to close this issue in favour of a more general approach to querying information (including the version) of installed shards (see https://github.com/crystal-lang/shards/issues/86#issuecomment-588208805).

> if the HEAD is now tagged with v0.1.3 Shards will raise the warning about a mismatch between the tag and the version in the spec. Sure, in a tagged...