Future of Kirby CLI

[benzin]

Hi there,

as I was using the Kirby CLI to update an installation the other day, I stumbled upon a bug I tracked down and fixed locally. I would love to share this, but when I had a look at the repository I found it rather inactive with some more bugs to be fixed and even some open PRs older than a year.

Now I was wondering, if it is worth making PRs and contributing to this tool? What is the road map for the CLI? What is its future? What are the plans for Kirby 3, maybe?

Would love to get some information regarding this

Cheers
benzin

[texnixe]

As far as I know, the Kirby CLI will continue to exist. Since I don’t have any more detailed information, I have invited @bastianallgeier to this thread.

I’d like to ask you to have some patience, though, because it might take a while until Bastian finds the time to answer this question.

[luxlogica]

We all LOOOOOOOOVE the CLI!

[benzin]

ping

[luxlogica]

I am training developers who are new to Kirby, and really need to know whether the Kirby CLI will be killed off, or not. Right now, we use it ALL THE TIME, and teach all new developers to use it as part of their workflow. Everyone loves it, and finds it easier to use than having to do the same installation/update/create tasks manually.

The point is: if the CLI is going to be killed off, I need to change our procedures - which will inevitably become a lot more complex for newbies… I know that the development of Kirby 3 is shrouded in secrecy and protected by a paywall, but would we be able to get an answer as to whether the Kirby CLI will live on?..

(…and I finish off by crossing my fingers and hoping that the answer is going to be ‘yes’!).

[jenstornell]

I understand your position. It’s always extra work to change workflow.

I see two reasons why it still may be good to deprecate Kirby CLI:

1. @bastianallgeier is only one guy. Do we want his effort to be on Kirby CLI or on the CMS itself? I would choose to have him work on the CMS.
2. Composer is almost a standard where almost every repo can be installed with Composer. If that would be used instead, then we don’t only learn how to install and update Kirby. We can use this knowledge outside Kirby as we learn to install and update almost every repo out there.

So my vote goes to keep as much side projects as possible out of the way. That includes things like Patterns and other plugins as well.

Then we will get the best CMS ever made!

[luxlogica]

I agree that when resources are limited, it’s best to focus our efforts on the things that are important. The question then is: how important is the Kirby CLI for the Kirby project itself?

Even more to the point: is the Kirby CLI a ‘side project’, much like a theme or template, or is it an integral part of Kirby, much like the Kirby Toolkit? Many CMSs take the approach that these command-line tools are actually an integral part of the CMS, and essential for attracting the pro users - indeed, we cansee CLIs everywhere, from Drupal to Grav.

As far as using Composer, or any other set of tools to ‘replace’ the Kirby CLI, IMHO that is not a very elegant or practical solution, because the CLI already does more than each of these tools alone can do - for instance: we can use the CLI not just to instal and update kits and plugins, but also to generate blueprints, controller files, etc. The same could be achieved either manually, or by using a combination of other tools, but the whole point of having the CLI is precisely to be able to do it easily - something that is important to the pro user.

The Kirby CLI is indeed a wonderful, valuable tool, and it would be a shame to see it die…

[jimbobrjames]

Let’s assume the CLI did fall by the way side in favour of concentrating efforts in better places, there are tools out there that could replace it. It’s possible to create your CLI tools with Node. If you feel up to it, you could roll your own CLI.

I looked into it as I wanted CLI tool for my framework. Theres a good guide here and a couple of libraries for making CLI’s:

Commander
Inquirer
The Open CLI framework
Vorpal

At least if you rolled your own, it’s future would be certain

[lukasbestle]

We have not made a final decision on the CLI yet. However I can tell you this:

Installing and updating Kirby

We are working (right now actually!) on massively simplifying the installation of Kirby 3 with Composer.

As Composer was built to be a package manager in the first place, it is a lot more robust and reliable than than our CLI. Also, Composer can already be used to install Kirby plugins that support it as well as other libraries as @jenstornell pointed out, so it doesn’t make any sense to re-invent the wheel and maintain our own installation method.

Our goal is to make Composer work out of the box without much manual configuration. Let’s hope it all works out nicely. If it does, we will support that installation method officially and also document how to use it.

In that case, the Composer installation method would replace the respective CLI features as it’s just the better solution in our opinion. You will see once we got it working.

Other CLI features

The features that can’t be provided by Composer are:

• creating a new site by setting up a starterkit/plainkit/langkit as well as
• the several make/delete/clear commands.

I myself haven’t used those features in the CLI as creating or deleting those files yourself takes just a few seconds – pretty much the same time you need to type in the CLI command if you factor in that you need to navigate to the directory in the terminal first each time you work on a different project.
Creating a new site just means downloading a ZIP from GitHub and extracting it. The CLI doesn’t do it differently. And if you already have your own site template, the CLI can’t help with copying it anyway.

Your opinion

But that’s just my opinion. I would like to know how many of you use the additional features of the CLI at the moment:

• Yes, I use the additional CLI features regularly.
• No, I don’t use the CLI because of those features. I only use it to install and update Kirby.
• No, I don’t use the CLI at all.

If you voted for “Yes”, I’m also interested in your workflows where the CLI can help you and why you use the CLI for them. Thanks in advance!

[texnixe]

Roll your own is probably not an option if you regard the CLI as an integral part of a CMS. And we all know how it goes with plugins/third party tools: if the developer doesn’t have the time to maintain it or loses interest, these things are abandoned, which doesn’t make sense for things that are part of your workflow.

Personally, I use the CLI a lot, but only for its core functionality which can probably easily be replaced with something else. For the rest, I always found the CLI lacking functionality. Creating single blueprint/template/controller files is not really faster than creating these files in the filesystem or in an editor.

However, I’ve really gotten used to installing plugins via the CLI and I’m not sure that I’d love adding these as dependencies to a composer file first… but this is probably a very special requirement in the support context.

The CLI as it currently exists would only make sense if it would see those enhancements, for example, taking a list of files to create or create a whole set of files.

[jimbobrjames]

@texnixe

Roll your own is probably not an option if you regard the CLI as an integral part of a CMS. And we all know how it goes with plugins/third party tools: if the developer doesn’t have the time to maintain it or loses interest, these things are abandoned, which doesn’t make sense for things that are part of your workflow.

Sure, with the best intentions in the world, people eventually loose momentum and things get abandoned. However, @luxlogica is working in a team that have grown to rely on the CLI as a key part of the teams work flow. I suggested it as it seems his team has a vested interest in creating and maintaining such a tool internally to help them.

@lukasbestle I had to vote no, but I would 100% use the CLI (To maintain and install Kirby, not so much with creating controllers and blueprints etc. It’s faster to just do that in the editor). The reason I don’t use it is because at the time I tried it out, it wouldn’t work for me because I keep all my sites on a dedicated hard drive. There was an issue in the CLI that meant it failed to move packages to another volume. If it wasn’t for that i would totally use the CLI.

[lukasbestle]

@texnixe

However, I’ve really gotten used to installing plugins via the CLI and I’m not sure that I’d love adding these as dependencies to a composer file first… but this is probably a very special requirement in the support context.

Composer has a command that installs a package and at the same time adds it to your composer.json for you, so it’s the best of both worlds:

composer require someone/some-plugin

[texnixe]

The good thing about the composer approach is that you have a file with all your often used dependencies - Kirby or not - that you can then reuse in new projects, which is great.

[lukasbestle]

@jimbobrjames

The reason I don’t use it is because at the time I tried it out, it wouldn’t work for me because I keep all my sites on a dedicated hard drive. There was an issue in the CLI that meant it failed to move packages to another volume. If it wasn’t for that i would totally use the CLI.

That’s exactly why we are now evaluating Composer. It has been battle-tested over the last gazillion years and won’t have any of those strange issues.

[luxlogica]

Where we have found the Kirby CLI to be most useful is when introducing Kirby to new developers. When a programmer is new to Kirby, having the CLI showing you where to instal things, and how to start files, is infinitely faster than having to constantly look things up in the docs. Example: we found that a new dev will frequently use the CLI to get a new blueprint started, as it already initialises it with all the options, which they can they customise by hand. It’s much faster than having to start a blueprint from zero in their text editor, and then have to look up all the page/subpage/file options in the docs. If anything, it would be even more helpful if more options and more wizards could be added.

Similarly, when installing and updating plugins, a new developer will often use the CLI (if the plugin supports it), as it will instal the plugin in the right locations - ie, plugin folder, field folder etc. - and saves time having to read the plugin docs. Especially when updating.

Once a developer knows Kirby inside out, they will often start a blueprint from zero - because they already feel confident they know all the options by heart - if the page is simple (not too many options) - but in our team, as Kirby is not the only CMS we use, even our experienced devs go back to the CLI when creating a blueprint that we know is going to be complex - it gives us an extra level of security in knowing we’re “doing it right”.

All of this can be replaced with alternatives. Composer can be used to instal and update kits and plugins. We can create our own ‘template’ files for blueprints, controllers, etc., which the team can use as a starting point. None of those options, however, is as easy and straight-forward as the CLI. Consider that it takes a developer literally 5 minutes to read through all the available commands on the CLI, and compare that with how long it takes for someone to learn to configure and use Composer appropriately.

IMHO the existence of the CLI is indeed a contributing factor for teams like mine in the choice of Kirby as a CMS, as it reduces both training, and project maintenance time - and helps make new developers more productive, quicker.

I know, however, that the Kirby team puts a lot of thought in their decisions, and trust that whatever the decision will be in regards to the future of the CLI will be ultimately the correct one, and a positive one for Kirby.

[jenstornell]

If going with Composer… The docs for Kirby + Composer may be be as simple as the docs for Kirby CLI (on install/update).

About the blueprint generator thing, maybe there is a good replacement for that as well. Then you would have Composer for install/updates and something else for file add/delete/edit. I don’t know what would be good for that. I’m thinking node.js, bat-files or plain php scripts, maybe even Kirby plugins. Whatever it might be, I think this part could be done by third party developers. Then we could have more choices to pick from. Sure, they can abandon the project, but then new ones can pop up in their place. For a company that relies on a plugin, they can keep it around as long as it works.

About Kirby CLI, the license is already MIT so anyone who wants could take it and make an own thing, like making it work with Kirby 3. Just be clear that it’s not made by the official crew and pick a new name for the new fork.

[lukasbestle]

@luxlogica

It’s much faster than having to start a blueprint from zero in their text editor, and then have to look up all the page/subpage/file options in the docs.

That’s a good point.

@luxlogica

Similarly, when installing and updating plugins, a new developer will often use the CLI (if the plugin supports it), as it will instal the plugin in the right locations - ie, plugin folder, field folder etc. - and saves time having to read the plugin docs. Especially when updating.

Installation to the correct locations is already possible with Composer if the plugin supports it. We are working on a plugin boilerplate for Kirby 3, which will include this feature. Let’s hope that more plugins will support it in the future.

@luxlogica

Consider that it takes a developer literally 5 minutes to read through all the available commands on the CLI, and compare that with how long it takes for someone to learn to configure and use Composer appropriately.

It’s basically the same. You will see.

@jenstornell

About Kirby CLI, the license is already MIT so anyone who wants could take it and make an own thing, like making it work with Kirby 3.

That’s true. I agree with @jenstornell that more choices regarding helper CLIs for Kirby might be a good thing actually. The workflow of different users can differ quite a lot. Some might want their CLI to create basic template files, some might want a very detailed wizard, some might want the CLI to use their own custom template file collection.

I think that all those workflows differ too much to cram them into just one tool as you can see in the GitHub issues of the CLI. So I think it’s better if we focus on making the installation of the CMS and plugins with Composer simple and reliable. The other features of the CLI aren’t really something we can do well in “the one official CLI”. So my current opinion is that we should discontinue the CLI. What do you think?

I have also invited @bastianallgeier to the discussion again.

[bastianallgeier]

Hey everyone!

This is a really great discussion and it’s good to hear about the different backgrounds why the CLI is helpful or not. We have completely neglected it while working on v3 and I’m very sorry about that. The CLI is a good example where it felt like we have to provide that as an official feature and it was easy to create the first version, but it turned into a huge extra burden. With a paid product we are often facing the problem of no clear path forward for the community, when it comes to core contributions. With an open-source project, probably someone would have already picked the CLI up and moved it forward. But I guess even though with the CLI being released under MIT, it’s often tough for you to join in and pick it up, because you somehow contribute to a commercial product without getting something back.

With the shift to composer we can outsource a lot of the CLI problems to composer, as @lukasbestle already said. It’s mostly about making the installation and update process really solid. Even though the CLI is running fine in most cases, there are so many edge-cases and it’s a nightmare to handle those on our own.

I never used the generation tools personally, but it’s great to hear that they can be so helpful. Especially to onboard new developers.

My ideal situation would be the following:

1. We give the CLI to the community and help to build and maintain it as good as we can, but the community is handling it as a 100% open-source project and without us being the gatekeepers

2. We provide composer support for v3 out of the box and it would be fantastic IMHO, if the cli could become a wrapper around that, by just calling the composer commands more or less. (not entirely sure if that’s possible, but I guess it should be) So in theory kirby install, kirby update, etc. could still work, but with a more reliable composer backend.

3. All the build commands are handled in the CLI and the CLI can also be extended to run custom commands.

To me, this would be the most future-proof way of keeping it going. What do you think?

[bastianallgeier]

Oh, maybe one more thing because @luxlogica mentioned us developing Kirby 3 behind a paywall. We will have a public beta without a paywall as soon as it is stable enough for everyone to join in testing the new version. The paywall is really just there to keep us running financially.

[fabianmichael]

@bastianallgeier

We provide composer support for v3 out of the box and it would be fantastic IMHO, if the cli could become a wrapper around that, by just calling the composer commands more or less. (not entirely sure if that’s possible, but I guess it should be) So in theory kirby install, kirby update, etc. could still work, but with a more reliable composer backend.

I’d prefer than, because this would make it possible to use Composer for all things it can handle better than our own implementation. But instead of being limited to Composer’s features, it would be easy to add commands that can leverage Kirby’s built-in API methods for e.g. creating new pages or similar tasks. I also think that there’s great potential for having an extensible CLI for doing heavy-lifting operations via cron jobs. I could think of features like preloading the cache, optimizing thumbnails, creating backups, refreshing search index or fetching content (e.g. social media stats, rss feeds) from remote services which could take too long for a regular page load. This pattern is used by other PHP software like Nextcloud, Tiny Tiny RSS or WordPress (only if you activate it) and works pretty well for them. However, this should stay optional keep the basic setup of Kirby as simple as possible.