Seperated functionality into OO-based webrepl API

[eduvik]

Seperated functionality into OO-based webrepl API (webrepl_client) that can be used by other python programs, and refactored webrepl_cli to use this library

[pfalcon]

webrepl_cli.py is intended to be both a command-line client and library. Please don't introduce any dependencies into webrepl_cli.py. It also must run on micropython, cpython2, cpython3.

[eduvik]

What's the use case for running on micropython?

The current code doesn't work as a library due to reliance on getpass to get the password.

Any objections to moving the oo version into the webrepl_cli.py file?

[pfalcon]

What's the use case for running on micropython?

Everything should run on micropython.

The current code doesn't work as a library due to reliance on getpass to get the password.

This should be fixed.

Any objections to moving the oo version into the webrepl_cli.py file?

Universal rule of thumb of contributing to any project: avoid making big changes at once. Especially avoid starting to contribute in such way.

[eduvik]

What's the use case for running on micropython?

Everything should run on micropython.

And indeed, my code should (not tested, but no dependencies there, unlike the existing code which won't run on micropython). I'm still curious about why you'd want this running on micropython.

Universal rule of thumb of contributing to any project: avoid making big changes at once. Especially avoid starting to contribute in such way.

I've retractored the code to be oo; haven't actually changed much at all. Go ahead and reject the pr if you want; I've got a particular use for the code I've written and will be using it, but thought I'd contribute back. The vibe I'm getting is that this isn't a project I want to participate in...

[pfalcon]

You're welcome to get any vibe, including the one communicated to you plainly and directly: if you're interested in your patches to be merged quickly, please avoid submitting "revolutionary" patches, painting everything green and red. The reason for that should obvious to any developer, and yet it is not, so let me explain: if you receive a patch which changes every other line in your project, you won't be happy about it. Ditto for any other project which receive such patch from you.

Go ahead and reject the pr if you want

It will hang around until someone will find time to look into details of it, which be long, because it's 1/1000th of things we're working in micropython. In the meantime, it will start to conflict with changes done to the original source, so will become truly, not perceptibly, unmergeable.

[eduvik]

I can understand and agree with all of what you are saying, but the way you say them makes a big difference to whether the project attracts or repels people who want to help with them.