Well, I think Composer is great because of DRY. There is already a package manager for PHP, why create another one that every user has to install?
The composer.json won’t be a requirement in any way and the package management should be in a plugin in my opinion. Kirby won’t force anything, but I think it just makes sense at the moment.
Not sure, if I get your point completely. I mean, this so-called “packages manager” plugin is not really a manager, merely a widget atm to list all plugins, to check their versions and display that information visually within the panel… who knows what else in the future. I’m not really heading for an install/uninstall mechanisms. I think Bastian wrote somewhere why he won’t include that into Kirby, if I remember correctly. And I have no aims for a plugin that does that for the same reasons.
Given the discussions here on the forum, I would suggest that there are quite some Kirby users that would rather install such a widget before ever using something like composer to manage their plugins. I would see the widget in that corner.
However, my main aim here was to just code something fun to actually see how we can get Kirby plugins on some common paths… finding some standards or so. I see the point that if some developers are actually using composer to install plugins and update them, why not choose composer.json as the foundation. Developers would make their plugins available for composer in that way and even if a user just downloads it from github and moves it to the plugins folder, the json file is still there for such context information.
Maybe you refered to this one:
Maybe you will not like it, but I’ll share my thought anyway…
Blueprints have two formats, PHP and YAML. Depending on the user need one of the languages is used. Kirby can handle both.
The package manager could look for the info-file in both formats and pick what is available. If there is a YAML file, use that. If there is a JSON file, use that.
Pitfalls with it could probably be schizophrenia and longer download time from Github. The benefits would be that people who don’t like JSON or Composer can use YAML instead.
The important thing is that the keys are the same. “version” should be called “version” in both formats.
One little suggestion. For now, the plugin is sometimes referred as »Package Manager« and sometimes as »Packages« Manager. Usually, these pieces of software use the singular form. I suggest, that also do that.
Well, I think all three of us are right. @distantnative’s widget is a plugin for the Panel, not the definite Kirby plugin widget. It’s a great experiment to check what’s possible and it might end up to be an actual plugin that can be used in production, but it won’t define standards for other plugins.
Don’t understand me wrong: I really like the widget and the idea behind it. But it is independent from Kirby and if someone rather wants to use YAML, the person can extend the widget to support that as well. It’s nothing baked into the Kirby core.
I think the plugin bundles are a huge step forward in general, and how to install the plugins is the user’s decision. The bundles would now make automatic installation with Composer etc. possible, but we won’t force users to use anything specifically.
What happened to this widget? It was a good idea, I think. 
please, NOOOOOOO!!!(!)
I want to propose an idea on that topic:
I really want to have a composer.json in my PHP projects because it’s way cleaner to see what I’m depending on.
For Composer to work right with plugins they need to switch from package.json to composer.json
So what would happen if you add a section to your local composer.json (for your site) that gets handled by the kirby installer?
{
"name": "your-company/your-project",
"type": "project",
"license": "proprietary",
"require": {
"php": "^5.4 || ^7.0",
"mnsami/composer-custom-directory-installer": "1.1.*",
"getkirby/kirby": "^2.4"
},
"extra": {
"installer-paths": {
"./kirby": ["getkirby/kirby"],
"./kirby/toolkit": ["getkirby/toolkit"],
"./panel": ["getkirby/panel"]
}
},
"kirby-plugins": {
"rasteiner/kirbytranslations": "0.8.*"
}
}
If you now call composer install in kirby gets installed (you might need to add the .htaccess and index files but the interesting command would be:
kirby install
which would parse kirby-plugins and call kirby plugin:install x on every item in that list (preferably with that version)
and if in this example kirbytranslations would add a composer json one could just move it from kirby-plugins to require
Also kirby plugin:install --save x could add the installed plugin to the composer.json
or preferably kirby plugin:install x would save if there exists a composer.json
I hope that makes sense and if someone else wants that I would probably start and extend the CLI
(I hope I can combine the first steps)
Hi. For the record I made https://github.com/fvsch/kirby-composerkit which kinda looks like an alternative to your first 3 steps. Though it’s a bit opinionated (it keeps Kirby core and the Panel’s PHP code in vendor).
I’m not sure there’s a point in extending the Kirby CLI with complexity to parse composer.json, resolve version requirements like Composer does, and install a series of plugins. If you’re going to use Composer, I’d go with a solution that relies on Composer only, not a combination of that + more steps using the Kirby CLI.
You can define any public git repo as a Composer package, though it’s a bit verbose, as defined in How to use Composer to install Kirby, Toolkit, Panel (note that this technique is not needed anymore for Kirby itself). For instance:
{
"repositories": [
{
"type": "package",
"package": {
"name": "distantnative/multiselect",
"version": "master",
"source": {
"type": "git",
"url": "https://github.com/distantnative/multiselect.git",
"reference": "master"
}
}
}
]
}
But if a plugin is only published on GitHub and not also available on Packagist, I would worry a little bit about its availability over time, and instead I’d install the plugin (manually or with the Kirby CLI) and I’d commit the installed files (rather than ignore them). I don’t want to create a project that can be installed now but not in 18 months when a developer changed their GitHub handle or deleted or renamed a repository.
I’m not sure there’s a point in extending the Kirby CLI with complexity to parse composer.json, resolve version requirements like Composer does, and install a series of plugins. If you’re going to use Composer, I’d go with a solution that relies on Composer only, not a combination of that + more steps using the Kirby CLI.
Parsing composer as I mean it would be:
$plugin_list = json_decode($composer_json, true)['kirby-plugins'];
and then I could at least try to update all packages at once or install all used packages
But if a plugin is only published on GitHub and not also available on Packagist, I would worry a little bit about its availability over time, and instead I’d install the plugin (manually or with the Kirby CLI) and I’d commit the installed files (rather than ignore them). I don’t want to create a project that can be installed now but not in 18 months when a developer changed their GitHub handle or deleted or renamed a repository
The goal should be, that all kirby plugins are on Packagist in the end. My proposal with extending composer.json is only to have a easier transition.
Maybe better to curate a Composer repository of Kirby plugins.
Relevant doc: Repositories - Composer
That would be some big community work (making a site that generates a big packages.json available on some public URL). Though it could be built with Kirby. 
And I don’t think that’s more work than writing and maintaining the PHP code for what you suggest (others may disagree with this estimation).
Having a public repository for Kirby plugins (at least those not on Packagist) allows doing something like this in your project:
{
"name": "my-kirby-powered-website",
"type": "project",
"repositories": [
{ "type": "composer", "url": "https://kirby-packages.example.com" }
],
"require": {
"getkirby/kirby": "2.4.*",
"getkirby/panel": "2.4.*",
"someone/some-kirby-plugin": "dev-master",
"someoneelse/cool-kirby-plugin": "2.*"
}
}
Of course this doesn’t solve having to copy the plugin’s code to site/plugins or other places, which is theoretically covered by GitHub - composer/installers: A Multi-Framework Composer Library Installer but I’m not sure that’s a 100% working and practical solution.
I really like that idea of http://packages.getkirby.com together with packagist.
But it still needs every plugin to switch from package.json to composer.json (or have both)!
My understanding is that it doesn’t. I’ll have to try it.
you would have to tell composer if its a plugin or a field or a widget or am I wrong ?