Lock dependencies

[ysbaddaden]

Shards is missing a mechanism to lock the state of installed dependencies, so installs could be repeatable, always installing the same exact set of dependencies across developer machines, CI, ...

The format of the lock file is undecided. I think it should contain the flattened list of dependencies, along with their Git URL and either the version or Git commit (if a git tag/commit/branch refs is specified).

The lock file will impact the install command which must abide to the locked versions/refs and do its best to install new dependencies that match. The lock file may be seen as an initial set of requirements for dependencies —yet not be injected as dependencies, which could install removed dependencies.

The update command must not be impacted, but must generate the lock file.

[jhass]

We probably should also aim for defining a formal format for the lockfile in the midterm too so we can ease retaining backwards compatibility when we have to do changes or additions to it.

[ysbaddaden]

Yes, probably.

For now it's merely a list of dependencies with either a version requirement or a commit sha1. Maybe we should have them under a shards key instead? That would leave space to add other data (like a shards version number, or something).

[jhass]

Yes, that sounds like a good idea. Maybe we should just version the lockfile independently, so if worst comes to worst we can have entirely different codepaths for legacy versions.

version: 0.1.0
shards:
  - source: ...
    version: ...

Or so (didn't look at the current version tbh :P)

[ysbaddaden]

Almost:

version: x.y.z
shards:
  name:
    github: url
    version: x.y.z
  name:
    git: url
    commit: <sha1>