The suggestion is to add "profiles".
Example of a command:
project init --dir --domain --profile
The command creates a project folder, a subfolder is created .osp and the project.ini file inside
--dir - project directory, required parameter. If the projects_search_path variable does not contain the path to the project folder, the path is added.
Example:
--dir = path_to_project_directory\my_project
There is no path_to_project_directory in the projects_search_path variable - it is automatically written to the variable
--domain - The domain name for project.ini. An optional parameter. If not specified, it is created automatically by the folder name and .local
Example: my_project.local
--profile - Pre-defined profiles for projects with specific modules
Example:
default_profile.ini
nginx_engine=NGINX157
node_engine=20.20.1
php_engine=8.1
ssl=on
ets
UPDATE
I will describe it in more detail. Profiles are separate prepared program entities.
When using the output command, we get the project directory at the path we specified with an already nested folder .osp and the generated project.ini file.
Example command:
project init C:\domains\my_project my_domain.local example_name_wordpress
We will get:
The my_project domain folder with a subfolder .osp and generated project.ini:
[my_domain.local]
php_engine = PHP-8.1
node_engine = 20.20.1
ssl = on
Ideally, after the specified modules for the domain are activated automatically.
It's really on the verge of what you want, so that you can specify subsequent commands in profiles, for example:
The suggestion is to add "profiles". Example of a command:
project init --dir --domain --profile
The command creates a project folder, a subfolder is created .osp and the project.ini file inside
--dir - project directory, required parameter. If the projects_search_path variable does not contain the path to the project folder, the path is added. Example: --dir = path_to_project_directory\my_project There is no path_to_project_directory in the projects_search_path variable - it is automatically written to the variable
--domain - The domain name for project.ini. An optional parameter. If not specified, it is created automatically by the folder name and .local Example: my_project.local
--profile - Pre-defined profiles for projects with specific modules Example: default_profile.ini nginx_engine=NGINX157 node_engine=20.20.1 php_engine=8.1 ssl=on
ets
UPDATE I will describe it in more detail. Profiles are separate prepared program entities.
Profile example: example_name_wordpress.ini php_engine = PHP-8.1 node_engine = 20.20.1 ssl = on
When using the output command, we get the project directory at the path we specified with an already nested folder .osp and the generated project.ini file.
Example command: project init C:\domains\my_project my_domain.local example_name_wordpress We will get: The my_project domain folder with a subfolder .osp and generated project.ini:
[my_domain.local]
php_engine = PHP-8.1 node_engine = 20.20.1 ssl = on
Ideally, after the specified modules for the domain are activated automatically.
It's really on the verge of what you want, so that you can specify subsequent commands in profiles, for example:
example_name_wordpress.ini php_engine = PHP-8.1 node_engine = 20.20.1 ssl = on [commands] RU unzip wordpress.zip
and after creating the domain, activating the modules, the archive was unpacked to the project folder
Mini deployment