Crimson is a version management tool geared towards people working with multiple versions of Crystal, compiler development and much more! With it comes a set of easy to use commands for managing and debugging/testing versions, giving you more time to focus on the code. Crimson is available on Linux and Windows (x86_64) with MacOS support coming soon and ARM support being planned, see the README on how to get started!
Any and all feedback is much appreciated, happy crystalling!
There is no doubt that many people are looking for a version manager like Crimson.
I want to give positive feedback, but I feel that I need to be direct with Devonte. The main reason I don’t want to use this version manager is that it depends on Cling instead of the standard library’s OptionParser.
Basic tools like this are expected to work for at least 5 years, ideally 10 years. So, I focus more on how long the project can last rather than the idea or convenience. For this, it’s important to use the standard library as much as possible, making it easier for others to maintain, contribute, and provide feedback on the project.
Some tools that didn’t follow this idea have still become popular. However, their authors maintained them for 5 to 10 years, proving to others that the project would continue.
What people want from an OSS project varies from person to person. Sometimes, it’s just a hobby. But generally, a version manager doesn’t have much meaning unless it becomes somewhat widespread.
If you’re aiming for that, please keep working over the next few years.
13 posts were split to a new topic: Issues with Crimson on Windows
Actually, I have some doubt. Or rather I’m wondering who needs a version manager (for Crystal and in general) and for what purpose.
I don’t really use global version managers at all, neither for Crystal nor anything else. So I guess I’m just curious.
If I need to pick specific versions of a development tool, I put that into project-specific configuration via https://devenv.sh/ or similar tools. That’s convenient because it manages all environment dependencies, not just a compiler for a single language. Often I also need other tools as well (e.g. linters, db clients etc.), so I guess that would otherwise require to use multiple version managers? 
That’s quite a strong opinion. I dig the general sentiment of basing on stdlib as much as possible.
However, option parsing is not a core feature of the tool, and a stable parsing library should not require much maintenance. So I think it should be fairly reasonable to assume that Cling could easily be used for an extended amount of time even if it receives no upstream updates (and it shouldn’t be hard to patch bugfixes if necessary). And in the worst case, exchanging the CLI parsing library with some other library that does the same job should be a relatively simple task, so if push comes to shove there’s not much cost associated with switching.
A older working project use Crystal 1.9.2, current Crystal version is 1.14.0, if want to play with that older project, you need do two things:
This is what asdf wants to do, but, asdf only support linux/macOS, Crimson filled the gap.
If I need to pick specific versions of a development tool, I put that into project-specific configuration via https://devenv.sh/ or similar tools.
What are you talking about? same things as .tool-versions in asdf? you can’t assume that everyone likes NixOS.
I agree, for projects I usually want a full environment (e.g. nix, docker) because crystal likely ain’t the only thing you need, and it’s better to have a replicated environment for anyone to start.
Now, I guess a version manager can be useful when you need to test with a specific version of crystal and don’t want to bother with the whole download, install, or updating your project?
Yeah, I presume .tool-versions serves a similar purpose. It’s not the same though because asdf is limited to making applications available at certain versions. With devenv.sh for example you can manage much more of your develpment environment (e.g. language config, processes, services, pre-commit etc.)
The great thing about these tools is that they’re non-intrusive. If I happen to use a specific management tool, the config will automatically work. If not, it doesn’t disturb anything. And you could use configs for multiple managers in the same repo.
Impressed, I think you’re introducing nixOS, in fact, many friend have been recommending it to me, will try it out sometime.
But, as i said, you can’t assume everyone like/know use NixOS like tools instead of version manager.
No, you’re misinterpreting that. I’m talking about development environment managers in general. Some of them are based on nix, but the same applies to other base technologies as well.
Is there actually something preventing the 1.9.2 project from working with 1.14.0? Unless you managed to hit one of the documented breaking changes edge cases, I’d expect it to just work out of the box. If it doesn’t then there’s likely a regression.
Cling is not a new project. It was created just over 2 years ago out of my frustrations from OptionParser and macro-based CLI shards and was designed to incorporate the same features as the existing shards with a foundation for new, non-breaking changes to be built upon it. It’s had a lot of criticisms and feedback during this time which has allowed it to get to where it is now; I have no doubt it is stable and contributions will continue to be welcome.
Updates to Crimson will come as and when they need to. I will not push pointless commits and releases for the sake of activity or to satisfy people’s perception of “alive”/“dead” projects. No one is forced to use Crimson, and you take the same risks you would for adding any other tool or dependency to a project or development environment. The tool will prove itself capable or not for your needs.
This statement seemed very contradictory to me.
But the next moment, I realized that maybe I’ve just gotten older. A frightening moment in life!
This is a good wish, if it can be achieved then that would be great, but I don’t think it’s possible.
Is there actually something preventing the
1.9.2project from working with1.14.0?
this is one of the example.
Very interesting, I have been using Linux for about ten years, I haven’t tried it yet.
Yea this was a bug fix where Lucky was depending upon the faulty behavior. These things are bound to happen every now and then. In a perfect world the issue would be identified in nightly CI and a patch release released to handle it shortly after. This way from the user’s perspective there is no problem between Crystal versions. I think it also depends on the project. The more complex it gets, the greater surface area for these things to appear.
So I guess what I’m trying to say is it would be best to default to using the latest Crystal version as it’s very likely going to be fine, vs coupling every project with a specific Crystal version just because of a one-off issue with one project.
I put that into project-specific configuration via https://devenv.sh/
This is cool. It seems like a very futuristic tool to me.
I thought about why people use global version managers.
In my case, I use rbenv to install new versions quickly. For example, when Ruby 3.4 is released, I can test it immediately and switch back if necessary. Also, I can run rbenv install ruby-dev to quickly install a development version of Ruby and revert it whenever I want.
I think it would be interesting if the same were possible for Crystal (though maybe there’s already a good way that I don’t know about).
Additionally, I find it useful for quickly checking whether a small Ruby library I maintain works with different versions of Ruby.
Finally, I think there are some differences between application development and using scripts for research or data analysis.
Many people around me use package managers such as Mamba or Anaconda. However, Anaconda is more than just a Python version manager, so comparing them here may be unfair.
This might be slightly off-topic, but I recently realized that Crystal one-liners are incredibly powerful when processing text files that are several gigabytes to 100 gigabytes in size. A process that takes 40 minutes in Ruby often finishes in 10 minutes with Crystal. With this much difference, the compile time doesn’t matter at all. Many people might think that Crystal’s slow compile times make it unsuitable for throwaway scripts, but I don’t think that’s true. However, I agree that this use case is not very common.
It’s worth installing Crystal globally in my local environment.
There’s no doubt that you have a very interesting talent, but I get the feeling that you might be a lot younger than I imagined. Do what you want and get lots of experiences. As for my comments, it’s fine if one day you just think, “There was someone who said something like that once.”
I usually prefer “generic” version managers like mise or asdf. One tool to learn. Although they are not available on Windows, I know of other new generation version managers that supports it, like VFox (Lua based plugins) or Proto (WASM based plugins)
For instance, I found vfox-crystal. Haven’t tried yet. Regards
