do a spike to try having countries in separate repositories (installing core code from pypi)

[mhl]

@evz suggested that it would be easier to reuse YNR if the code specific to a particular country was in its own repository, which then used the core YNR Django code as any other django-application installed from PyPi. As an example, datamade took this approach for councilmatic:

• main app: https://github.com/datamade/django-councilmatic
• per-city apps:
  • https://github.com/datamade/chi-councilmatic
  • https://github.com/datamade/nyc-councilmatic

There are various advantages from our point of view to having all the countries in one repository. e.g. those that occurred to me when discussing this earlier were:

1. you can't have any issue with version skew between the country and the core code, especially helpful when the code is in early development and changing fast
2. from the point of view of tooling it's easier to have everything in a single repo (e.g. a single git grep invocation will find every use of an identifier), the "switch country" script can be simpler, etc. - this isn't a particularly strong reason, i concede, because you can just script those things
3. now there are per-country tests, it's easier to test that a change isn't breaking a particular country
4. there are some changes planned for the near future that will affect every country

On the other hand, reusers of the code are left with some not very appealing options to work on their own version of the site, basically either:

• Having to make frequent pull requests after rebasing to get their work into the upstream master
• or maintaining a long-running fork

Making YNR a django application which is on PyPi and easily reusable by country-specific sites / repositories would mean that neither of those are an issue, and more generally seems like a better architecture.

I'm not really sure how much work would be involved in this refactoring, however, so I'm suggesting a two day spike to see how hard it would be.

[struan]

It would also presumably avoid the issue of what are essentially blessed election slugs being used by other people and unexpected things happening when they ran migrations.

[evz]

Just for the record, this approach combined with #653 would make re-deployment quite a bit simpler and would allow a deployed instance to be pegged to a release that would just "work" until a maintainer got around to updating to a newer YNR release.