Shards: Set required crystal version

[r00takaspin]

Hello, is it possible to require certain or minimal crystal version in shards.yml?

For example, add option crystal_version:

name: sample
version: 0.1.0

authors:
  - somebody

crystal_version: 0.12
license: MIT

[ysbaddaden]

No. I thought about it, but it raises sone questions: shall we enforce it? how? or should we just display a warning when installing the dependency? or shall we discriminate when resolving?

Crystal changes quickly (until we reach 1.0) and libraries and apps must be updated on each release (almost). Maybe we should postpone such an option until Crystal stabilizes more, or maybe it can be useful, already?

I leave the question open so we can discuss it.

[r00takaspin]

Just playing with kemal based (sinatra-like web framework) webservice and I'd like to be sure, that it can be build again in long period of time.

Thanks for answer.

[matiasgarciaisaia]

+1 to enabling this dependency.

I think Crystal being quickly evolving is an argument _for_ implementing this. For pre-1.0 Crystal versions I wouldn't specify a _minimum_ version, but a fixed one - I know my shard works for Crystal 0.12, but I really don't know if it _will_ work for 0.13.

It's sad to checkout a project that doesn't compile as is - just because you never knew it's been developed for a previous language release.

Would listing crystal as a dependency work better than using a custom property like crystal_version?

[asterite]

I think it's good to know that a shard was developed against a specific crystal version. Then when it doesn't compile you can check what's wrong, and know what changes to apply by looking at Crystal's Changelog. But I wouldn't enforce anything: if you enforce a specific version, you are forcing all shards to update their crystal version number just so that they work... but it might be the case that they already work without modifications.

[matiasgarciaisaia]

How's that different with specifying other dependencies' versions?

[asterite]

The difference is that when you specify a dependency version, that version is checked out and required in the project. You can't checkout different versions of the compiler, you always have just one the compiler, the one installed in your system.

[bcardiff]

I would like to add it as a dependency. Maybe the crystal template can expand to the current version by default (or even with a >=).

In the future that crystal version can be used to filter feasible versions of each shard to be used.
But, definitely, at least for information purposes let's add a crystal: key to the shard.yml

At the end of the day is like adding the required version of the std. That been said, it could also be the case for the crystal key to appear inside the dependencies.

[asterite]

I've been talking a bit more with @bcardiff and I think this would be something very good to have. Basically, if a shard has set crystal_version: x then compiling with a compiler whose version is >= x will work, but won't otherwise. So if a shard is upgraded to the latest version and uses new compiler features, and you use an old compiler, you will immediately know you can't install that shard because it won't work.

Another use case of this is automatic documentation generators. Right now it's kind of hard to do because compiling old code with newer crystal versions might not work, so generating docs might not work. But if there's a language version set in a shard we can use the compiler for that version, and that's guaranteed to work.

I would even make this a required attribute of a shard.yml.

[jhass]

The semantic of x or later is sadly not very workable, the following situation shouldn't be too contrived:

• I generate a new project, crystal init writes the current compiler version into its shard.yml, I look at it but don't really notice that fact. At least I'm not aware of the semantic, I think stuff will notify me and forget about it.
• A new Crystal version is released and I update to it.
• My project no longer compiles, so I patch it to work with the new version. Unfortunately the changes are not compatible to the initial Crystal version.
• shards is still happy, the requirement is fulfilled. So I commit and push.
• The automatic documentation service, to stay with your example usecase, sees the push, looks at the shard.yml and sees the old Crystal version, so it uses it. And it no longer works because it got incompatible and I didn't update the version because nothing notified me of having to.

[bcardiff]

What you mention @jhass is something a the ci services could use, doesn't it? The default crystal version could be the one declared as minimum requirement in the shard, unless overridden somehow.

I agree that any check during dev will push you to use the oldest compiler you declare, which might not be that bad, but kind of awful.

I would feel comfortable leaving that check to the ci.

[ysbaddaden]

I propose to have a crystal: version entry in the SPEC, e.g., crystal: 0.19.1. A tool could understand the version as being = 0.19.1 or ~> 0.19.1, allowing to use 0.19.3 for instance. As for the libraries entry, it won't be enforced (as a dependency check), but optional and encouraged (crystal init and shards init should set it, maybe documented).

This entry could be understood as "the last crystal version that is known to work" or "the version that CI should use".

[rdp]

So there is no warning message generated for this yet, I presume?

[ysbaddaden]

No.