For a while we are thinking about a way to be able to distribute neos in different flavors. The most simple use case would be a distribution that does not include Neos.Demo as in all projects the first step is to remove this package.
We already agreed about that the best way would be to add post_create_project scripts that do the required work and that are kind of extensible.
A basic pr for flow exists already https://github.com/neos/flow-development-collection/pull/1852 that would configure the available post_create options in the main composer file in path extra.neos.post-create-project-tasks . While this already works and allows to preconfigure composer commands that the user may want to execute after setting up a project it is quite a bit of configuration and hard to get right.
"extra": {
"neos": {
"post-create-project-tasks": {
"nothing": {
"description": "Start with am empty Neos Setup",
"type": "nothing",
"hints": [
"For local development you still have to:",
"1. Add database credentials to Configuration/Development/Settings.yaml",
"2. Migrate database './flow doctrine:migrate' ",
"3. Import site data './flow site:import Neos.Demo'"
]
},
"neosDemo": {
"description": "Start with the Neos.Demo content",
"type": "composer",
"options": {
"command": "require",
"packages": ["neos/demo:dev-master"],
}
"hints": [
"For local development you still have to:",
"1. Add database credentials to Configuration/Development/Settings.yaml",
"2. Migrate database './flow doctrine:migrate'",
"3. Create your site package './flow site:create'"
]
}
}
}
},
My problem is that this configuration is a bit bloaty and clumsy at the same time. Especially the “nothing” task looks like a bad idea. It only exists to define the help message in for this case.
Questions:
Do you have an idea for simpler configuration.
Does this have to be more flexible and allow to run multiple commands.
I will give the format some thoughts and give response later but first:
Could this introduce a “wizard”-kind of thing. Imagine: After you are done, get a selection of methods to execute (think CommandController)
Your Flow project is created - you can do the following
1. Enter the credentials (executes a command controller taking credentials, write to YAML)
2. Execute database migrations (required credentials)
The console can take a input and we can do that (see neos/setup, it writes yo a yaml file).
This is not actual related to your RFC, but a thing to have in mind, when we decide on a format.
First commnt: Let’s not use the “nothing” and"neosDemo" keys - I don’t see we need the keys, since this is composer.json managed by the development of that exact project.
type could be our own identifiers for whatever “executor” we have underneath, that wraps a call.
thanks for bringing this up again.
This is an evergreen topic that we are discussing at least since five years… It would be great to finally get a grip on this one.
I know that we already collected some more ideas in the direction of an extensible wizard, but for the love of G… Neos, I can’t find the discussion anymore…
Also, what’s the role of the neos-splash package in that regard – is that related at all?
I’d love to discuss this as well - @s.regniet and myself are heading into a direction which is a bit different, more comparable to https://start.spring.io, combined with a “demo site hosting service” for new people. So let’s discuss this and maybe settle on a good approach
I really like that idea as well, but I think both approaches can be valuable (for different audiences) : As a coder I’d love to be able to quickly setup a Neos instance from CLI (choosing a distribution, setting up credentials, …).
For new people a visual/website driven wizard would be even less of a burden!
The splash concept was split into two parts. The part that clones a package and alters the namespace is now Sitgeist.Chantalle the post create project pr above is basically the other parts. Ideally both could be combined eventually if we get the post create project stuff really flexible.
Having a nice demo and playground is different and valuable aswell. The target group for the post create project commands is developers who are starting a project.
maybe I did not explain it well enough; it shouldn’t be just a playground but also a “getting started with good practices for seasoned developers”. Essentially I for example want to also replace company-maintained boilerplates like https://github.com/sandstorm/neos-kickstart
However if you like the CLI approach more, I think it would be also OK if we go both ways and
then see what works best for which audience. For example Spring also has start.spring.io, and
spring boot CLI.
I think docker boilerplates are really nice but a solid cli approach could be the foundation to build those upon. Beside that i still see valid usecases outside of docker :-).
Also we currently have a base distribution that requires a package that does harm if not removed as Neos.Demo comes with a dimension configuration. So wes should get that fixed someday.
When I read the RFC, I think about the setup I’ve experienced with vue-cli, where I get a number of option to go through afterwards.
In a combination with composer and the composer post-* possibilities, this is awesome for development startup - no matter if you are trained or not. Let’s make it easy for everybody.
A mybe-giveaway on that, could be more building block approach, that can be added in the startup of your project. (Yes, please add CORS http component, REST API)
Another possible approach would be to have a cli version of neos setup and only include this into the base distribution.
The last step of the setup would then simply suggest to run ./flow setup That way we could circumvent the limitations of post_create_project commands like not beeing conttrollable via cli-arguments.
I would really like to be able to pass all required configurations via Json to a setup command for a non-interactive setup. That would be great for all kinds of automation. The interactive version would still ask all those qustions.
(see neos/setup, it writes yo a yaml file).
*g