Incorrect Composer Root detected when using Symlink

[jigarius]

Since I saw the label question, I thought it was allowed to ask questions here. If asking questions is not allowed on the repo, please feel free to close this ticket and refer to the question of StackOverflow if you have the time.

Context

• Set up a custom Composer package, say, custom/foo at /opt/foo.
• Set up an empty Drupal installation at /opt/drupal.
• Set up a custom repository and install the custom project as a symlink (for development):

  "require": {
    "custom/foo": "*"
  }
  ...
  "repositories: "{
    "type": "path",
    "url": "/opt/foo",
    "options": {
      "symlink": true
    }
  }
  

• Run (new DrupalFinderComposerRuntime())->getComposerRoot()

Expectation

The path to the Drupal project should be returned, i.e. /opt/drupal

Reality

The path to the Package's root is returned, i.e. /opt/foo

References

• Issue on jigarius/drall
• Question on StackOverflow

[jigarius]

At this point, I'm even willing to swap the real DrupalFinderComposerRuntime with a CustomDrupalFinder and use the custom finder for local development. However, I'm afraid the solution isn't future-proof without a DrupalFinderInterface that would ensure the correctness of the custom finder implementation.

Here's a pull request in case the idea appeals to you.

Any help will be greatly appreciated. Even if you can't help, I'm still thankful for Drupal Finder.

[webflo]

@jigarius Thanks for opening the issue. Could to try to create the file/repo structure as a fixture in https://github.com/webflo/drupal-finder/tree/master/tests/fixtures? I will take a look. I think drupal-finder should work for your use case. Thanks!

[jigarius]

I've created a fixture and a test case that roughly matches the problem I'm facing.

While creating the test, I spent ~30 minutes to see if there's an easy solution to the problem, but I got nothing.

I noticed that you have a similar kind of situation in your repo setup but you do not use symlink: true. This means composer reinstall-fixtures must be run many times during development. For now, I think I'll try to switch to a set up like that.

[webflo]

@jigarius Thanks for providing the fixture. I saw you closed jigarius/drall#96. Did you resolve the issue on your own?

I think the binary in your fixture (tests/fixtures/symlink-package/package/symlink-package) should use the global variables from composer $GLOBALS['_composer_bin_dir'] and $GLOBALS['_composer_autoload_path'] to retrieve the autoloader. Related docs: https://getcomposer.org/doc/07-runtime.md#autoloader-path-in-binaries

[jigarius]

I used a workaround that unblocked my development. I used symlink: false so when I do composer install, the development code is mirrored into the other project instead. This way, it detects the right composer installation.

I was in a hurry so I chose an ugly solution, but I will look at the docs at the earliest and revisit this issue.

[jigarius]

Nice! Using $_composer_autoload_path solved the problem for me. I wonder why I didn't stumble upon those docs despite all the searches. The original sin was to assume that loading dependencies was to simply require the autoload.php.

Would you still like me to refine the binaries test case so that it can be a part of Drupal Finder tests? If yes, leave a comment and I'll do so at the earliest. For now, I'm closing this issue.