I know it's hard to keep up with Drupal 8 but drush was working before I foolishly pulled. This is becoming more and more a Linux situation where I fear every upgrade and when I finally do it, the change is big and my system breaks.

You are about to create a sites/sites.php file and DROP all tables in your 'd8' database. Do you want to continue? (y/n): y
copy(sites/sites.php): failed to open stream: Permission denied drush.inc:841 [warning]
Failed to copy sites/sites.php to sites/sites.php

I have no idea what this wants to do or why. Again it worked before pull :(

CommentFileSizeAuthor
#18 drush-1837026-18.patch568 bytestim.plunkett
#13 1837026_13.patch2.49 KBchx
#12 1837026_12.patch2.27 KBchx
#10 1837026_10.patch702 byteschx

Comments

chx’s picture

chx commented
Version: » All-versions-4.1

drush si -y --db-url=mysql://root@localhost/d8 minimal

this was the command.

chx’s picture

chx commented
Version: All-versions-4.1 »

I was looking for master but apparentyl 5.x-dev is that? I am not sure. Anyways I am on master.

chx’s picture

chx commented

Also, it's very likely I will ditch drush and write my own install script. It has grown so complex I can no longer debug it easily and also I do not think it does everything needed for a clean D8 install now. It's an awesome tool for site management for sure but for core development, it is no longer. I am sad, but this is the case.

Things needed for a clean install: wipe config, wipe php compiled files, copy the default.settings.php to settings.php do NOT add the install profile to settings.php after.

disasm’s picture

disasm commented

I'm having the same issue chx is having. Crell has suggested in the past that getting Symfony's Console Component in Core might make things easier for drush, as well as provide other interfaces for working with Drupal on a command line.

I've created the issue here: #1837280: Discussion: Use Symfony Console Component to decrease the Drush/Drupal specific code parts of Drush.

chx’s picture

chx commented

It's perfectly possible already to run Drupal from the CLI without adding more bloat to core.

greg.1.anderson’s picture

greg.1.anderson commented

From the error message that you are getting, it looks like you cannot write to the 'sites' folder (since, in theory at least, Drush site-install should not write sites.php unless file_exists says it is not already there). If this is the case, though, it would indicate that perhaps the pull of Drush master was not the thing that broke site-install. The two things for you to try would be to check your permissions on the sites folder, and check out an older version of Drush master and see if si really does start working again. If it does, git bisect would be a helpful tool to find out which change broke your environment.

I realize that it hard to manage Drush master vs D8 development, as changes in each can affect the other. This situation will probably continue to at least a certain degree until the D8 API freeze, as it won't be possible to make a stable release of Drush that supports D8 until then. Moshe and I recently spent a fair bit of time making the Drush tests work on D8; site-install does work in the tests, but the Drush quick-drupal command does not work, so there is certainly a likelyhood that there is a problem in si. It is also likely that not all of the advice from #3 is done by si yet; the tests always start with an empty folder (or restore a site with archive-restore). We will continue to work on bringing the tests back into a functional state as time allows.

You could, if you wished, write a D8-specific site-install command that is independent of Drush; if you did, a Drush maintainer would probably be able to help integrate it into Drush if you posted it here for consideration.

chx’s picture

chx commented 
dba6a753b250d7fe42d65ac8e04e358183599212 is the first bad commit
commit dba6a753b250d7fe42d65ac8e04e358183599212
Author: Moshe Weitzman <weitzman@tejasa.com>
Date:   Wed Oct 3 09:49:36 2012 -0400

    Keep up with Drupal8. Multisite requires a sites.php. See #1055862: Require sites.php to opt-in for multi-site support/functionality.
chx’s picture

chx commented 
+  $sitesfile = "sites/sites.php";
+  $sitesfile_write = drush_drupal_major_version() >= 8 && !file_exists($sitesfile);

but even the commit message says Multisite requires a sites.php. I do not run multisite.

chx’s picture

chx commented

Yes, creating a zero byte sites.php help. Still.

chx’s picture

chx commented
StatusFileSize
new 1837026_10.patch702 bytes

Tentative patch.

chx’s picture

chx commented

Now the only thing remaining for a better experience is a through wipe of the files directory but I presume that's a different issue cos it needs a recursive delete with a forward-chmod to be able to wipe the mtime protected compiled php files.

chx’s picture

chx commented
Status: Active » Needs review
StatusFileSize
new 1837026_12.patch2.27 KB

Fixing bugs wherever I find them since 2004.

chx’s picture

chx commented
StatusFileSize
new 1837026_13.patch2.49 KB

Actually this might be the more correct version.

greg.1.anderson’s picture

greg.1.anderson commented

Thanks for working on this. Overall the changes look good. I do think, however, that it might be too destructive to remove the entire files directory. Wouldn't it be surprising to lose user-uploaded files on a site install? Open to other opinions here, because "install" does by its name sound destructive; however, I don't think that we've deleted user uploads in the past, so I am somewhat reluctant to introduce that behavior by default now. As a compromise, perhaps site-install could respect a --hard flag, to delete all of files?

chx’s picture

chx commented

It's not hard to switch this to nuke files/php and files/config only. Will see to it or you can.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Needs work

I already added the sites_subdir bit two days ago: + $sitesfile_write = drush_drupal_major_version() >= 8 && !file_exists($sitesfile) && $sites_subdir != 'default';. See e92279432350c7df35122bff20b46e482b5bcf50.

I added the emptying of the config dirs during BADCamp. From your list, all that is missing now is files/phpIf someone could submit a patch for that it would be swell. The drush_delete_function might need some improving to deal with the permissions on these dirs.

Thanks for working *with* the Drush maintainers.

moshe weitzman’s picture

moshe weitzman commented
Title: Site install is broken » Remove files/php directory when reinstalling a D8 site.
Priority: Critical » Normal
Status: Needs work » Needs review
tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Version: » 8.x-6.x-dev
StatusFileSize
new drush-1837026-18.patch568 bytes

This seems to have been committed: http://drupalcode.org/project/drush.git/commitdiff/fad595d8

But, there are warnings due to permissions.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Fixed

Committed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.