Feature Request #4475

Complete installer

Added by Ruslan Sukhar almost 3 years ago. Updated almost 3 years ago.

Status:NewStart date:03/10/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Resolution: Points:1

Description

(Moved from here)

Hello everyone!

I propose to make changes in Basic Application that in my opinion could be very useful.

Bootstrap config

First of all, in every application developers in 90% of cases make the same changes in APPATH/bootstap.php:

  1. Set the default timezone
  2. Set the default locale
  3. Set the default language
  4. Set the default environment (or tie it with the host name)
  5. Change Kohana::init attributes: index_file, caching, profile, errors. As to me, I tie last three to Kohana::$environment.
  6. Choose modules to include

So, in my opinion it would be very convinient to refactor default bootstrap and store all this stuff in more structured way.

(It it is kind a sacred thing, please let me know :) )

For example special config file APPPATH/config/bootstrap.php could be something like this:

return array(
    'default' => array(
        'timezone' => 'America/Chicago',
        ...
        'modules' => array(
            'auth' => array(':MODPATH', 'auth'),
        ),
    ),
);

So we achieve several advantages:

Now we can easily switch from one predifined configuration to another
Particular settings can be changed not only by developer with IDE.

logs / cache

Every time I manually create logs and cache. Why not to create it in installer? As for now Kohana_Core creates logs/cache folders only if they are defined in $settings variable.

Modules configuration

  1. Database always needs connection settings
  2. Auth always needs salt key
  3. ...

Some settings in configuration files should be somehow marked as "changeable at installation" (maybe in some module-install file).

How we can change config files?

With Kohana_Config_File_Writer

Just a simple class that performs var_export($config) function and stores the result in APPATH/config/some_config.php

Installer

As for now install.php only performs Environment Tests. I think one can agree, that it hardly goes well with the term "installation".

So install.php could be supplemented with next abilities:

  1. Change bootstrap configuration
  2. Change modules configuration (using module installers)

This can be useful in blank installation and in future deployments of working application.

After this installation process will be complete.

Now please tell me before I started working at it: is this feature interesting to anyone?

History

#1 Updated by Steven G. almost 3 years ago

This should be closed and split into multiple issues.

Agree on moving all one-value "settings" into either one or many configuration files; each configuration file setting should have it's defaults in the appropriate module. Thus allowing for various modules to add new configuration options and/or overwrite core ones.

Disagree on modules being in a configuration file. You're not going to load modules from your database, so since you're always going to have file access it's pointless. Configuration also depends on modules so the design is... nonsensical.

Also, the entire module system along with the configuration system need to be split right out of kohana. Kohana depends on these systems so it's much cleaner to have them as seperate entities. Regarding caching they can both accept a caching interface at any time; "any the time" being when the correct caching sub system is actually loaded.

Against against automated salt and database configuration. This can cause interoperability issues. The reason you're suppose to configure them is because they're suppose to be unique to your application not your code. As in, if you reinstall you need the same settings, not new settings. Salt in this case may not be a serious issue if unique but I'm against automated generation of security settings, outside of using a tool to help generate values (not set them for you blind). Case to point, say cookie salt was set automatically. If I can somehow detect the time on your installation by accessing static resources such as images and whatnot then I'm very close to cracking your salt if say the way it was generated was using the current time or relied on the current time. Having a stupid mokey do it is a lot more unpredicatable.

Generating complete overwrite configs should be a minion task, since you actually don't want to overwrite all values in a config most of the time. Not overwriting means you have guranteed best config options from upstream. Doing it on install also gives a false sense that you actually have all the configuration options in your config, when in reality that may not be the case (well, not after you run an update on your submodules it won't).

Against monolith install file. Installing should be split between various other concerns. Database configuration mapping. Migrations. Etc. The actual installer should be no more then a common interface. As it stands all that is currently not supported. Until those are supported an installer is pointless as it would not satisfy the need for people that actually require "installer" support in their projects.

Against log / cache change. No idea what you're talking about. Current system is fine. If you need extra functionality such as multiple logs you can extend the log class and add it; this is how it's supppose to work in the current design and there doesn't seem to be any disadvantage to it.

Now please tell me before I started working at it: is this feature interesting to anyone?

Does not improve the design IMO. So... no?

#2 Updated by Steven G. almost 3 years ago

On "install.php" in particular...

I think you're right that it's incorrect to call it "install.php" as it does nothing of the sort.

It should probably be "kohanainfo.php" or something. :)

#3 Updated by Ruslan Sukhar almost 3 years ago

You're not going to load modules from your database, so since you're always going to have file access it's pointless. Configuration also depends on modules so the design is... nonsensical.

It seemes to me, that I used wrong words to describe the whole idea.
I totally agree with you, that using Config (that depends on modules) to load modules list is out of sense.
I used the term "configuration" just to describe idea, not pointing to Kohana_Config.
Bootstrap configuration should be absolutely native without any dependencies, something like this:

$boot_config = require APPATH.'config/bootstrap.php';

This can cause interoperability issues. The reason you're suppose to configure them is because they're suppose to be unique to your application not your code. As in, if you reinstall you need the same settings, not new settings. Salt in this case may not be a serious issue if unique but I'm against automated generation of security settings, outside of using a tool to help generate values (not set them for you blind).

Sure, I'm not talking about automatic generation of settings! None of them!
I was talking about GUI for manual input of all the settings.
I'm talking about a step from manual setting via IDE to manual setting via GUI.

Against monolith install file. Installing should be split between various other concerns. Database configuration mapping. Migrations. Etc. The actual installer should be no more then a common interface. As it stands all that is currently not supported. Until those are supported an installer is pointless as it would not satisfy the need for people that actually require "installer" support in their projects.

Good idea. Sure we can easily add database creation (via sql execution).
As for migrations I think this is a lot more broad topic than just "installer".
At the moment in our company we are finishing milestone (list of tasks), that is devoted to migrations.
In my opinion simple installer can absolutely be created regardless of migrations. And vice versa.

Against log / cache change. No idea what you're talking about.

Just about automatic creation of needed directories.

#4 Updated by Steven G. almost 3 years ago

Bootstrap configuration should be absolutely native without any dependencies, something like this:

Technically that just takes the array and just moves it to a file. It's still an array, you just now have an extra file call. What's the point? What's the advantage?

Moving it in config/ is also wrong. All the files in config should be true config files that load via the cascading file system. Having it there would suggest you can have auto-loading modules, which you can't. So that means you have to have this module declaration somewhere random. You would also not have the array but the actual instruction (ie. Kohana::modules). Does this make sense? Personally I've split things like routes into seperate files just because they took so much space, but never saw the need for the module declaration.

If someone out there has so many modules or a special process for loading them (like binding them to routes) that they need a specialized file to configure them then it should be their responsibility to do so, since the default (empty) module declaration is only good as reference in bootstrap as is.

I was talking about GUI for manual input of all the settings.

What you actually want is a backend module. I've experimented with the concept as a means of eliminating admin actions from views with theme support. It requires more convention and configuration then you are currently conceiving in your feature request. I would also not recommend creating such a module just for changing configuration modules; there needs to be support database configuration mapping before that as well, not because it's required but because creating one with out considering will simply require a rewrite later.

This also needs to be in a separate module since it implies the existence of a user and access control system. Web interfaces are vulnerable; I've seen too many companies with public administration configuration. It's very sad.

As for migrations I think this is a lot more broad topic than just "installer".

No. A proper installer needs to be able to install both a fresh copy as well as upgrade the database structure and migrate data when applied to an existing database. Any less, and it is useless and better left in the hands of the developer. Well I suppose the upgrade functionality can be considered optional, but I wouldn't recommend that.

Just about automatic creation of needed directories.

They are already created. Can you describe the behavior in more detail. Sounds more like a bug. I can only think of one cause: are you downloading the files directly or fork/cloning?

#5 Updated by Ruslan Sukhar almost 3 years ago

What's the point? What's the advantage?

The same advantage that we achieve taking modules settings to config files despite of having "extra file call".
Please read again the first message, you don't get the main point.

All the files in config should be true config files that load via the cascading file system.

I agree. It's reasonable.

This also needs to be in a separate module since it implies the existence of a user and access control system. Web interfaces are vulnerable;

Well, take a look at any existing installer. Phpmyadmin, wordpress, drupal, for example.

A proper installer needs to be able to install both a fresh copy as well as upgrade the database structure and migrate data when applied to an existing database.

Ok, thank you. I still think that these things are totally different and can be realized regardless of each other. But if you see the real way to create installer with migrations, that will be great!

I'm still waiting for more opinions.

#6 Updated by Steven G. almost 3 years ago

The same advantage that we achieve taking modules settings to config files despite of having "extra file call".

With those the advantage I see is that the setting and the process by which it is set is independent. This means the same setting can be applied in a different way or even used to populate other values. Not the case for modules. Modules are exactly the same if they are in a file or outside a file.

Well, take a look at any existing installer. Phpmyadmin, wordpress, drupal, for example.

You need to understand those are all independent application not frameworks. Unless you want to pigeonhole every kohana aplication to be a wordpress, phpmyadmin etc hardcoding the implementation and making so many assumptions on how it will work is not feasible.

But if you see the real way to create installer with migrations, that will be great!

Already created one. It's not "finished" yet though. I won't post it since kohana has it's own migration system, you should look into that.

Also available in: Atom PDF