Should we include the platformsh cli?

wunderio / image-fuzzy-alpine-devshell

https://quay.io/repository/wunder/fuzzy-alpine-devshell

GNU General Public License v3.0

0 stars 1 forks source link

Should we include the platformsh cli? #28

Closed james-nesbitt closed 8 years ago

james-nesbitt commented 8 years ago

It's still used heavily in our offices, especially in DE. It can be added just like Drush/D-Console, and can be kept at the project level, as well as global.

james-nesbitt commented 8 years ago

hmmm, probably not a good candidate right now:

➜  ~ composer global require platformsh/cli
Changed current directory to /app/.composer
Using version ^3.1 for platformsh/cli
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Can only install one of: stecman/symfony-console-completion[0.7.0, 0.5.1].
    - Can only install one of: stecman/symfony-console-completion[0.7.0, 0.5.1].
    - Can only install one of: stecman/symfony-console-completion[0.7.0, 0.5.1].
    - platformsh/cli v3.1.0 requires stecman/symfony-console-completion ~0.7 -> satisfiable by stecman/symfony-console-completion[0.7.0].
    - Installation request for platformsh/cli ^3.1 -> satisfiable by platformsh/cli[v3.1.0].
    - Installation request for stecman/symfony-console-completion (locked at 0.5.1) -> satisfiable by stecman/symfony-console-completion[0.5.1].

james-nesbitt commented 8 years ago

We could use the downloadable installer:

curl -sS https://platform.sh/cli/installer | php

But we already do that with composer, and it is a bad practice really. The installer could break at any time and we'd have no understanding of why.

aleksijohansson commented 8 years ago

@james-nesbitt Why do you think it's bad practice to use the installer in composers case? With Platform.sh CLI I agree because there is no option to define the version to install. Would it be better if we install it manually by downloading a specific release from Github?

james-nesbitt commented 8 years ago

Running install scripts from the internet works means:

unvalidated code is running for the install (did you read the install PHP code?)
install code can change without any warning (can't restrict to a specific version)
falls outside of repository management so typical software management tools can't manage linking, updates etc
code is not packaged for specific platform, and therefore the platform particulars may not have been considered in the installer (alpine is often at risk for this due to use of muslc instead of libc)

The compose case is sort of temporarily allowed, as the alpine compose package is based on PHP5, but that will likely resolve itself over this year.

james-nesbitt commented 8 years ago

Incidentally, conflict with the platform CLI has been longstanding on-and-off. It is often been a problem where the Drupal console team are slow to update their dependencies, whereas the platform team are quite fast.

james-nesbitt commented 8 years ago

@aleksijohansson I don't mind using the installer for now, but I think that we should mark it for review in the future.

aleksijohansson commented 8 years ago

@james-nesbitt Valid points, thanks for explaining! Let's do what you suggest.

james-nesbitt commented 8 years ago

https://github.com/wunderkraut/wundertools-image-fuzzy-developershell/pull/32 uses an intermediate approach. It bypasses the install script (most of which is redundant for us) and uses curl to dl a specific version to /app/.composer/vendor/bin/platformsh. This pretends as though it was a composer install, and can be easily be replaced if/when we can mix it as a proper composer download.

aleksijohansson commented 8 years ago

Tested and merged #32. I'll create another issue with upstream label for updating the build to use composer when issues with it has been resolved.