Second copy of modules directory after drush make run

Please post the log of running the same command with --debug.

Also, try using the dev (2.x) version.

I have been experiencing a similar issue while trying to build a drupal-org.make file. I believe davidfells means this -

If you already have a directory named "modules" in your working directory, Drush Make will place downloaded modules in a directory called ./modules/modules

Steps to repeat:

1. Create a directory named "modules" in the working directory (in our case, we need such a directory to contain custom modules that will ship with our profile).
2. In the working directory, create a make file like the following:
   

   ; Drupal core version.
   core = 6.15
   
   projects[views][version] = 2.8
   projects[views][subdir]  = contrib
   

3. Run drush make --drupal-org [filename].make

Expected Result:
Modules are downloaded to the ./modules directory (e.g., ./modules/contrib/views)

Actual Result:
Modules are downloaded a ./modules/modules directory (e.g., ./modules/modules/contrib/views)

this is due to the way the command mv works. I'll see if there is a flag which can stop this behavior - because what Drush make does is non-recursively copy all files over from a working tmp directory.

this is due to the way the command mv works

Ah, very interesting. That makes sense.

It looks like the -T flag is what you're looking for. I'm not exactly sure how Drush Make is architected, but here's a basic example of -T usage:

Original Directory Structure:

./dir/subdir/file1
./subdir/file2

mv subdir dir/subdir creates the following structure:

./dir/subdir/file1
./dir/subdir/subdir/file2

mv -T subdir dir/subdir creates the following structure:
./dir/subdir/file2

Of course, that bashes file1. Maybe some combination of the -T flag and some basic merging will do the trick.

Or you could always use a combination of cp and rm to do the same thing. For example:

cp -r ./subdir ./dir/subdir
rm -rf ./subdir

I tried to solve it with mv parameters, but didn't find any parameter working in all cases.

The patch tests if the destination dir exists, and uses cp -rf is so.

Fact is we overwrite already existing modules (without removing old files). A notice would be nice here, maybe we need to run update.php if we overwrite a project with a new version.

Let me know, then I will add a notice per module.

Realized last patch is only solving it when $base_path = '.'

New patch with deleting existing project and warning.

#7 patch seem to work with my intended workflow. I already have drupal core installed in `www`. My layout look like:-

$ ls drupal6-base
core.make contrib.make sites www

`sites` is already generated skeleton with `all` and `default` directory. Now I want to run the following command:-

$ drush make --working-copy --no-core --contrib-destination=./sites/all contrib.make

and have all the modules and themes downloaded into `sites/all/modules` and `sites/all/themes` respectively. Over the time I might add new project into contrib.make and re-running the command would download the newly added project. Would be nice if drush make could check first whether the project already exists (and up to date) rather than just redownloading everything again.

Look like there's some nasty bug with patch in #7. My hg clone just been wiped out (or not copied). My .make file:-

core = 6.x

projects[drupal][download][type] = "hg"
projects[drupal][download][url] = "http://bitbucket.org/k4ml/drupal6-core/"

$ drush make --working-copy core.make drupal6-core
or
$ drush make core.make drupal6-core

drupal6-core directory is not created. Here some output with drush make --debug:-

mv: cannot stat `/tmp/drush_make_tmp_1270541125/__build__/robots.txt//tmp/drush_make_tmp_1270541125/__build__/robots.txt': Not a directory
Executing: ls -A '/tmp/drush_make_tmp_1270541125'/__build__/'scripts' [12       [notice]
sec]
  code-clean.sh
  code-style.pl
  cron-curl.sh
  cron-lynx.sh
  drupal.sh
Executing: mkdir 'drupal6-core'/'scripts' [12.004 sec]                          [notice]
  mkdir: cannot create directory `drupal6-core/scripts': No such file or directory
Executing: mv                                                                   [notice]
'/tmp/drush_make_tmp_1270541125'/__build__/'scripts/code-clean.sh'
'drupal6-core'/'scripts/code-clean.sh' [12.007 sec]
  mv: cannot move `/tmp/drush_make_tmp_1270541125/__build__/scripts/code-clean.sh' to `drupal6-core/scripts/code-clean.sh': No such file or directory

Not sure if this helps, but I was having this problem and solved it by removing (or moving) the existing modules & themes folders out of the way before running the make command. Mine were stored in an install profile folder, so I was seeing /profiles/profilename/modules/modules.

That's the problem, you have to delete existing folders which mean it only useful for one off operation. You can't 'incrementally' add stuff your .make file, re-run it to get the newly added module.

I still can't find a way to solve this. cp -a while work quite well and simpler, doesn't copy hidden directory (.hg, .git etc). Using tar I have the problem with the leading path and have to use --strip-components which I think useless unless we know the number of components to strip to get back original directory structure.

@k4ml regarding #9

The patch in #7 still only worked when $base_path = "." , not when $base_path = "drupal6_core".

Even this should work now and keeps your .hg directory:

drush -d make --working-copy core.make drupal6-core

From #8:

Would be nice if drush make could check first whether the project already exists (and up to date) rather than just redownloading everything again.

This seems not easy to implement, so I won't work on this. Redownloading is cheap these days.

Please test this new patch!

I am using this patch right now to avoid the modules/modules/ directory effect. Works as expected. Setting to NR to catch the maintainer's attention :-)

Oddly, I run into this on one server, but not another. Both servers have local git repositories that include some custom modules. As I'm building the site on one server, I'll use git push, and then git pull on the other server and run ./rebuild.sh, and it create the improperly nested folders. ./rebuild.sh on the original server does not cause that. Any idea why it works on one and not the other?

After I run the patch from #7, .htaccess file is created as a directory. Afterwards I am not able to access my website because .htaccess file is missing.

Can you try adding a tests? There's a new section in README.txt describing how to do that.

I decided to take a completely different approach

Was this fixed in beta8? What was the different approach?

it was - i used cp -rn i believe