more formal plugin aproach

[tomas-pecserke]

I've been thinking about how to automatize testing of this project, and I've found that as it's now, we have problem using unit tests as the whole project is one big inter-twisted system. We need a way of breaking it down to smaller, more easily maintained and tested pieces.

In my opinion the best way to accomplish it, considering some pseudo-formalized plugin system in place already, would be to use more formal plugin system. It's obvious the project is already on that road anyway.

The key aspect would be a dependency system. Imagine having nice little plugins Apache which is securely set up and completely unit tested. Then you make package Automatic Vhosts which depends on Apache. All you need to do to test it is test interactions of new code and dependency interactions, not the plugins themselves.

With this also so called meta packages (no code, only dependencies) would be super useful.

So my question is: how do we do this?

Now we could create our own PPA repository and use custom configurations. This approach is very powerful as configuratibility is concerned, but would be sot of a black box for users, and I stated, it's important for you to keep all the settings transparent.

Another possibility is to devise one of our own design. I believe this to be the most difficult and the most flexible solution at the same time. We could make it as simple as possible supporting all the features we need.

And at last we could utilize some existing provisioning system. Viable choices here would be Chef and Puppet.

[mhlavac]

I thought of this script as a way how to create a LAMP virtual machine. It is obvious now that this script can be used on workstations as well. Not only that... it should provide whole developer team with same development environment.

As you already stated, PPA would be blacked boxed. I would avoid this as this scripts is open source mainly to publicly show what it does.

Our own design is waste of time as there are provisioning system which should do the work just fine. I'll look into it.

Current prefered option is Chef.

[mhlavac]

@tomas-pecserke I've started experimenting with chef and i am not sure if it is what we need. I was thinking all about how upgrading to newer version will be possible, but that might not be true as developer could change his working environment to a state which we would overwrite with the patch.

Chef would allows as to easily config different packages (at this time i want to keep LAMP simple = no need for parametrized configuration) and to support more linux distros (same thing here, i don't want to allows developers to choose the distro as it should work for every developer the same way).

My conclusion is, if developer uses vagrant, or similiar technology he can keep his project data on his current filesystem and he can mount these to virtual LAMP. This way if he needs to update LAMP all he has to do is to download new .ova (virtualbox), or just update his .vagrant file and run vagrant up.

If developer made modifications to his virtual LAMP then he is not going to upgrade anyway. If you would like to provide such a functionality i would go for patches.

[mhlavac]

I've read your original post again. Chef solves the dependencies problem pretty well as you can set that one package has dependency on another package.

The problem here is that developer needs to install RoR and Chef to run all of these scripts. Good thing is that we can use already existing cookbooks for apache and other parts of this LAMP.

Anyway... i've started working on tests and i am going to push new branch with tests. It's not nice as i am doing testing in SSH for first time in my life, but it tests at least the system as a whole which is enough for now, but in near future we will need tests for separate plugins as you've already stated.