Are environments mandatory?

[WillyBaldy]

I went through the documentation and it seems that the notion of "environments" is mandatory. In all of our projects we moved away from such paradigm (as did Symfony and Zend/Laminas a long time ago) and use only a non versioned "local" configuration file(s). I was able to fiddle with Phinx so that it's always using "production" but then gets the configuration from a local non versioned file. It's still weird to see the mention of "production" even though we're in development, and I thought it would have been much cleaner to allow not using environments at all. Maybe to allow the database configuration information at the root of the config array in some 'database' key, and if "default_environment" is not found and if the environments is not passed to the CLI commands, then this key must exists and is used for the database connection. This would allow to completely bypass the environment mecanism and any reference of it in the configuration file.

[dereuromark]

Many users (incl me) are using it non-env based through https://github.com/cakephp/migrations If phinx standalone works env based I think we should remove this in next major then (or at least opt in that instead of opt out).

[WillyBaldy]

Alright thanks that would be great, because right now I don't think there's any way to use Phinx stand alone without environments, as far as the documentation and my tests go. I'm getting a "The environment configuration for 'production' is missing" or "Could not find a default environment" errors when I try to do away with environments.

[dereuromark]

Are you able to make PR against 0.next? Or even a fix for Master to have a default?

[MasterOdin]

What exactly are you looking to have here? Where you can define an .env file with say the following:

DATABASE_URL="mysql://db_user:[email protected]:3306/db_name"

and it'll work, with everything else (paths, phinx migration table, etc.) just using defaults?

[WillyBaldy]

@dereuromark Sorry I'm just at the stage of reviewing different migration tools for my company so I can't get into any sort of coding yet, but just thought I'd make sure there was no alternative and to make a suggestion at the same time.

@MasterOdin Well, first of all, we don't want to use environment variables for sensitive information like database passwords (it's actually bad practice IMO) so it would have to be in some config file that's not versioned. For example, we could have a config.php.dist which is copied to config.php (same thing with yaml or other formats) and then we'd put all of the settings directly in the root of the array, no mention of "development" or "production". Of course, we could have a config.php.production.dist if we wanted. That's the modern way of handling different environments. I think Phinx should get rid of the system of passing the environment as an argument, and remove the default environment option and anything related to environments. On top of that, you could make it possible to use environment variables (I think you already do) so you could use them in the config files if you wanted.

[MasterOdin]

Alright, sounds like this is two things:

1. allow all non-db connection fields (e.g. paths) to have sensible defaults
2. flatten out the environments into a singular array

For point 2, we could do something like this:

$config = [
    "environment" => [
            'migration_table' => 'phinxlog',
            'adapter' => 'mysql',
            'host' => 'localhost',
            'name' => 'production_db',
            'user' => 'root',
            'pass' => '',
            'port' => '3306',
            'charset' => 'utf8',
    ]
];

(where migration_table is optional and defaults to phinxlog, and then the rest of the fields are adapter specific on what's optional and what is not. Not fully onboard with pushing all environment details onto the root of the array, as opposed to having this singular level of nesting, and other frameworks (like symfony and laravel) seem to have a similar level of nesting at the very least for their DB configuration files. Could also give an alternative name (database_details?) if so desired.

Under the hood, phinx could silently cast that into the environments way of it, though this ends up being an implementation detail the user need not concern themselves with. This would maintain BC for people interested in still using environments.

[WillyBaldy]

Yes this could be a good trade off if you want to keep backward compatibility. I personally would have done away with environments (I've been in total dislike of them as far as Symfony2, remember the old app_dev.php? GIves me shivers!) in the next major release (welcome to 2020!) but it's easy for me to say when I'm not the one dealing with making upgrades for your users as smooth as possible. I've got loads of other suggestions but I think you've got enough on your plate. Thanks for your time.