Auto web3

[sbc64]

What was wrong?

This request provides a solution for: https://github.com/pipermerriam/web3.py/issues/302

How was it fixed?

The auto module configures a web3 instance instance for you. If you don't specify which provider you want it will default on IPC first, then HTTP.

Cute Animal Picture

(I'm starting to hoard cute animal pictures on my phone)

[carver]

Looks great! Excited to have this in. Just a couple pieces of feedback.

[carver]

Right now, this is opening more connections than it needs to:

1. It connects to http even if ipc is available (on module import of http)
2. It re-attempts the connection that was already tested during module import

You could get around both of those issues by switching to a dynamic import and using the w3 already defined, looking something like:

for connector in ('ipc', 'http'):
    connection = importlib.import_module('web3.auto.%s' % connector)
    if connection.w3:
        ...

---

It could be nice to give these modules a consistent interface, something like ipc.connect() and http.connect(). Not critical, though.

[sbc64]

I like the ipc.connect() and http.connect(), makes it clearer.

[carver]

It doesn't look like this will cover the major operating systems, for geth. Take a look at how the IPC module does it: https://github.com/pipermerriam/web3.py/blob/master/web3/providers/ipc.py#L38-L65

In fact, it might be better to just initialize IPCProvider() without any args, which will automatically look for the geth file.

---

Nice that it looks for the parity path! Can you add in support for parity on other OS's, too?

[pipermerriam]

I would be supportive of just adding the parity paths to the web3.providers.ipc.get_default_ipc_path function. In fact, I think it would be good to modify that function so that rather than just returning a path, it enumerates a number of different paths and checks to see if there is an IPC socket in place that it can connect to and returns the first one.

Order of operations I would like to see on that is:

1. go-ethereum (mainnet)
2. go-ethereum (rinkeby)
3. go-ethereum (ropsten)
4. parity (mainnet)
5. parity (ropsten)
6. parity (kovan)

[pipermerriam]

A few suggested changes.

[pipermerriam]

It's nice to be able to configure this type of thing using environment variables. This can be done something like the following.

w3 = Web3(HTTPProvider(
    os.environ.get('WEB3_HTTP_PROVIDER_URI', 'http://localhost:8545')
))

This allows for this functionality to be used beyond just localhost.

[pipermerriam]

I would be supportive of just adding the parity paths to the web3.providers.ipc.get_default_ipc_path function. In fact, I think it would be good to modify that function so that rather than just returning a path, it enumerates a number of different paths and checks to see if there is an IPC socket in place that it can connect to and returns the first one.

Order of operations I would like to see on that is:

1. go-ethereum (mainnet)
2. go-ethereum (rinkeby)
3. go-ethereum (ropsten)
4. parity (mainnet)
5. parity (ropsten)
6. parity (kovan)

[pipermerriam]

I'm thinking that it may not be good to instantiate this here since it's done in web3.auto

[carver]

This supports the API from the issue:

from web3.auto.http import w3

Which would give you an autocreated http connection even if an IPC one exists. I suppose we could revisit whether that's necessary. I don't have a strong use case for it, it just seemed like a good idea in the abstract.

[carver]

Also, this comment should address the double-instantiation issue: https://github.com/pipermerriam/web3.py/pull/344#discussion_r143795348

[sbc64]

Thanks for the feedback. I will work on the recommendations.

^.^

[sbc64]

My two cents on the issue of whether to use from web3.auto.http import w3 and from web3.auto.ipc import w3.

I don't think people will be running three different ethereum clients, maybe me to test this implementation. They will likely be running a single client. I might be wrong on this but it is usually testrpc or parity or geth.

Using from web3.auto import w3 is enough to find the current client running.

[carver]

I'm happy with going that direction: either you're using a simple, single-client setup and can use from web3.auto import w3 or you have multiple clients and you need to specify the provider explicitly. That doesn't seem like an unreasonable burden.

[pipermerriam]

Same here. Maybe remove this instantiation since it's done independently in web3.auto?

[carver]

Cool, I'd love to get this into the upcoming beta. I included a few "nice-to-have" suggestions, but I don't think they should block merging.

[carver]

This check looks redundant: if w3 is set, then isConnected() is True

[carver]

A utility function like first_available_path(paths) could maybe remove some of the repetition here.

[pipermerriam]

One change requested assuming my remembered knowledge of constructing paths on various operating systems is accurate.

[pipermerriam]

I think these should still use os.path.join to construct these paths as it will use the proper path separators for the os.

[carver]

Heh, I've been out of windows for so long that I don't remember what \\.\pipe\geth.ipc even means.

@Sebohe because of the '\' start, it wasn't intuitive to me how to use join here. This was the first way I could find to do the join: os.path.join('\\\\', '.', 'pipe', 'geth')

It looks like this is the last change needed to get merged.

[pipermerriam]

I so wish we had windows CI to know that this works.... 😢

[carver]

Tagging #166 for motivation.

[sbc64]

I tested it on my windows machine if it is of some consolation to you. I couldn' get seperated "\\", "\\" to work. It would merge them to one \. That is why I used 4 backslashes.

[sbc64]

I also had geth and parity running while doing my in house testing, but I agree a more thourough test would be comforting.

[pipermerriam]