timcase / echowrap Goto Github PK

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

Echowrap.song_search(
    :title => "Born to Die", 
    :artist => "Lana Del Rey", 
    :song_type => "studio",
    :bucket => ['tracks', 'id:7digital-US'],
    :limit => true).first

results in

#<Echowrap::Song:0x007f3b829a6a90 @attrs={:title=>"Born To Die", :artist_name=>"Lana Del Rey", :artist_foreign_ids=>[{:catalog=>"7digital-US", :foreign_id=>"7digital-US:artist:1107056"}], :tracks=>[{:album_type=>"unknown", :release_image=>"http://artwork-cdn.7static.com/static/img/sleeveart/00/015/712/0001571223_200.jpg", :album_date=>"2012-01-27", :foreign_release_id=>"7digital-US:release:1571223", :preview_url=>"http://previews.7digital.com/clip/17296574", :catalog=>"7digital-US", :foreign_id=>"7digital-US:track:17296574", :album_name=>"Born to Die", :id=>"TREKOIE135C7E8E556"}], :artist_id=>"ARICLSK131AAE25F5E", :id=>"SOJJEAF144BDB4FA1B"}>

Accessing result.tracks.first.album_name throws error.

I wasn't sure if you'd want to change the Echonest in the wiki docs to Echowrap. Echonest.artist_biographies did not work in pry but Echowrap.artist_biographies did.

Echonest.artist_biographies(:id => 'ARH6W4X1187B99274F', :results => 3) =>
[<Echonest::Biography:0x007ffea32c20c8...

to:

Echowrap.artist_biographies(:id => 'ARH6W4X1187B99274F', :results => 3) =>
[<Echonest::Biography:0x007ffea32c20c8...

I've been trying to find a way to determine the current rate limit while using the echowrap gem. Unfortunately I can't find any documentation or examples that show how to find it. Is this a feature echowrap offers? Thanks and great work @timcase

https://github.com/timcase/echowrap/blob/master/lib/echowrap/error/client_error.rb#L19

ClientErrors are built from HTTP responses with body such as:
{"response": {"status": {"version": "4.2", "code": 5, "message": "Identify data is not valid, be sure that the data is valid JSON and not urlencoded: data is not properly json-encoded"}}}

Yet, presumably because body.nil? is false, the error object's message property isn't set to response[:status][:message]

It appears the exceptions raised to the calling code do not include the backend error message, rendering debugging difficult.

I get a bad request response when using the song_profile endpoint with the tracks in the bucket using the very same example as in the specs:

irb(main):009:0> p Echowrap.song_profile(:id => 'SODJXOA1313438FB61',
irb(main):010:1*                             :bucket => ['artist_familiarity',
irb(main):011:2*                                         'artist_hotttnesss',
irb(main):012:2*                                         'artist_location',
irb(main):013:2*                                         'audio_summary',
irb(main):014:2*                                         'scores',
irb(main):015:2*                                         'song_currency',
irb(main):016:2*                                         'song_discovery',
irb(main):017:2*                                         'song_hotttness',
irb(main):018:2*                                         'song_type',
irb(main):019:2*                                         'tracks',
irb(main):020:2*                                         'id:7digital-US'])
Echowrap::Error::BadRequest: 
    from /home/niko/.gem/ruby/2.1.0/gems/echowrap-0.1.0/lib/echowrap/response/raise_error.rb:21:in `on_complete'
    from /home/niko/.gem/ruby/2.1.0/gems/faraday-0.9.0/lib/faraday/response.rb:9:in `block in call'

The specs do run though. I guess there's something mocked which has since changed behaviour.

Niko.