drush make [download][url], relative [download][url] is not relative to the makefile

[drzraf]

Setup a makefile inside /path/to/my_repo (which contains my_profile), containing:

projects[my_profile][type] = "profile"
projects[my_profile][download][type] = "copy"
projects[my_profile][download][url] = "./my_profile"

• From /path/to/my_repo/, drush make succeeds
• From /tmp/, drush make fails

"./my_profile" is not relative to the Makefile contrary to what documentation says, but relative to the current directory.

[jonpugh]

This is an issue for me as I try to get the Aegir Git project able to clone a repo with a makefile in it: https://www.drupal.org/node/2838489

We are attempting to include makefile in a git repository that uses relative paths to include site specific code. You can run drush make project.make.yml in the repo folder, but if you are not in the folder and run drush make /path/to/project.make.yml, it fails with Unable to copy projectname from file://./profiles/projectname.

Aegir uses absolute paths when calling drush for both the makefile path and destination path.

This setup (a makefile and custom code in a repo) is somewhat of a holy grail for developers and aegir maintainers because it combines the usefulness of git with the stability of using a makefile, but it currenly cannot be done in aegir because relative paths only work from CWD.

I'd love to track this one down and help out.

cc:@ergonlogic

[ergonlogic]

I can confirm this issue. Presumably a work-around is to build the makefile from the root of your repo, or something similar, so that you can consistently point to the right paths relative to CWD. Fixing this would, however potentially change behaviour. So, I'd suggest adding a flag that defaults to CWD, but can be switched to allow "relative to makefile".

This is complicated by includes and recursive makefile builds. Presumably the "relative to makefile" will mean relative to the makefile in which the project is defined. So we'll presumably need to resolve these to full paths during the initial parsing of the makefile, prior to inclusion.

The documentation will also have to be update to reflect the correct default behaviour (cwd), as well as the new behaviour.

[jonpugh]

Thanks for the reply, @ergonlogic ... I attempted a fix in the PR mentioned above, but as you said, this is tricky...

If someone else thinks making a drush option to use relative paths is a good idea, I can try that but I do think that using the path of makefile as the relative root is the more logical behavior.

[ergonlogic]

DrushMakeProject::preprocessLocalFileUrl() appears to already be trying to do this.

[ergonlogic]

I guess, since the docs already state that this ought to be relative to the makefile, that this is a bug. So backwards compatibility isn't really an issue.

[ergonlogic]

preprocessLocalFileUrl() appears to only be called when resolving patch and translation paths. Presumably we'd be able to re-use it when downloading a package.

[jonpugh]

Would it be simpler to chdir to DrushMakeProject->make_directory and then chdir back?

[ergonlogic]

I believe that we'll need to resolve the full path in _make_parse_info_file(), prior to including other makefiles, since $makefile here represents the path to the current makefile.

[ergonlogic]

Actually, after further reading, I don't think preprocessLocalFileUrl() will help here. DrushMakeProject->make_directory appears to be the target build directory.

[ergonlogic]

In _make_parse_info_file(), we should be able to call a function that does something like:

chdir(dirname($makefile)); 
foreach ($data['projects'] as $name => $project) {
  $project['url'] = realpath($project['url']);
}
chdir($original_path);

[greg-1-anderson]

Make is deprecated. Closing old issues.