Closed lolautruche closed 2 years ago
Looking at the most important global dependencies early... In general it's best practice to not use global composer dependencies, but rather to put them into the project. But I guess if we have people using these... it's not hard to support.
The more things we put into the Dockerfile, the longer the initial startup is (first time for project).
I'm not sure we should fiddle with python/python2/python3/ruby at this point.
nodejs is another thing; ddev is already maturing in this regard, And the ability to add npm packages globally is interesting, and not hard. Assuming that dependencies work out.
One thing we need to sort out as we do this... Where can mainline DDEV learn from Platform.sh usage; What features should just be implanted in the project?
Dependencies can be important for many users. Global Composer dependencies should be fine here. I'm fine with only dealing with PHP deps.
Where can mainline DDEV learn from Platform.sh usage
Not sure to understand what you're asking. My guess is that the Platform.sh docs should be a good starting point.
What features should just be implanted in the project?
These are represented by the issues I created 😉, in regards to the assigned milestones (1.0, 1.1, 1.2) . Unless I'm missing something.
Can you suggest more php dependencies? The two examples in the docs are composer 2 and drush 8. DDEV already has drush8 available for D7 projects, and composer 2 is the default, but can be changed to composer 1 in config.yaml. I can certainly add composer 1 to config.yaml where necessary.
PHP dependencies are actually only Composer packages, so it can be anything that is installable globally using Composer.
Example: psysh/psysh
/ composer g install psysh/psysh
Install global PHP dependencies in the container, as configured in
.platform.app.yaml