Direct Install lacks options and cleanup

[OleVik]

Thought I'd tag @akeif for this, since he's been very involved in getting the directinstall command working. Whilst the command works well, with only minor infidelities I thus far have blamed on Windows and haven't tracked down fully in debug, two points are worthy of immediate consideration: The command does not register common options, and folders are not deleted on failure or success.

For the former, force, all-yes, and destination are not available. Just like the rest of GPM, having them available cuts down on development-time significantly. For the latter, I noticed that regardless of whether the installation halts or succeeds, the temporary folders in /tmp/ are not deleted - at least none have been thus far.

[gnufred]

Thanks @OleVik 😄. I'm definitely interested in tackling this issue.

My understanding

If I get you right, here what should be done before solving this issue.

1. files created in /tmp/ while running directinstall should be removed
2. folders must be deleted whether the command succeed or fail
3. command force should be available and implemented properly
4. command all-yes should be available and implemented properly
5. command destination should be available and implemented properly

Request for more information on point 2

I get you are saying that this might happens only on Windows.
Also, what do you mean by folders?

[OleVik]

Folders, as in directories. After running the command, whether it fails or not, it leaves behind a copy of the extracted extension in /tmp/Grav-randomhash/ for each attempt, but they are not subsequently removed by the process.

What happens on Windows is not related to point 1-5, they are merely current deficiencies of the implementation. On Windows two things happen on occasion: mkdir fails, or Composer's Autoload fails with the name is already in use in /tmp/Grav-randomhash/pluginname/pluginname.php. I suspect this is more an issue with Windows, though, and shouldn't be tackled unless it can be consistently reproduced.

[gnufred]

All right. So I'll stick to this:

1. files created in /tmp/ should be removed whether the command succeed or fail
2. command force should be available and implemented properly
3. command all-yes should be available and implemented properly
4. command destination should be available and implemented properly

[gnufred]

I'll take a look and make a plan before coding. I'd like create a merge request for each point but we'll see how this goes.

I'll try to do this tonight but will do Friday or Saturday at worst.

[gnufred]

Changes to consider after this issue has been resolved

• Add bin/gpm direct-install command to the API doc.
• Add to doc: how to run unit tests
• Fix found issues 1, 2
• Get tests to work

[gnufred]

What the command does

Install

• Grav
• plugin (package)
• theme (package)

from (.zip only?)

• path
• URL

[gnufred]

Test packages links

Grav latest
Grav core 1.1.17
Grav update 1.1.17
Antimatter latest
Antimatter 2.1.0 zip
Antimatter 2.1.0 gz
Admin 1.1.17
Piwik 1.0.2
Gravstrap 1.2.3
Shortcode UI 2.2.0
Login 2.2.1

[gnufred]

@OleVik In the bin/gpm direct-install context, what would be the difference between --yes-all and --force. To me, both would do exactly the same, so one would be an alias.

[OleVik]

The aliases of force and yes-all are f and y, respectively. force will "Force re-fetching the data from remote", whilst yes-all "Assumes yes (or best approach) instead of prompting".

Essentially, you can force retrying/refreshing data from the GPM and/or pass the generic yes to all asked questions, such as "Dependencies are not met, proceed? y|n?". See InstallCommand.php.

[gnufred]

Look likes theres two var I need to check out in system/src/Grav/Console/Gpm/DirectInstallCommand.php.
$tmp_zip is downloaded or copied package folder containing the file $zip and $tmp_source is the extracted zip.

[gnufred]

I don't think direct-install hit a cache. To what I see on GPM::downloadPackage and GPM::copyPackage in DirectInstallCommand.php it's copied and downloaded each time.
So the --force option will not be useful as of now.

Let's see what come out of this.

[gnufred]

Installing an older Grav package delete the tmp folder and fails.

di https://github.com/getgrav/grav/releases/download/1.1.17/grav-v1.1.17.zip
#!/usr/bin/env php
Are you sure you want to direct-install https://github.com/getgrav/grav/releases/download/1.1.17/grav-v1.1.17.zip [y|N] y

Preparing to install https://github.com/getgrav/grav/releases/download/1.1.17/grav-v1.1.17.zip
  |- Downloading package...   100%
  |- Extracting package...    ok
  |- Checking destination...  ok
  |- Installing package...  
                                    
  [RuntimeException]                
  Cannot move non-existing folder.  
                                    

direct-install <package-file>

De-packaging 1.1.17 on branch develop probably cause this error.

This is probably cause by trying to install a stable release on the develop branch.

[gnufred]

Following my tests with packages from this comment successful installation clean temporary files.
See Folder::delete here and here.

[gnufred]

I can't get my functional test to work. Instantiating a null output when I call the Grav command is giving me trouble.

This doesn't help me: http://stackoverflow.com/questions/18237519/symfony2-console-output-without-outputinterface

I get the error

[Symfony\Component\Console\Exception\InvalidArgumentException] The "package" argument does not exist.