Closed alphex closed 5 months ago
I think that looks like 128 MB of memory allocated to PHP? That's dangerously low, considering the number of modules that get installed by Starshot.
According to the PHP docs, it looks like memory_limit
is something that can be overridden at runtime so I personally don't see much of a problem with merging a PR, if you send me one, that runs php core/scripts/drupal recipe ...
with php -d memory_limit=512M
.
Regarding Lando and/or DDEV: I think it makes a lot of sense to make Starshot compatible with both of them, as easily as possible, but it's a little beyond my level of expertise to do that, since I use neither. (I'd probably favor DDEV, since it seems to be the most commonly used Docker-based development environment for Drupalists.) I'm more than happy to review/merge any PRs towards that goal, though!
This looks cool, and will be a huge step towards wider Drupal adoption, thanks @phenaproxima!
DDEV integration would be very nice. To try in DDEV (possibly add to the README?):
mkdir starshot && cd starshot
ddev config --project-type=drupal --docroot=web
ddev start
ddev composer create drupal/starshot-project --repository='{"type":"vcs","url":"https://github.com/phenaproxima/starshot-prototype"}' --stability=dev
After the download completes, I get this error since drupal quick-start
doesn't work in DDEV:
[ERROR] No suitable browser opening command found, open yourself: 'http://127.0.0.1:8888/user/reset/1/1715116386/alOwbH0JiiNV0T6aJAjRKVFSD-D49NU5kXdbXMXEuIw/login?destination=%2F'
Stop the server with Ctrl-C, and create login link in DDEV:
ddev drush uli -l https://starshot.ddev.site
Yeah, the fact that the browser cannot be opened makes sense, since DDEV is running in a containerized environment and there's no browser to open (within that, anyway).
If you post a PR that adds these instructions to the README, I'd gladly merge it.
The current installing process with one-liner is a killer feature. Integration with DDEV may give a false impression that this requires Docker and could negatively impact on the perception of what Starshot is.
Why? I think with proper documentation, it doesn't need to give them impression that Starshot requires Docker. We should keep the current one-line command front and center, but I don't see any particular reason to make folks who prefer DDEV figure it out themselves...?
+1 for the installer increasing the memory limit.
The default PHP memory limit is 128MB, which should be enough to run the site, just not quite enough to install 143 modules (made it to 134).
> cd web && php core/scripts/drupal recipe ../recipes/starshot
134/143 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░]
Installed History module.
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 1310720 bytes) in /Users/wiifm/projects/starshot-project/web/core/lib/Drupal/Component/DependencyInjection/ReverseContainer.php on line 75
One of the very strong point of using DDEV, is that you do not have PHP and Composer installed on the host machine. DDEV takes care of everything.
I created a PR which adds DDEV install commands #43.
Oh, and @phenaproxima, I highly recommend that you try DDEV -- it's a spectacular tool.
@gitressa I have nothing against DDEV - it is a great tool! But I'm afraid it will take the focus away from the purpose of this project.
Your PR literally states
After the download completes, you probably get an error since
drupal quick-start
doesn't work in DDEV
This means that instead of using a single line command, which is a killer feature to trying this fast an evaluator user would need to use multiple commands that may or may not work, leading to a breakage of the onboarding experience.
you do not have PHP and Composer installed on the host machine.
But now you have to have DDEV installed. This has its own drawbacks.
My point here is to highlight the risk. The decisions, is of course, on maintainers.
@AlexSkrypnyk @gitressa @phenaproxima
The original issue here is that on my very capable M1 Max, with 64GB of ram... it didn't work. I originally sugguested lando and ddev because those are highly scripted enviromments, that -- igoring the requirement for docker -- are supposed to "just work".
If anything, the goal of this task should be to identify how to allow PHP on OSX to work.
I use homebrew, and when I run which php
I get
/opt/homebrew/opt/php@8.2/bin/php
Thats just how I set it up - and if we're looking for easy early adopters, we need to answer the ability for most people to execute this out of the box. That was my larger purpose of this issue I raised.
Well, for whatever it's worth, main
now has this:
"cd web && php -d memory_limit=512M core/scripts/drupal install ../recipes/starshot"
So we've probably kicked the problem a little down the road here.
I think we should support (by documentation) Docker-based or other dev environments (certainly DDEV, maybe Lando and Docksal), but explaining how to set up a whole dev environment is absolutely beyond the scope of Starshot. If you have DDEV already, great -- let's give folks instructions on how to set up Starshot, specifically, with it. Same idea with Lando/Docksal. But I don't think we need to explain how to set up the environment itself.
And remember -- we have Tugboat integration already. If someone really has no dev environment but wants to try Starshot, all they need do is click on a link that's already in the README.
This is on an M1 Max with 64 GB of ram.
Do we need to explicitly call PHP with more memory usage?
is there an argument to distirbute this as a lando or ddev recipe? and leverage containerization ?