Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add an option to create a new project using Symfony Docker #411

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

dunglas
Copy link

@dunglas dunglas commented Jan 15, 2024

The Core Team privately discussed repurposing the --docker flag of the symfony new command to create a project using Symfony Docker. The goals are to have an official way to bootstrap a project using Docker with ease and to set up FrankenPHP with Symfony.

This patch only covers project creation.
In the feature, it could be nice also to detect if Symfony Docker is used and forward symfony console, symfony composer, and similar commands to the Docker container.

Usage:

symfony new --docker

cc @weaverryan

@weaverryan
Copy link

I’m not qualified to review technically, but this is exactly what I had in mind. It will help with discoverability.

it could be nice also to detect if Symfony Docker is used and forward symfony console, symfony composer, and similar commands to the Docker container.

That’s super interesting!

@sarim
Copy link
Contributor

sarim commented Jan 18, 2024

please excuse my interjection as I'm not a core team member, but I'd like to share some thoughts on the proposed --docker flag. I appreciate the effort to integrate Docker seamlessly, but automatically using "dunglas/symfony-docker" and FrankenPHP could be confusing for those less familiar with Docker or web server administration. It would be ideal if the default behavior created a project with de-facto-standard technologies: nginx/php-fpm. Perhaps the --docker flag could require specifying a skeleton name or URL, initializing the project accordingly. Official Symfony skeletons should be created in official namespaces like symfony/docker-fpm or symfony/docker-frankenphp. Then these official skeletons would be listed in the --help output. Additionally, a Symfony documentation article outlining the required structure for Docker containers to be compatible with this Symfony-CLI feature would be beneficial. This could enable the community to create and utilize their own skeletons effectively.

I apologize again for intruding on a core team discussion.

@weaverryan
Copy link

Hi!

Valid points! From a practical point of view, I’m not sure we can maintain 2 different docker skeletons. And so, the one will be opinionated.

Official Symfony skeletons should be created in official namespaces like symfony/docker-fpm or symfony/docker-frankenphp

Being under the symfony org makes sense to me. But @dunglas is the one doing the maintaining of the docker skeleton in reality. But yea, I think it’d be cool to have it under the symfony org if it’s the official option.

@dunglas
Copy link
Author

dunglas commented Jan 29, 2024

@sarim Unfortunately, FPM is not well suited to containerized platforms. This is one of the main reasons I started working on FrankenPHP: to easily distribute Symfony applications as Docker images, as easily as with Node or Go. As a "Symfony Docker" maintainer for years (who used NGINX and FPM in the early days), I can guarantee that using Caddy and then FrankenPHP has simplified a lot of things and greatly improved the developer's experience.
That's also the reason why NGINX created NGINX Unit (the project doesn't look very active anymore).

I gave [a full presentation on this topic] (https://dunglas.dev/2022/10/frankenphp-the-modern-php-app-server-written-in-go/) at SymfonyCon 2022.

@weaverryan I'm not against moving Symfony Docker under the Symfony namespace, as long as we can continue to grant maintenance rights to @maxhelias, who has done a great job maintaining it for a very long time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants