Failed to create project: '~/*/drupal-cms/.DS_Store' is not allowed to be present

Hah - that's a clever little bug.

When you look at a folder in Finder, it puts a .DS_Store in there, and DDEV freaks out because the directory is, as far as it's concerned, not empty.

The workaround for you is to not open the directory in Finder, and do this in Terminal:

cd /path/to/drupal/cms
rm -f .DS_Store
./launch-drupal-cms.sh

The proper fix, for me, is to add the rm -f .DS_Store to the launch script.

Brilliant!
But all this might easily block or mislead any normal Drupal CMS user, not so expert of any Terminal and that is so confident in opening folders in the Finder.
So I really think that rm -f .DS_Store should indeed be added to the launch script.

Worth to mention also that after running the rm -f .DS_Store and then again ./launch-drupal-cms.sh
I now receive the following stopper:

FATAL: We do not appear to be in a Drupal CMS project.

And what is that, now?

Pretty frustrating and hard to go through, for a not coder user (that the Drupal CMS is expected to speak to), isn't it?

Should I assume I need to start everything over, from the initial drupal-cms.zip unzip?

and restarting over ... FYI I now have the following blocker:

./launch-drupal-cms.sh
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted
bash: ./launch-drupal-cms.sh: Operation not permitted

And after working around all the above I then now hit this new blocker:

[omissis]
Executing Composer command: [composer create-project drupal/cms --stability=RC --no-plugins --no-scripts --no-install /tmp/TAfujZ]

OCI runtime exec failed: exec failed: unable to start container process: current working directory is outside of container mount namespace root -- possible container breakout detected: unknown
failed to create project: exit status 126
stderr=
[omissis]

attaching a new related screenshot from my PHP Storm

FATAL: We do not appear to be in a Drupal CMS project.

This means that the .drupal-cms file, which is intended to ensure that you're actually operating in a Drupal CMS project, was deleted. It's meant to be deleted, so that DDEV can do the composer create-project operation...but in the event of an error, it should be restored. The fact that it wasn't is interesting, and possibly another bug.

so I now also need to adjust folder permissions ...

The launch script doesn't mess with permissions, this might be system-specific.

OCI runtime exec failed: exec failed: unable to start container process: current working directory is outside of container mount namespace root -- possible container breakout detected: unknown
failed to create project: exit status 126

Whatever this is, it's probably NOT related to the launcher script. This is probably something to report directly to the DDEV maintainers if you continue to encounter it once I've fixed the .DS_Store bug.

I'll get right to it: this issue has changed my thinking about the launch script. It was a mistake to add it, and it needs to go before we tag RC2.

It pains me to write these words, because @rfay and I spent a long, hard day hacking that script together. Our goals were to make it work properly in DDEV as conveniently as possible. I had thought we struck a good balance.

But this issue (which, to be clear, is a completely legitimate bug report) fills me with dread. It demonstrates that the script is fragile and causes a great deal of inconvenience if anything goes wrong. It strongly suggests that, if we release it in our next RC, we will see more reports of weird, buggy behavior that we will have to waste precious time fixing reactively. That, in the last few weeks before our stable release, is the very last thing we need.

At the end of the day, we have to face the unfortunate fact that, at this time, Drupal CMS cannot really be spun up by non-technical marketers. The only runtime we really support is DDEV, which is an inherently technical platform. And it's a fantastic platform, to be clear, but marketers -- our target audience -- will rightfully never go anywhere near it. It's not meant for them.

The trial experience was (is) intended to be the way for marketers to jump into using Drupal CMS, but that track is stalled due to circumstances completely beyond our control, and technical problems that we could not overcome with the resources we have. I don't doubt that the trial track will find a path forward, either as a hosted trial, or as some kind of awesome browser-based WebAssembly build, or maybe something else altogether.

So, given all that, let's accept reality and give people a command line install that actually works. Rather than the complex launcher script, that will be a shell script you have to run with curl, sort of like (don't try this, it doesn't actually exist yet):

curl -fsSL https://drupal.org/drupal-cms/install.sh | sh

There is precedent for installs like this; Homebrew leaps to mind.

This also means we should kill the zip file download. Entirely. It's already only 800 KB (because the install profile is embedded within it), and it is fundamentally incompatible with DDEV -- indeed, the existence of the zip file is the entire reason why we had to create the launcher script in the first place. The proposed curl command would simply run the brief sequence of ddev config and ddev composer create commands required to properly spin up Drupal CMS with DDEV. This adds a small measure of convenience for technical users, but more importantly it's not fragile -- because it works in harmony with DDEV, rather than trying to fight it.

And what about folks who want to do composer create-project directly? Well, it'll still work for them, no problem at all. They can still use DDEV; they'll just have to run the appropriate ddev config command to get set up. Or, they can use whatever PHP interpreter and web server they want. Very little will change for this crowd.

So there you go -- it sucks to admit we're in this place but we need to be clear-eyed and honest about what we're in a position to deliver right now. Let's give people something that works. What we've got right now is too clever for its own good.

at this time, Drupal CMS cannot really be spun up by non-technical people

This also means we should kill the zip file download. Entirely.

Maybe I am wrong and it was not planned as one of the feature of the Drupal CMS (but there was a download link by the Drupal CMS in the initial WF designs: #3453043: Review initial Starshot wireframes → ). I think that an easy+non-technical installation is a crucial part of any CMS project. The core is going away from from zip/tarball downloads ( 🌱 [meta] Deprecate tarballs, because they are incompatible with Composer-managed dependencies, Automatic Updates, Project Browser, and release managers' health Active ), which is OK, but Drupal CMS is a different product, for different audience and if we look at other CMS systems, most of them allow "download, copy, install and go" approach (see Wordpress, where you just need to download a ZIP and copy it to the hosting - the same apply to Joomla, Typo3, ...). Anything more complicated could be a barrier to a faster adoption of Drupal CMS, which, as you wrote, is unfortunate. I hope that we will be able to figure out this somehow and change that, because an easy installation is something, which was driving also Drupal 7.

Does this needs to be discussed in a separate issue? Seems like a quite significant change for me. Thanks!

I think that an easy+non-technical installation is a crucial part of any CMS project.

Nobody is disagreeing with this. The trial experience's goal is to deliver this very thing. But that track is not ready in time for our RC2 release, and that's the situation we're in. I hope we can turn that around quickly too, but that is out of my hands.

Does this needs to be discussed in a separate issue?

I feel strongly that we don't have time for that; this is an RC2 blocker and needs to be resolved now. @pameeela and @tim.plunkett are the relevant leads here, so they are the only ones who need to sign off AFAICT.

Besides, I'm not really sure how fruitful a discussion would be, to be honest with you. I think we all fully agree that an easy, non-technical installation is necessary. But I think we would also all agree that an easy, non-technical installation is something we don't yet have, and never did. The fully built zip file wasn't for non-technical people either; you still had to be able to point a web server at it, and we relied on DDEV to do that.

Rewrote the issue summary and assigning to @tim.plunkett for explicit approval.

What worked for me is unzipping the file directly in terminal.

What worked for me is unzipping the file directly in terminal.

Yes, ok. but assuming that a "normal" (marketers) users should only rely on the Terminal and stay far away from their Finder / Windows tools looks really mismatching with original goals of the Drupal CMS project

really mismatching with original goals of the Drupal CMS project

Just wanted to call out that Drupal CMS has a three-year strategy :) We were never going to be able to nail this in a few months' time. We are doing our best to make it accessible to all users but anything that requires a download is outside of the optimal outcome. On this, we all agree, but it's what we have for now.

@pameela ... for sure!
Sorry, mine have nothing to do with complaints, but only feedback to try to represent the user experience of those who want to satisfy

It's a long time since I've used shared hosting but the one use of the zip I can think of would be 'upload all the files you need to the web/ folder of a shared hosting account'. But that only works if the shared hosting account has composer available for automatic updates, otherwise that user won't be able to ever update that site.

But even if it's useful for that, it would make sense to provide the zip only once this has been proven to work on a handful of major shared hosting providers, which means removing it until then.

@catch, the reason we hollowed the zip file out is because it would cause us to ship outdated dependencies, since we don't pin them the way core does. See 🐛 Installing Drupal CMS with the zip file does not grab the latest version of dependencies Active .

@tim.plunkett is really, really smart.

If we alter the script to not use the super-opinionated ddev composer create, it becomes much more relaxed and fault-tolerant. We probably don't have to remove it; we can just change it. This, in my view, is a suitable compromise. It fixes the main problem that kicked off 🐛 Remove .ddev directory from composer create-project Active (the presence of a .ddev directory in the project template) but removes the requirement that ddev composer create operate in an empty directory, which caused a ton of complexity in the script.

phenaproxima → credited tim.plunkett → .

@tim.plunkett blessed this MR verbally in Zoom.

I feel much, much, much better about this now. @rfay expressed a similar sentiment to me in Slack. With gratitude and relief, merged into 1.x.

Great job. Thanks a lot!
Will try the new installer asap.

Tried the normal route installing the release candidate version this morning as per https://ddev.readthedocs.io/en/stable/users/quickstart/#drupal-drupal-11

Will try the fixed version of the installer later. 🙏

Btw, as a designer, the installer is a much welcomed step (although the DDEV step might be scary for some). 🙇‍♂️

Thanks a lot! I just re-tested the ./launch-drupal-cms.sh script / installer and all LGTM on my Local Mac OS X Dev env.