Time to fork Drush?

By Jaypan on 24 Jul 2014 at 10:44 UTC

I have to say, I'm pretty unimpressed with Drush recently for two reasons:

1) They have stopped support on Drupal.org. Very anti-community. Any requests for support get a reply of 'go to github'.
2) It now requires composer to run. Composer cannot be installed on most shared hosts, and I have a few clients on shared hosting.

I'm thinking it's near time to fork the last version before they added the composer dependency, and bring it back to Drupal.org. I'm not a Unix pro though (just a user), so I'd like to enlist the help of anyone who is interested in helping. Any takers?

Comments

1) Why would they provide

bojanz commented 24 July 2014 at 11:23

1) Why would they provide support on Drupal.org if the code is elsewhere?
And is the fact that you need to visit another link for support enough for you to try and support everyone by yourself?

2) More and more Drupal modules are going to require Composer to run. That's Drupal 8 reality.
I'm trying to figure out how to remove that requirement for Commerce 2.x, but the state of drupal.org packaging is making it impossible for now.
So thinking about our packaging is much more productive than thinking about forks.

Regarding shared hosting, since it has no shell, how do people even use Drush there?
I personally believe that the time of shared hosting is over. Drupal 7 barely runs on it. Drupal 8 won't for sure.
And we live in the age of 5$/month VPSs.

1) Why would they provide

Jaypan commented 24 July 2014 at 11:35

1) Why would they provide support on Drupal.org if the code is elsewhere?

Why would they put the code elsewhere when they can do it on Drupal.org. It's anti-community.

And is the fact that you need to visit another link for support enough for you to try and support everyone by yourself?

I'm not intending to do it myself. That's the point of this thread, to try to enlist others who are as turned off by the Drush team as I am.

2) More and more Drupal modules are going to require Composer to run.

I didn't know this. That could turn out to be a big issue. I wonder if people realize that by requiring Composer, they are cutting off pretty much every user who is on shared hosting.

So thinking about our packaging is much more productive than thinking about forks.

Not really. The whole abandonment of Drupal.org alone is enough of a reason to fork. The addition of the composer requirement pretty much seals the deal in my books.

Regarding shared hosting, since it has no shell, how do people even use Drush there?

All the shared hosts I work with have shell access, so I'm not sure to what you are referring.

I personally believe that the time of shared hosting is over. Drupal 7 barely runs on it.

I have a number of client sites on Drupal 7, on shared hosting, that run fine. Once caching is turned on, and as long as too many modules are not used, it's not a problem.

And we live in the age of 5$/month VPSs.

These are unmanaged VPS. As long as everything works, it works. But when things go wrong, unless you are a sysadmin, you are in for headaches galore.

Anyways, this is all beside the point. Basically this thread is to see who, if anyone, is ready to work with me to fork Drush, bring it back to a usable state, and bring it back to Drupal.org. If I'm the only one who feels this way, then it will die here. But if others agree with me, then we'll be working with Drush2 soon enough.

Why would they put the code

bojanz commented 24 July 2014 at 11:43

Why would they put the code elsewhere when they can do it on Drupal.org. It's anti-community.

Because d.o has poor code collaboration tools, so every few years many projects migrate off to GitHub, which triggers
d.o improvements (like the Great Git Migration), which then triggers a migration back to d.o.
Funny enough, it seems to match preparation for new core releases, since most contrib coding is done at that time.

Drush has its own additional reasons of course, due to the fact that they are a shell tool and not a module, so they fit
poorly into the existing versioning & workflows.

Anyway, my point is that the things you're seeing are a part of a larger Drupal community shift.
Forking Drush is just trying to treat a symptom.

Forking Drush is just trying

Jaypan commented 24 July 2014 at 11:44

Forking Drush is just trying to treat a symptom.

You're welcome to that opinion. Obviously I disagree. This thread will show how others feel.

Most shared hosting supports

John_B commented 24 July 2014 at 12:54

Most shared hosting supports Pear. Maybe one day it will support Composer. The glacial speed at which cPanel introduce new features (in the interests stability) suggests there will be a long wait. As OP certainly knows, Drush 7 (the version required for D8) requires composer. For earlier versions of Drupal you can use an older version of Drush which does not need Composer.

I did get Composer working on shared hosting. The hosting company supportive. It was a battle: on some hosts it will be impossible for anyone, on others it is impossible for many Drupal users.

The reality is that Drupal, driven by the big Drupal shops, is turning into a fantastic enterprise product which (I concluded after having done a bit of work with D8) will not be suited to hobbyists and low-budget clients, or (probably) to shared hosting.

If you ask the key drush developers when they last met someone who uses Drupal on shared hosting, or when they last derived income from serving such a client, I daresay they would give you a blank look. If Drupal 8 itself has abandoned that market, as I think it has, I see no reason why the Drush devs should put much time into supporting that market for the more recent versions.

On the other hand, if a large cohort of core devs, and Acquia staff in particular, were ever to decide that real efforts should be made to ensure that hobbyists, and clients on cheap shared hosting, should find Drupal 8 accessible, then Drush's requirement for Composer would be a massive problem.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Doesn't require composer

Steve Hanson commented 25 July 2014 at 19:50

They just list an installation with composer first in the instructions. Read further down in the installation instructions and find the "Manual Install" section.

They're just trying to make life EASIER for you to use composer for the install if you're an install sort of person. You can still download the Drush archive and extract it on to your server - just like in the past.

All that being said, getting used to composer at this point is probably not a bad idea since a lot of working seriously in Drupal 8 is going to require it.

Or you could just go to a host that supports Drush as part of their server install - we do, there are certainly others.

Steve Hanson
Principal Consultant Cruiskeen Consulting LLC
http://www.cruiskeenconsulting.com
http://www.cms-farm.com

If installing drush without

John_B commented 25 July 2014 at 20:15

If installing drush without Composer is even harder than with it (and I sweated blood for several hours getting Composer working on shared hosting), then God help the low-skilled people whose small clubs, churches and charities have in the past been 'empowered' (to borrow Dries's word) by Drupal, on $5 a month hosting, and who elect to install the drush using harder (non-Composer) way.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Or you could just go to a

Jaypan commented 25 July 2014 at 23:16

Or you could just go to a host that supports Drush as part of their server install - we do, there are certainly others.

I have a VPS I pay a hefty amount of money for that allows me to install whatever I want. That is not the issue. The issue is that for Drupal sites that are not so heavy, I'm not going to tell my clients that they have to get $100+/month hosting (for a managed VPS) so that I can have a tool that benefits me in development, and does nothing for them. And I'm not going to recommend they get a cheap unmanaged VPS which opens them up to security issues because I don't have a full sysadmin on staff. The obvious solution for hosting for these sites is shared hosting (I actually recommend semi-dedicated hosting by MDD hosting).

Where are the manual install instructions that do not require composer?

On the Drush Github page

Steve Hanson commented 1 August 2014 at 20:09

here
Scroll down till you get to the part that says "Install - Manual"

Steve Hanson
Principal Consultant Cruiskeen Consulting LLC
http://www.cruiskeenconsulting.com
http://www.cms-farm.com

Thank you. That's helpful.

Jaypan commented 1 August 2014 at 22:37

Thank you. That's helpful.

Nope. Scroll further and you

flaviovs commented 30 October 2014 at 18:26

Nope. Scroll further and you'll see:

INSTALL - MANUAL

(...)
5. From Drush root, run Composer to fetch dependencies.

$ composer install

If you cloned the git repository, the only way i found to run drush on a D7 site without having to install Composer is to use the "6.x" branch, e.g. run on your cloned repository:

$ git checkout 6.x

FVS - https://dmarcpal.com

Appreciate this discussion to

izmeez commented 30 October 2014 at 19:10

Appreciate this discussion to see how Drupal 8 is changing the dev environment.
Adding comment just to follow it since there is no follow button on forum posts.

Before and after

chirale commented 19 June 2015 at 09:07

I want to share my activities involving Drush on dedicated host, before and after the Composer thing, on CentOS:

Before:
1) yum search pear
2) yum install php-pear.noarch
3) pear channel-discover pear.drush.org
4) pear install drush/drush

jobs done

After:
1) sudo curl -s https://getcomposer.org/installer | php
(here I'm executing something arbitrary from a website like another, the day someone inject some malicious script there we'll be happy, just a rant)
if something goes wrong with certificates (and it happens), repeat point 1 like crazy. Spend some time browsing stackoverflow and hitting your head on the floor with php.ini, certificates and other configuration things that nothing have to do with drush directly. 1 2.

Even if you have full access to the server, it's a time-wasting process.
2) I've imported a ton of certificates on the server. Fine.
3) composer global require drush/drush:7.*
4) If everything goes fine, now you have both composer and drush installed.

I don't know why to abandon Pear for a couple of arbitrary scripts / methods. It seems like another framework vs framework battle. The practical result is that I'm stuck with the pear 6.x version in many servers because it is very time-wasting to configure this new composer thing. The drush is the Drupal administrator swiss-knife, and now you must have a permit to use it.

Both of these actions are anti-community.

Michael-IDA commented 5 October 2015 at 16:29

If D8 requires Composer to install and run, then D8 is toast for the group that made Drupal widely available. That Drush abandoned d.o. is, in my opinion, heinous.

There is no argument that both of these actions are anti-community.

Drush 7.x is not usable without Composer:

# mv drush-7.0.0/ drush
# drush --help
Unable to load autoload.php. Drush now requires Composer in order to install its dependencies and autoload classes. Please see README.md

Drush 6.x is not usable without PEAR Console_Table library:

# mv drush-6.6.0/ drush
# drush --help
exec() has been disabled for security reasons bootstrap.inc:645      [warning]
exec() has been disabled for security reasons exec.inc:150             [warning]
exec() has been disabled for security reasons exec.inc:150             [warning]
exec() has been disabled for security reasons exec.inc:150             [warning]
unlink(/home/username/bin/drush/lib/package.xml): No such file or      [warning]
directory drush.inc:691
The drush command 'help' could not be found.  Run `drush cache-clear     [error]
drush` to clear the commandfile cache if you have installed new
extensions.
Drush needs a copy of the PEAR Console_Table library in order to         [error]
function, and the attempt to download this file automatically failed.
To continue you will need to download the 1.1.3 package from
http://pear.php.net/package/Console_Table, extract it into
/home/username/bin/drush/lib directory, such that Table.php exists at
/home/username/bin/drush/lib/Console_Table-1.1.3/Table.php.

Edit:
Ah, it's been too long since I've had to deal with shared hosting. To 'fix' the "exec() has been disabled for security reasons bootstrap.inc":

First use 'drush status' to find your system php.ini you're currently using, then for:

Shared Hosting:

Copy your system php.ini to either $HOME/.drush or your actual drush directory.

Dedicated Server:

Copy your system php.ini to /etc/drush/php.ini .

Then remove 'exec' from the 'disable_functions' list in the php.ini you've copied.

$ grep disable php.ini 
; This directive allows you to disable certain functions for security reasons.
disable_functions = show_source, system, shell_exec, passthru, popen, proc_open

$ drush status
 PHP executable        :  /usr/bin/php-cli                      
 PHP configuration     :  /etc/drush/php.ini /etc/drush/php.ini

# # #

Since both developer groups have made finding the actual download links a pita, here's the links as of today:

wget -c "https://github.com/drush-ops/drush/archive/6.6.0.tar.gz"
wget -c "http://download.pear.php.net/package/Console_Table-1.1.3.tgz"

# # #

My 2 cents? Wait until the Drush group abandons Drush 6.x and then 'fork' that branch back onto d.o. You'll need a catchy new name, but hey, names aren't hard to come by.

Best All,
Michael

Drupal Hosting

NIH Cancer Study: Supplemention with both vitamins and fenbendazole exhibited significant (P = 0.009) inhibition of tumor growth.

NOTICE: Drush no longer supports installation via pear

soulston commented 17 November 2015 at 15:24

https://www.drupal.org/node/2132447

Just an FYI here for everyone as this relates to installing Drush and you can no longer install drush via the pear channel.

Somehow i am totally missing

babipanghang commented 19 November 2015 at 15:33

Somehow i am totally missing why someone with shell access would not be able to use composer on shared hosting? Not that i ever tried, but the composer requirements page states as only requirement: "Composer requires PHP 5.3.2+ to run.".

So if that's all, one would generally be able to install composter somewhere in one's home directory without much trouble?!

Did i answer your question on the forums? I love to hear a reply wether or not it worked for you!
Jaap - Acquia certified drupal site builder

If you have any interest in

John_B commented 22 November 2015 at 20:09

If you have any interest in the matter at all, log in to a few shared hosting accounts, download composer, type php composer.phar and see what happens. Some hosting accounts allow you to enable phar. Some do not. Some do not even allow ssh login.

There is a set of people who think Drupal has not really left shared hosting users out in the cold. There is a set of people who use shared hosting. The intersection of these two sets has no members.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

If you have any interest in

babipanghang commented 24 November 2015 at 10:08

If you have any interest in the matter at all, log in to a few shared hosting accounts, download composer, type php composer.phar and see what happens.

I do have interrest in the matter. In fact, about a year ago i bought my own virtual server, coming from shared hosting land. Main reason for moving over: instability of hoster, lack of control, lack of ssh.
However, i'm not going to "log in to a few shared hosting accounts" simply because i want to try things out, they cost money you know!

Some hosting accounts allow you to enable phar. Some do not.

I didn't know some disable phar. Phar can be executed like regular PHP files right? So can you execute normal php files with the command line on those hosters (just asking because i honestly don't know)? If not, i don't see the relevance to this topic, since drush relies on that.

Some do not even allow ssh login.

This topic is probably not about those shared hosting accounts, since drush requires some kind of terminal access.

There is a set of people who think Drupal has not really left shared hosting users out in the cold. There is a set of people who use shared hosting. The intersection of these two sets has no members.

That is a very bold statement. As said, i've tasted from both worlds, and i'm just trying to figure out what the problem is at this point.

Did i answer your question on the forums? I love to hear a reply wether or not it worked for you!
Jaap - Acquia certified drupal site builder

I have certainly seen claims

John_B commented 24 November 2015 at 13:15

I have certainly seen claims where people who say Drupal still works OK on shared hosting have a colleague who has friend they help out who uses shared hosting. I have yet to hear, read or meet someone come out and say 'sure, I have used shared hosting for Drupal and it is no problem' (unless they have picked a niche Drupal-specialist host who installs drush for you).

Best thing is to go and try it. Some of the big name cheap shared hosts such as Hostgator can be quite supportive, on a good day. The super-cheap ones are a dead loss. However, if you try installing drush and composer now on shared hosting, you are likely to find it a painful experience, I have done it, I struggled, and I have better skills than the typical target audience for shared hosting.

The reason for my bold statement, is that I know that a lot of the people who are developing Drupal core and possibly those creating the support tools (drush, drupal console) do make the assumption that it is probably going to be OK, but they would never dream of putting Drupal + drush + composer on shared hosting for real, and probably never even tested it. Anyone who does test it, could help a lot of people by creating some documentation here.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

@bojanz, @John_B specifically

Michael-IDA commented 6 December 2015 at 15:50

@bojanz, @John_B specifically. Everyone else in general.

Hi Bojan, John,

Regarding shared hosting, since it has no shell, how do people even use Drush there?

Most shared hosting have the capability of turning shell on. You might need to submit a support ticket, but it's generally available.

And we live in the age of 5$/month VPSs.

Which costs another $15/month for cPanel and another $50+ per month for someone to do sysadmin.

Cheap VPS: $60+ per month, w/ server security concerns
Shared Hosting: $5+ per month, server security handled by host.

So, no. 5$/month VPSes are not anywhere near a direct replacement for a shared hosting account.

# # #

While on the topic, I'm going to weigh in on the side of shared hosting being entirely suitable for D7 and below. As long as all the hosted sites don't ever get more than a couple concurrent page requests at a time.

But, I'll be completely upfront, my example uses Bluehost and I entirely dislike Bluehost, who in my opinion are either technically incompetent or incredibly lazy. (And with a shared hosting memory_limit of 128M, are about as bottom of the barrel as you can get.)

On Bluehost, shared hosting, you can install Drush 6.6. As long as the server isn't about to crater (happens multiple times a week), it works well.

I have not tried to install composer or D8, it's a client account.

# # #

low-skilled people whose small clubs, churches and charities have in the past been 'empowered' (to borrow Dries's word) by Drupal

I personally believe that the time of shared hosting is over. Drupal 7 barely runs on it. Drupal 8 won't for sure.

These two statements identify the real issue. Drupal is no longer being developed in a manner that is either 'empowering' or with use by 'low-skilled people' in mind. The argument can be made that Drupal abandoned the 'low-skilled people' with D7, but D8 is shaping up to force every low-skilled person with a Drupal site to abandon Drupal and migrate to WordPress.

Sure it's great for Acquia, the other top ~100 Drupal shops, and probably the DA, but the masses of people that really made Drupal popular? Hardly.

Best,
Michael

Bojan,

As an aside, Commerce, out of the box, has this same issue (abandoning 'low-skilled people').

Using Commerce Kickstart (D7) as an approximation as to what a site would need to be to reasonably usable functionally or 'production worthy' as you will. Commerce arguably isn't even close to usable in a manner that is 'empowering' or realistically achievable for the 'low-skilled people' who use to be able do the same thing with D5 and D6.

Out of the box, there are 128 non-core enabled modules in Commerce Kickstart. Using exceedingly simple math, factor 1 hour per non-core enabled module for research for a low-skilled user just to find, and install, each module. Add whatever number of hours you want for the proverbial 'normal' low-skilled person to get a grasp on rules, and everything else, needed to drive Commerce, and it's easily more than a man month of hours. Compare that to one (exceedingly) long weekend in D6 to achieve the same (non-Commerce Drupal solution).

Yes, Kickstart is one great band-aid for the issue. But, it's just that, a band-aid that masks the true problem that the complexity of finding just what modules to use has exceeded the grasp of a low-skilled user.

I dislike people bitching without even an attempt at a solution, so here's two thoughts.

First thought would be to do a complete write up on Kickstart. What's used. Why is it used. Why are the core patches used? Basically a complete guide that someone could follow that would achieve the same thing, that also gave at least minimal explanations as to the rational behind the use of each tool selected.

Second thought, would be to clean up the Drupal Commerce project realm. Probably not achievable, but a large portion of the upfront research time is wasted on just eliminating all the abandoned, no longer used, modules like commerce_sp from what is usable. Especially since a good portion of search results indicate these are (were) the 'best choice' solution.

Drupal Hosting

NIH Cancer Study: Supplemention with both vitamins and fenbendazole exhibited significant (P = 0.009) inhibition of tumor growth.

@Michael-Inet

John_B commented 6 December 2015 at 16:50

@Michael-Inet

Well you have an interest, in that according to your signature you run a Drupal shared hosting service, albeit a fair bit more expensive than typical shared hosting. And good luck to you. There should be a niche for someone between the lower priced offerings (which until recently James Oakley offered to a high standard, though there are not many in that market) and the more professional-oriented players like Pantheon, which can get expensive as well as intimidating for many users.

One of the results of the way Drupal has changed is that there is - I and several others I have heard speculate - less chance of being transformed from a hobbyist website developer into a professional than there was in the past. The learning curve is probably now to steep for most who do not have some software background. However, it would be unfair to criticise Drupal specifically for that, because it may apply to the web more widely.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Hi John,

Michael-IDA commented 7 December 2015 at 20:29

Hi John,

Well you have an interest, in that according to your signature you run a Drupal shared hosting service, albeit a fair bit more expensive than typical shared hosting.

I've never been able to come up with exactly what my offering should be called, as it bears zero resemblance to typical shared hosting, but is legitimately 'shared hosting.' *Shrug* I've just renamed it to "Fully Managed Drupal Hosting."

I basically charge nothing for hosting. My quarterly fees are entirely based upon labor to keep the client's site updated (in a professional manor).

I have less than $10 per client, per month, in server expenses. Basic economies of scale, a 12 CPU (24 Threads), 64 GB RAM server averages +80 %idle
with 12 to 16 clients.

I'm lazy, It'd cost me more to do efficient load balancing, so I just buy another dedicated server . . .

The learning curve is probably now to steep for most who do not have some software background. However, it would be unfair to criticise Drupal specifically for that, because it may apply to the web more widely.

I adamantly disagree. WordPress does not have this issue. Why should Drupal?

# # #

For clarity of bias, I can't say that the majority of my clients, or myself with 30 years IT, were ever part of Drupal's historical user base. For the most part they're are business owners who understand the value of their time, and are willing to pay someone to provide business services. They understand cost / benefit analysis and Acquia's costs for them are so absurd, they'd never use them. *

And based upon how many have said Acquia never replied to ANY of their emails, Acquia won't even talk to business their size if the first place.

But, returning to your point, my response is, "Why is Drupal abandoning it's historical user base? When it doesn't need to?"

Best,
Michael

PS: I'll reply to your email in the next day or so.

* The clients I have on places like Bluehost are non-profits, who I give a hugely reduced rate too.

Drupal Hosting

NIH Cancer Study: Supplemention with both vitamins and fenbendazole exhibited significant (P = 0.009) inhibition of tumor growth.

And based upon how many have

Jaypan commented 7 December 2015 at 22:34

And based upon how many have said Acquia never replied to ANY of their emails, Acquia won't even talk to business their size if the first place.

I've had that exact same problem with Acquia on two occasions. The second time I had to email them three times on three days before I finally got a response.

My experience too. They are

John_B commented 8 December 2015 at 08:21

My experience too. They are not interested. I have talked to Acquia sales on chat, more than once on the phone (and face to face at DrupalCon). They remain polite and seem smart. And once they know you and your clients are relatively small players, not a flicker of interest in either selling anything, or even in making the process of buying from Acquia less challenging. And to be fair, we are not the market Acquia are interested in or, owing to prices, can readily sell to, so why should they be any different?

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

eeek!

DrupalDope commented 15 December 2015 at 04:37

eeek!

I'm totally scared by what I read.

I am new to Drupal, coming from Postnuke - I am making the jump to Drupal now only (7 years after I should have done it) because no other system could replace Postnuke after its devs sabotaged it.

https://www.drupal.org/node/2536122#comment-10664776

Please don't let the same thing happen to Drupal.

Double eeek!

leoklein commented 15 December 2015 at 21:15

@eeek:

I agree.

LEO

I agree with you regarding

bojanz commented 8 December 2015 at 09:06

I agree with you regarding the Commerce problems. They are the ones I am trying to fix in Commerce 2.x for Drupal 8.

If you decide to create that write up on Kickstart, I will gladly answer all of your questions on IRC or Skype.
For d.o projects I think the only thing we can do is create issues that say "mark the project as deprecated, recommend X instead", then escalate it to the webmasters issue queue if the maintainer is no longer present.

Maybe create a package

DeveloperChris commented 31 March 2016 at 22:43

I came here via google because I want to know how to install drush WITHOUT COMPOSER. So I totally agree with the OP.

The reason we need it is because using composer on productions systems is considered a security flaw. We cannot allow this system to pull in arbitrary code that can be replaced by bad actors. We do not have enough time and resources to vet everything, so we must minimise our exploitable surface at every opportunity.

As we move more and more to a Drupal house we are looking at ways to minimise maintenance cost we simply cannot afford to content freeze, move sites to dev, upgrade, test, move to prod, unfreeze. For every site. Multisites do not make it any easier for those that will propose it.

With Drush we can skip the debilitating content freeze portion do our testing on dev at our leisure (Ha) and then perform the upgrade in one fell swoop on the production machines.

But I am reticent to install Drush and its composer based installation system on a production machine!

Unfortunately I don't have the time to contribute to a fork.

I am going to work on a 'package' debian has a package but unfortunately it is too old and fails.

You are free to run Composer

bojanz commented 31 March 2016 at 23:23

You are free to run Composer locally then upload or package the result (and doesn't Drush have a PHAR option already? Drupal Console does).
You need Composer, but you don't need it on the server.