Closed bcardiff closed 4 years ago
Should we really touch the regular lock
opposed to creating a shard.override.lock
or not writing down the overrides at all?
If I have to take care to not commit the dirty lock, why have a separate file for overrides in the first place? It could just be section in shard.yml
then, there's no difference to partially committing one or two files.
OTOH what's wrong with committing the overrides file and the lock changes from that? If collaborating on a project with outdated dependencies (the primary usecase for this), why should everybody have to redo the overrides?
This whole flow with additional file seems wrong to me. I'd rather take inspiration from Elixir (already mentioned) instead, KISS plz.
@jhass in theory there is nothing wrong with committing the override and lock with overrides. That should be done if the overrides are required for an app to work. It happens that I have more present the workflow of temporal overrides to fix things.
If the story for sharing overrides, or forcing some resolution without warnings is wanted the last proposal of the proposal in #412 can be implemented later:
The only scenario where a forced dependency should be tracked is on application
shard.yml
. In this case, dealing with additionshard.override.yml
seems like a reasonable compromise.If we want overrides to be in the
shard.yml
we would need anoverrides:
orresolutions:
sibling todependencies:
.# shard.yml dependencies: bar: github: bar/bar resolutions: foo: github: non-main-author/foo
This is similar to what is done in yarn. It would offer a slightly cleaner solution to the scenario where a team needs to share overrides. Here, there would be no need to add a warning in the
shard.lock
file. If wanted, this extension can be introduced later.
I think that having another lock file will generate confusion. The lock can be used as the source of truth for reinstalling the dependencies, if there are two, then there is a logic need to choose.
@Sija in #412 I mention that adding a forced or override attribute similar to Elixir one is not backward compatible and we will be forced to add a version in the shard.yml. The alternative is to override as in Yarn which I mention. Having an additional files allows per-user customization similar to Bundler which I've found convenient to work with custom forks and local paths.
This is a very useful feature but it's currently not easy to find via google – I arrived here by following a trail of issues.
This may be related to the shards command page being outdated and not linked to the man page? /cc https://github.com/crystal-lang/crystal-book/issues/476
Implements most of #412 .
Reads a
shard.override.yml
(or the file specified bySHARDS_OVERRIDE
) to override the source and restriction of a dependency. There are no changes regarding CLI options of shards.This allows the cases described in the motivation of #412
Usage sample
On a project that uses
github:crystal-lang/crystal-sqlite3
it will current usecrysta-db 0.8.0
.Let's suppose I need to work on a fix for
crystal-db
. I can create ashard.override.yml
file pointing to my working copy ofcrystal-db
Execute
$ shards update
to change the installed and locked version ofcrystal-db
. (Note: if$ shards install
is used instead of update, the use will get an error regarding that db has ambiguous sources due to the existing shard.lock and the shard.override.yml)After this update you will have a symlink to the /my/path/to/crystal-db
And the
shard.lock
has some comments to clarify if the lock was computed with overrides and will not be safe to commit.Note that in this example we also bump
crystal-db
from 0.8 to 0.9 despite the fact thatcrystal-sqlite3
requires~> 0.8.0
. So we are overriding the requirements along the dependency graph.You can override to a specific version, branch, fork, local path and solve ambiguos reference in case the ecosystem do not agree what is the main fork for a shard name.
Having a
shard.master.yml
will all dependencies to the master/develop branch will simplify how to check if you the project is up to date with non-released changes of dependencies.Closes #412 Closes #105 Closes #299