Druptask

Welcome,

We are currently quite busy with all the project applications and I can only review projects with a review bonus. Please help me reviewing and I'll take a look at your project right away :-)

It would be good, if you could provide some installation shell script or a pear channel, so that it's easy to install your software on any UNIX environment. I have installed it on fedora by copying files from debian sub directory into the matching paths and the only minor problem I can see is, that the druptask inifile command tries to cut /etc/apache2/envvars which is not present on my system.
Your configuration file is easy to understand, but I can't see lines for the user name and password of the root user ( uid 1 ) of drupal. I see it creates a user with name admin and some password set in the created database.
I can see the generated webpage. Somehow all the links on the generated website link to rewritten paths like DrupalRoot/user although my web server don't support them.
I know this is not a module, but in modules the README file is called README.txt, I don't know if your are suppose to name it so in a feature.

Hi c2is

I've just been through the code.
First, none of the PHP complies with the Drupal code conventions. Although this is radically different from a normal module, if your chosen language is PHP, it should show the same syntax and layout as we use elsewhere.

But the bigger problem is : Debian packaging is a very strange way to choose to distribute Drupal code. It just doesn't fit any of our existing release procedures.

Did you know that you can easily extend drush by providing your own drush commands? That is a hugely more popular, supported , and practical way of extending drush functionalities with command-line additions you think are possible.

duplication

I can't tell from your description

a set of command line php utilities which automates some tasks

what actual tasks this does or tries to do. Please be a lot more specific. :-)

Digging deep into the code however, I see just a couple of calls that seem to either :
- partially replicate (in a much more limited way) the functionality of drush site-alias config files.
- partially replicate (in a much more limited way) functionality similar to drush make and drush site-install

I really think you should spend some time looking at those to identify if your scripts provide anything that is not already in and tested in drush core.
A small patch/addition to these drush functions may be probably the better approach. If not, then certainly they should be a drush extension, insite the drush framework, not as a comand-line harness that tries to sit outside of drush.
I think you'd have a lot more to gain (and get a lot of fun tools for free) by doing this rather than continuing down the dpkg route.

At the very least, please make it very clear on your project page what sets this apart from those existing utilities.

Closing due to lack of activity. Feel free to reopen if you are still working on this application.