Shards 0.9.0 (release candidate 2)

News
1

I fixed some issues in the upcoming version of Shards, which features a complete overhaul of its internals compared to v0.8, allowing to add:

  • official support for pre-releases version numbers, for example 0.9.0.rc1 or 0.9.0-alpha;
  • a smart dependency resolver with conflict handling (using a SAT solver), no more try the latest and be lucky or fail miserably when a tiny conflict arises;
  • update selected dependencies only, trying to be as conservative as possible, not every single dependencies;
  • the --local flag that won’t fetch Git repositories (assumes local cache is up-to-date), for incredible-speed lock, install and update commands.;
  • the outdated command to list dependencies that can (should) be updated;
  • the lock method to generate/update shard.lock without actually installing the dependencies;
  • see the CHANGELOG for the whole list of changes.

Please test this release candidate extensively!

10 Likes
2

These are very cool additions! Pre-prelease versions rock :metal:

However I can’t think for a usecase for --local flag. Why would we need that? What’s the local cache? An OS-wide or the project lib folder?

3

ls ~/.cache/shards/github.com/

It’s a cache of the shards you installed before. I.e. would grab them from that directory, vs going out to refetch them from Github.

1 Like
4

The shards’ cache is alongside the crystal cache (usually ~/.cache/shards). Its where Git dependencies are cloned. Whenever you run a shards command that involves dependencies (except check) it will always git fetch each and every dependency, which can quickly become very slow and annoying.

If you believe the local cache should be up to date, then you don’t necessarily need to fetch all those dependencies again and again, and can just try a quick shards update minitest --local for example.

2 Likes
5

I’m interested in the solver itself for Mint since I wrote a naive solution for it. Is there any chance it can be separated into a shard somehow? :smiley:

It would be more awesome if it would be a general package manager which can:

  • clone repositories and gather dependencies based with a custom method per repository / version
  • solve the dependencies and call a method with every repository / version - so we can use them somehow
  • save and manage a lock file
  • have API for updating and such
2 Likes
6

It seems a bit odd to store the files “somewhere else” than the project themselves. Maybe instead of ~/.cache/shards it could just use a local dir like “.shards_cache” for the cache? Just thinking out loud, it might be less shared between projects but make more sense to beginners :)

7

The actual files are checked out in the lib folder of each project directory. ~/.cache/shards only contains bare git repositories and caching them centrally makes much sense to reduce unnecessary duplication. There should be no downside to that approach and the user doesn’t even has to bother about this (at least until the cache directory fills up the filesystem…).