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

Allow PHP 7.x and 5.6 side by side #1765

Closed
GeoffreyWolff opened this issue Aug 22, 2018 · 7 comments
Closed

Allow PHP 7.x and 5.6 side by side #1765

GeoffreyWolff opened this issue Aug 22, 2018 · 7 comments
Labels

Comments

@GeoffreyWolff
Copy link

Hello, I am using multi project setup and I was wondering how could I have 2 versions of the PHP in one installation of Laradock.

The problem is that some of our legacy projects still runs on PHP 5.6 but newer (and upgraded) stuff runs on PHP 7.x. Also if I want to start a new Laravel project, I want to use latest stable framework release which requires me to use PHP 7+

Having to change environment variable to switch PHP version and rebuild the container is a pain. I was wondering if it would be possible to have 2 containers and just run which ever version I need at the moment.

PS: I was looking for similar issues, but did not find any. If there is one, sorry about the duplicate.
PS2: I am new to Docker. I was happy with my Vagrant / Homestead setup but wanted to try something more lightweight. If this is a stupid question, sorry about that.
PS3: English is not my native language, sorry if it's hard to follow what I mean.

@liminworks
Copy link

可以设置2个容器,,不同的别名和端口号,nginx配置中取不同的别名连接啊

@AminMkh
Copy link
Contributor

AminMkh commented Aug 31, 2018

Most of us are running different environments per project, you can clone Laradock into each of your projects' directory. Modify docker-compose configurations to your needs. They will be completely independent.
Make sure you change:
COMPOSE_PROJECT_NAME=laravel
and this way docker will identify containers differently, so:
COMPOSE_PROJECT_NAME=WebApp1
could have PHP version 7.2

and
COMPOSE_PROJECT_NAME=MyBlog
could have PHP version 5.6
This way you wouldn't have to rebuild images.

But note, rebuilding containers wouldn't take long because the first time you build one, it gets cached.

@GeoffreyWolff
Copy link
Author

Yes, I know that and I agree. But I don't want to go that way because that would mean I would have to keep multiple systems up to date and that would not by very DRY. I wanted to switch to Docker / Laradock to have something simple to use, more lightweight than classic Laravel Homestead.

For now I've made myself a bash script to switch between 7.2 / 5.6 and other versions in .env file

### PHP Version ###########################################

# Select a PHP version of the Workspace and PHP-FPM containers (Does not apply to HHVM). Accepted values: 7.2 - 7.1 - 7.0 - 5.6
PHP_VERSION=7.2

and rebuild the containers, bring them up. It's certainly more user friendly and makes usage of the system a lot easier or better to say enjoyable to use.

Anyway I still think that the process of switching PHP versions in PHP and Workspace containers should be easier for newcomers.

PHP version in the workspace container matters because of composer and executables installed in the project using composer. Yes we can use composers --ignore-platform-reqs but that requires special configs in composer.json file.

@AminMkh
Copy link
Contributor

AminMkh commented Sep 6, 2018

sure but typically, we have every project, with it's own dependencies, 1 PHP version, specific PHP extensions. That's why we clone Laradock into each folder and make customizations (if needed).
From what I understand, your problem is that you want each project to have same configurations but many PHP versions, which is a special case.

@mufengorg
Copy link

At present, many PHP integrated development environments are multi-project sharing. The demand of most users is actually multi-version PHP and multi-version MySQL coexist. Most of the other modules can be shared. The COMPOSE_PROJECT_NAME mechanism requires laradock to copy multiple copies. This will result in maintenance costs for multiple cloned version environments, which is not an optimal solution. Is it possible to add a grouping mechanism to the outermost layer to store multiple items that can be configured in a shared configuration?

@stale
Copy link

stale bot commented Feb 2, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Stale label Feb 2, 2020
@stale
Copy link

stale bot commented Feb 23, 2020

Hi again 👋 we would like to inform you that this issue has been automatically closed 🔒 because it had not recent activity during the stale period. We really really appreciate your contributions, and looking forward for more in the future 🎈.

@stale stale bot closed this as completed Feb 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants