Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The inclusion of a nested drush make file in this project it makes life difficult for those of us utilizing a drush-make-based workflow. It also has recently broken since the URI for openlayers has just gone down this afternoon.
To put it succinctly: It 'should' be up to us what version of the openlayers library is used, not your module.
Other modules have come across this issue before and the consensus has been to remove the drush make file. E.g.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | openlayers-remove_make-2232445-6.patch | 416 bytes | jaxxed |
| #1 | openlayers-2232445-remove-drush-make.diff | 421 bytes | jamsilver |
Comments
Comment #1
jamsilver CreditAttribution: jamsilver commentedComment #2
jamsilver CreditAttribution: jamsilver commentedComment #3
PolI've read all the comments and I won't remove the file right now, maybe later, but right now, it's helpful for a lot of people.
Comment #4
adrinux CreditAttribution: adrinux commentedI've always found the best approach is to include it but disable it by renaming, e.g. openlayers.make.example
That way it's there for people to use in their make files but doesn't break automated platform building with drush make when the url changes. As it has done again now...
(edited to add)
The problem is that a make file within a module will always override any other, that's the way drush make is built. Workarounds for anyone building platforms and distributions with drush make is to patch the module or do a manual install. Both of which rather spoil the effect of supplying a drush make file with the module in the first place.
Comment #5
PolComment #6
jaxxed CreditAttribution: jaxxed commentedI am running into drush make errors because this make file has an error in it. This breaks the entire deployment/release process. I will be including this patch to remove the file in my build scripts.
You should reconsider having this file, as it is not safe enough. It might be nice to have, but it breaks some Drupal best practices used for delivery. It might sound like an inconvenience, but it is a deal-breaker for strict deployment environments for the professionals.
If this was on production, I would have to completely sidestep my deployment process, ssh into the box and manually build the site. In some cases I don't have access ssh access (just jenkins) and so cannot work around this issue.
Close this issue again if you still think it is a moot problem.
I am updating the patch to point to 2.x dev branch from today.