Add drush make file to download spyc dependency

Duplicate of #1349588: Update documentation and make file relating to Spyc requirement and Libraries integration + make libraries optional the reply there has not changed so please do not keep spaming the issue queue...this is not a bug.

The library as per the committers agreement should not be in repo.

If you provide a patch to do that it will be certainly be considered........

Is there a reason that the Libraries module is not used for the spyc library allowing Drush Make files to explicitly download the library as part of the build and Services to reference the library from a centralized location? That is something that we can likely easily provide a patch for, but it adds a requirement on the libraries module.

As I said if you provide a patch we will consider it but this issue is won't fix as far as the services team is concerned.

And a issue for this already exists #1325572: Integrate services with the libraries module to improve handling of third party libraries. but it isn't bug at the end of the day

Thanks for the pointer.

1) It is generally considered better practice to place third-party libraries that are not included in the source tree in sites/.../libraries not to be download within the source tree.
2) Lets just make a drush_make file...

If the library is changed so it can be located in libraries/spyc then the following will allow it to be cleanly downloaded.

projects[spyc][type] = library
projects[spyc][download][type] = file
projects[spyc][download][url] = http://spyc.googlecode.com/files/spyc-0.5.zip

Until then you need a bit of hax which requires that people have services in sites/.../modules/services and not something like sites/.../contrib/modules/services. This is another reason for moving the location of the library. So currently we end up with the following.

projects[spyc][type] = library
projects[spyc][download][type] = file
projects[spyc][download][url] = http://spyc.googlecode.com/svn/trunk/spyc.php
projects[spyc][download][filename] = "../spyc.php"
projects[spyc][destination] = modules/services/servers/rest_server/lib

Personally, I vote for committing this and then starting a new issues to move the lib location and just update this makefile. That way folks already trying to deploy this pragmatically (like myself) can get it working without all kinds of fuss.

The rest for a drush make file has been asked for before and was rejected last time policy has not changed.

I'm rather lost after that comment...

As I said if you provide a patch we will consider it but this issue is won't fix as far as the services team is concerned.

I seem to have provided a patch which means we move on to the consider part? I re-read the above I nothing jumps out as a blatantly obvious reason for not making this easy for people to use rather than a PITA.

The library as per the committers agreement should not be in repo.

Which based on every other module that gets there means you need a build script....or perhaps linux package building as a pattern.

For those who like to use computers to automate things you can use the following in your make files.

projects[services][version] = 3
projects[services][patch][1355952] = http://drupal.org/files/1355952-drush-make.patch

I'm sorry marcingy, I can't really see how this is a duplicate of http://drupal.org/node/1325572. And using make files that include third party code isn't against any policies, is it?

It's a small change with minimal maintenance costs that simplifies automated deployment. So if there aren't any strong reasons not to provide a make file I fail to see why the patch should be rejected. Please enlighten me if I've missed something obvious.

Cheers,
Hugo

I want to do the same "trick" with Services for D6, so I re-upload the patch, only with core = 6.x

Really can't imagine why this couldn't be committed and it is obvious others want this as well. No fun when your site uses 20+, 30+, 40+ projects with dozen or more having extra libs to download to want to do that manually. It's nice to think that this is just one to download for services, but services is just _one_ project. Not like the 5 line file is a big maintenance hassle (especially since it will likely never change [short of needing a new version of lib]) and drush make is even built into drush now.

Can someone provide a _real_ reason for not committing this? Otherwise, lets do so.

Last patch is invalid since doesn't reference /dev/null since new file. Mine in #13 is fine.

I don't see anything bad in committing patch #13. @marcingy please advise what do we have against it?

I am not really involved in the project at the moment, commit what ever you feel see fit.

Commited to both 7.x and 6.x branches.

Update to the drush make file with /contrib attached and using libraries[] instead of projects[]

I'm not sure this is a good idea, instead I recommend adding a services.make.example file that people can copy into a drush make file.

See this comment from the entityforms module issue queue:
http://drupal.org/node/1701496#comment-6277830

Looks like leaflet, rules, geofield, colorbox, entityforms modules either removed or renamed their module.make file.

The solution is to have services look for the library in libraries/ then you don't need the path garbage and it is all relative.

#13: 1355952-drush-make.patch queued for re-testing.

@gmclelland, that make sense, we do not need it here any more, we can just rename it to make.example so people can copy/paste it.
@boombatower, yes. the only solution I can see is also look for libraries/spyc, but that will make this module dependency of Libraries, it's no big deal.

#26: 1355952-drush-make-26.diff queued for re-testing.

So What needs to be done here? Are we cool with committing #28

Since we already have a drush make file im bumping this to a bug and marking as major.

Id like to get this in the impending 3.2 release which will happen very soon, so any idea on what needs to be done here, just let me know and Ill make the changes/apply the patch.

I think, there is nothing to do with this issues, cause I believe libraries 2.x implementation(#1325572: Integrate services with the libraries module to improve handling of third party libraries.) and download spcy.php to sites/all/libraries would be better than this. Since .make file is meaningless inside the modules folder so we can rename it to make.example or something.

Heads up this does not work with either in the latest version of drush due to #1796252: drush_mime_content_type() returns "application/x-tar" when it should not.

Seems like committing #28 is fine as sites/.../libraries is the real solution.

Fixed, thanks guys.

Using a make file that contains only drupal core and services, and running drush make my_custom_site.make www, I consistently get this error:

Directory not empty: /tmp/drush_make_tmp_1352479597_509d336d54cd3/__build__/modules/contrib/services/servers/rest_server/lib    [error]

That lib directory contains two other files, so drush is complaining about it. The problem is actually with the version of drush that we are using. When using the latest version of drush, we do not have this problem. However, other issues are currently preventing us from upgrading drush.

In case other people encounter the same problem, I'm posting a patch that removes the make file. This is fine for us because we are already installing spyc separately.

I have a similar problem in a production environment where I'm stuck on Drush 4.6.

I have attached a patch for the latest 3.x version.

I use a distro and I cannot upgrade Services on my sites until this issue is resolved. Using drush 4.5 and cannot upgrade to latest Drush for other reasons. Would like to know how & where to install Spyc separately if that would workaround the problem.

Re-opening this issue to fix the above problems.

This is not major

guys, why do you report problem with older version of the drush? This is out of our control. If you have this problem please add bash commands to download spyc library and remove make file from services for your local instances (patch #40).

Because ideally we ought not to rely on Bash as everyone's setup is not the same to inject bash commands as necessary. Major modules like Services need to also be backward compatible with still heavily used versions of drush such as 4.6.

To state my problem simply, try running the following make file:

; Drupal core
; -----------
core = 7.x
projects[drupal][version] = 7

; Drush Make API version
; -----------
api = 2

; Contrib modules
; -----------

projects[libraries][version] = 2.1
projects[libraries][subdir] = contrib

projects[services][subdir] = contrib
projects[services][version] = 3.3

projects[services][patch][] = http://drupal.org/files/services_drush_make_1355952-40.patch

libraries[spyc][download][type] = "get"
libraries[spyc][download][url] = "https://raw.github.com/mustangostang/spyc/master/Spyc.php"
libraries[spyc][filename] = "../spyc.php"
libraries[spyc][directory_name] = "lib"
libraries[spyc][destination] = "modules/contrib/services/servers/rest_server"

as

`drush make myprofile.make --no-core testservices`

The output is attached. Even using the patch from #40 there did not help.

I was expecting perhaps the module could work with having Spyc downloaded to libraries/ folder instead of within module, which would make it work with both versions of drush.

Drupal core has no concept of backwards compatibility and services does not either, so this issue is closed please update your drush version.

I understand it's like flogging a dead horse here. I will not pursue the matter further as nobody wants to make this better. However, to state there is no backward compatibility reminds me of this article and that the only way to automate the installation of Services is to use a bash script sends shudders down my spine! I will try my best to inject some bash script if I can. Perhaps I will end up just not upgrading Services. I think I stated clearly there are other reasons why I cannot upgrade Drush (as did others).

girishmuraly, applying the patch does not work for you?

Not in the way as stated #41 and #45

@girishmuraly we are simply adhering to common drupal practices, and if you can't upgrade drush maybe you need to look at new hosting provider?

* updated the patch for the current version

(The current version did not work, perhaps because the content is different)

Rerolled patch against HEAD.

Rerolled to match #2200269: Fix make file for drupalorg whitelist

Can you open a new ticket explaining the current issue?

This is not a new issue.
As Services maintainers decided to keep a .make file even if it breaks most of distributions build script, we're "just" maintaining a patch which remove that file.

Sorry, but :

1. Spyc is absolutely not a hard requirement for Services (for example, if you're not using rest_server or if you use it only with JSON content type);
2. The common practice regarding drush make is to provide a .make.example so that drush make users can copy its content to their own distrib .make file.

   Others did get through this already, see :

   • Entityform : https://www.drupal.org/node/1701496#comment-6277830
   • Rules : https://www.drupal.org/node/1329346
   • Colorbox : https://www.drupal.org/node/839580
   • Geofield : https://www.drupal.org/node/1152088

I'm not gonna argue on this topic once again, I just need a .patch to remove the .make file to be able to put Services in a distro .make. I'm just keeping it up to date with HEAD (and @tobiasb too, see #52)

Forgive me, I haven't seen you argue on this topic yet?
Second you don't have to apologize for being clear and concise.

If its more of a standard practice to provide a make.example, then lets get a patch that does that instead of bickering about what to put in the current make.file?

This comes up a lot and everyone seems to have a different opinion on it. Frankly I'm really tired of seeing .make issues so I'm all for making it an example.

This patch renames services.make to services.make.example

This patch renames services.make to services.make.example

Patch committed and pushed, thank you all.