The tool has not changed since quite a lot of time, that’s why the goal of this poll is to have an idea of its usage and what the Crystal users would like.
How do you use crystal init?
I use it, and it is fine as-is
I use it without Travis CI, and that’s fine
I use it, but I wish it had more features (CIs, licenses…)
I don’t use it, or prefer using third party tools [1]
oh, I read that wrong. I don’t use Travis, but I’d be ok with there being either no CI generated, or a way to configure which CI stuff is generated (and whatever other options)
For Lucky, when you generate a new app, we actually run crystal init first, then just slap some new files on top. But all new Lucky apps are generated with both travis and Github Actions now by default.
I would personally like to see some cli that could be used as init & generator that could be used for different frameworks and types of projects. But I am not sure what is the ideal design of such tool to allow project template, and expansions on existing code bases.
Without such a tool I think that any improvement to crystal init is not a real game changer.
I know there will always be guides here and there for how to do X, but crystal init serves that directly to the user and it reduce the burden.
Although Github Action is a very attractive option for github repos the setup for travis is still the simplest one to start with.
But a CI is not needed at all to get started with Crystal. Is it really used by beginners when they try locally to have a working Crystal program?
CI, license, README are welcome, are a good practice of course, but not essential to get started.
In a sense, all of this could even create noise when the goal is to have a minimal working project.
If it’s easy to delete files, why use the tool at all? Just copy another project of yours and delete some files.
(And I’m not even sarcastic, that’s what I do, anyway)
As a basic summary, what we can know from the poll:
people use crystal init (as expected)
for most people, the command does not fit exactly their needs (fine or not with it)
roughly half the people are fine with the tool in its current state
roughly half the people are not really fine with the tool for its lack of features
Overall, adding more features can be beneficial for most of us, if the current ones are still present to satisfy those being fine with the current situation.
What’s remaining to decide is the hardest part: what to do? It can prove to be a challenge to have a more complex tool, yet still simple, remaining inside the compiler (or not, like shards?).
Maybe this is “childish”, but crystal initactually opened me the world of unit tests and CI. If, hypothetically, there would be a configurable tool, that asked me for exact features i want to use in project, then my answers (from the time I first met Crystal) would be “Mercurial VCS/GPL license/test framework:none/CI:none”.
But the crystal init didn’t ask, so i started to use github because it was already configured, started to write tests because it created a dir with the files, and then started to use CI because it wasn’t a strange combination of words anymore, but already configured thing and i just have to do few clicks in web interface to make it work.
That’s why I consider not giving a choice as a good thing for newbies. More advanced tools that allow to select any aspect could be useful, but crystal init that is shipped with language and is a default choice for any tutorial imho is good as is - just works without asking single question.
If we continue your logic, this would be better to provide a GitHub Actions template than a Travis CI one, because working out-of-the-box in GitHub (most Crystalers use it rather than Travis for their new project on GitHub).
We can’t say that git is “better” than mercurial or MIT is “better” than GPL. In a way, mercurial is even more user-friendly than git.
Also, as I said above, having good defaults and advanced features can perfectly fit on a same tool.
There is also something lacking on the current tool which is very useful and widely used: API docs generation deployed in gh-pages.
I would try to keep the compiler tool as minimal as possible. The current scope is pretty neat. It could use some refinements to improve some aspects. But I don’t think big changes would be good.
I wouldn’t want to introduce complex features like templates. That should better be a separate tool.
Yes, it could go into one, but focusing on small feature sets (aka Unix philosophy) is probably better.
@konovod Thank you for your comment. I think that perfectly summons the most important purpose of the init tool
The tool could be on a separate project then, like crystal deps → shards? Clearly, as we can see from this poll, people are seeking additional features. I agree with you not to bloat the compiler with unrelated things from the language itself. If it was only me, it will remain only the compiler and the formatter (like in most languages out there, except the later)
I don’t see major disadvantages of having a dedicated command vs a subcomand, only one more package to install.
