Units equivalency context manager -- mostly for dimensionless angles - #1593

@mdboom - I do think it is important to be able to turn off the context temporarily (and this is needed in decompose to avoid roundtrip). but we could do it the other way around: we could always add to the list and have the default remain equivalencies=[]; then, we could newly determine that equivalencies=None means "never use equivalencies at all". Maybe I just go ahead and do that... (as well as the reset part).

@mdboom - OK, I changed None vs [], and now add global equivalencies by default. Definitely cleaner

In addition, I thought I should really pre-normalize equivalencies in the registry -- which was a bit of a can of worms, since Unit does not yet exist when UnitsRegistry is defined. I ended up making _normalize_equivalency a function outside of the Unit class, with an call to it from within that also adds the global equivalencies if required. Hope this makes sense.

Apart from my documentation comment, I think this is looking quite good.

@mdboom - yes, indeed, much better -- especially if equivalency moves out of quantity, this will be much more generally useful. Now done (plus some clean-up of that page; sorry if that makes it quite a bit less easy to check).

That doc looks much better. I think this is in good shape, and as you say, makes the removal of equivalencies from Quantity feasible, since there's something good to replace it with.

@mdboom - OK, thanks! (and spelling corrected).

@mdboom, @astrofrog - the travis sphinx failure would seem to be related to modelling rather than this PR. Perhaps a problem with a random number? I thought I'd pass it on rather than uploading a no-op change to get it to rebuild.

@mhvk: At this point, this needs a rebase anyway. Would you mind doing that? That should also trigger a rebuild of Travis...

@astrofrog, @mdboom - I rebased and pushed but Travis doesn't seem to start. Any idea?

Note: somewhat sillily, I rebased this one rather than #1161; do you want to consider both together here? I'm not sure how to get #1161 in order without redoing the edits.

@mhvk - I think Travis was just under heavy load. I restarted the build manually.

@mdboom - with some hopefully final corrections, the documentation will now hopefully build; I hope this can still be merged before #1662...

Finally managed to get the context manager documentation bug-free as well. @mdboom: would you consider this to be ready to go in?

This looks really good and ready to merge, aside from the very minor comments.

However... we're working on top of each other a bit today. I just filed #1662 which simplifies the use of the context manager and combines add_enabled_units and add_enabled_units_context into one. I wonder if you wouldn't mind rebasing this branch on that branch and doing the analogous simplification for the equivalencies context managers. (Or I can do that as a PR against this one once #1662 is on master and this has been rebased on master). I just think those context managers are really ugly if you can't use them both ways.

@mdboom - I tried rebasing and while I am not yet done, it seems less bad than I feared. In any case, fine to go ahead as far as #1662 is concerned.

@mdboom - OK, it was not bad at all -- I do like the new way of doing it, much cleaner! Note that I took the liberty of adding some comments also to your set_enable_units, etc., as it did take me a while to figure out what was going on.

We're getting this doc error:

/home/travis/build/astropy/astropy/build/lib.linux-x86_64-2.7/astropy/units/core.py:docstring of astropy.units.core.set_enabled_equivalencies:26: ERROR: Inconsistent literal block quoting.

Other than that, I think this is good to go, and thanks for handling the 11th hour update to the less complicated context managers.

@mdboom - this finally passes everything. So, once #1161 and #1662 are in, this can go in as well.

@mdboom - p.s. you comment on the wrong initialisation in the _UnitRegistry made me realise that part should be tested as well. I now added tests that add_enabled_equivalencies and set_enabled_equivalencies do what they are supposed to.

@mhvk - it looks like this needs rebasing?

@astrofrog - hmm, odd, maybe because of #1634? (actually, how does one see whether it needs rebasing?) Since #1161 and #1662 may also suffer from this, perhaps it is best for me to wait until those are in, and then rebase.

@mhvk - if it says "We can’t automatically merge this pull request." it means you need to rebase. Sometimes it's something as simple as a CHANGE.rst addition conflicting.

@astrofrog - I don't see that -- but checking on my own repository, I do see it there, so I guess this is simply hidden from people who do not have merge rights. I guess the way around it is to simply try it locally, a la

git fetch upstream
git checkout upstream/master
git checkout -b merge-trial
git merge units-angles-dimensionless-context

Oddly enough, though, that actually works...

Anyway, as said, #1161 and #1662 should really go in first (unless you want to do it in one fell swoop). Since apparently I cannot test this locally, is #1161 OK?

Oh that's annoying (only committers can see the message).

Merged (manually).