In order to use it in torflow's scaling method

Even for a valid domain that usually resolves, sometimes the local DNS
resolver won't be able to resolve it (duh). Catch the exception that gets
thrown in that instance and fail gracefully by returning an empty list.

GH: closes #218

Matt Traudt authored Jun 22, 2018 and juga committed Jun 24, 2018

The chance of us needing a refresh at this point is TINY, but it's probably
better to return a list of relays stale by a millisecond than it is to cause
the user's program to crash.

Matt Traudt authored Jun 22, 2018 and juga committed Jun 24, 2018

I'm not sure if this is necessary, honestly. But it doesn't hurt.

Matt Traudt authored Jun 22, 2018 and juga committed Jun 24, 2018

GH: ref #205

Use the new can_exit_to member func of the Relay class in order to
remove the exits_can_exit_to member func of RelayList, which I never
really liked.

Relay.can_exit_to has the same DNS-based limitations as its older
brother.

Part of this takes care of... GH: closes #145

to make it less confussing.
Note that stem call it ed25519_master_key instead of
master_key_ed25519, but dir-spec.txt uses master-key-ed25519, which
is the term chosen here.

Matt Traudt authored Jun 07, 2018 and juga committed Jun 10, 2018

With unused support for ed25519 keys

* RelayList is now a list of RelayNS instead of RouterStatusEntryV3
  to have master_key_ed25519 as an attribute
* create pytest fixture to start Tor with tests
* create test to check master_key_ed25519

GH: closes #144

that most likely can exit to the given host:port

GH: closes #67

May have some runtime bugs still. Needs a little more testing

GH: see #67

GH: closes #57

Hopefully everything works first try