-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manage compiler dependencies with shards
#14363
Comments
This is a huge 👍 from me. I guess I was too early when I proposed that 5 years ago. Let's treat the compiler as a regular crystal application already. |
Trying to do this with the current declared versions in the respective name: Crystal
version: 1.12.0-dev
authors:
- Crystal Team <crystal@manas.tech>
dependencies:
markd:
github: icyleaf/markd
version: "0.4.2"
reply:
github: I3oris/reply
version: "0.3.0"
license: Apache-2.0 It looks like neither dependency matches exactly. To avoid breaking existing code, we might as well update those dependencies to include at least these patches:
|
The currently installed version of reply is a bit weird as it does not match any commit in the main branch exactly. But I3oris/reply@90a7eb5 is functionally equivalent with no relevant changes. |
@ysbaddaden I suppose the selling point would've been that we can just keep |
I'm stubborn, maybe we'll drop the More seriously, both dependencies are external to |
Yeah, I've recently thought about whether checking in |
The compiler has two external dependencies vendored in at
lib/
:reply
andmarkd
.To keep these synced with upstream, we use
git subtree
. Or at least that was the plan. It was never setup forlib/reply
.And while it's not terribly complex to setup and maintain,
git subtree
adds some overhead and it's not very straightforward to understand what's going on.In the Crystal ecosystem we actually have a great tool for managing dependencies:
shards
!Now of course the compiler should not require
shards
for building to avoid circular dependencies. But there's no need to. If we continue to keep the lib sources vendored in the repository,shards
is only used for updating the sources. That would be a simpleshards update
then. Compare that with the commands forgit subtree
which I'm far from being able to recall from the top of my head. Of course, that could be automated. But the point stands thatshards
is just so much easier to use. And you have the full features available to check which versions are installed, check if they're outdated etc.We should expect compiler dependencies to be published as Crystal shards, so this should work with any future additions.
So here's what I'm proposing:
shard.yml
into this repository with declared dependencies ofreply
andmarkd
at the currently installed versions.shards install
and there should be no difference in thelib/
folder except a newlib/.shards.info
file (which will also be checked in like the rest oflib/
, andshard.lock
as well)The text was updated successfully, but these errors were encountered: