Find a country based on an EP.org URL slug

[octopusinvitro]

This PR allows to make a search for a country or for a legislature using uppercase or lowercase queries.

Closes #17

[tmtmtmtm]

I'm a little hesitant to even semi-document searching by these fields by enshrining them into tests. They do currently work, but I'd be inclined to treat that as accidental rather than deliberate. Or, from another angle, I'm not so sure that if an implementation change were to break these, we'd care…

I'm open to persuasion that this is something we actively want, though…

[octopusinvitro]

Do you mean I should use other fields instead for the test, like name or slug? (I chose those randomly)
Or that the whole test should disappear?

I'm happy to remove the test, but in that case, do you think it would be a good idea to then simplify the code it tests, so that we don't have untested code? For example, replacing:

    def legislature(query)
      query = { slug: query } if query.is_a?(String)
      legislature = legislatures.find do |l|
        query.all? { |k, v| l.__send__(k).to_s.downcase == v.to_s.downcase }
      end
      fail Error, "Unknown legislature: #{query}" if legislature.nil?
      legislature
    end

with:

    def legislature(query)
      legislature = legislatures.find do |l|
        l.__send__(:slug).to_s.downcase == query.to_s.downcase }
      end
      fail Error, "Unknown legislature: #{query}" if legislature.nil?
      legislature
    end

This would also be more in line with how we documented the code in the README, where we are telling people to pass the slug to the method.

What do you think?

[tmtmtmtm]

My original objection was to testing searches against lastmod and person_count. Those currently work, but I'd say that's by accident rather than design, and I'm wary that explicitly testing them means we're essentially increasing the commitment to keeping them working. (Not guaranteeing it, but making it significantly harder to drop support for it.)

On reflection, however, I think that's also true of the whole concept of being able to pass multiple key-value pairs to find. As per the discussion yesterday, that's also something that largely works by accident, rather than being officially supported.

It's definitely worth raising an issue to simplify the code (or to officially document and test it), but that seems to be too big an en passant change for this PR.

[tmtmtmtm]

The bulk looks good, but I'm not so sure about one of the tests.

I'm also a little wary of this getting blocked by that though, so if we don't get quick agreement on what to do, I'd be inclined to simply skip that test for now, as it's incidental to the main point of the PR…

[octopusinvitro]

@tmtmtmtm @chrismytton I decided to update the tests that document the scenario of searching by more than one field at a time, using the fields that are stable at the moment (name, slug) instead of less stable fields (code, lastmod, person_count), so that we don't necessarily imply a commitment to keeping the unstable ones working, while at the same time we don't have untested code.

That way, the PR can be closed and we can decide later what behaviour we want to support, regarding the fields that we pass to find. I have opened an issue for that, "Official support for being able to pass multiple key-value pairs to the find method", so that we can discuss what we want to do in the issue as opposed to in the PR.

[tmtmtmtm]

@octopusinvitro when I rebased this over master, rubocop was also complaining about .downcase-ing strings to compare them (rather than using casecmp). I'm unconvinced by that one, as I think the whole having-to-check-for-zero thing makes it less legible, so I added an extra commit to disable that check.

I also decided to drop the commits that were adding tests for searches with multiple keys, under the principle that anything extraneous to the PR should be skipped if it's contentious. I'm not convinced that we should be doing this at all, and now that you've opened #33 to consider that, I think these are better off just being omitted until then. I also went ahead with squashing the commits down, adding the release log, and upping the version number, as I wanted this merged rather than having around longer! Hope you don't mind!

[octopusinvitro]

I am not a fan of having untested code, but I also have a high respect for your general judgement.