python 3 support

[sijis]

Is there any work/thoughts on getting this library to work under python 3?

[whiteinge]

No work yet but many thoughts. Python 3 support would be very cool and probably not too much work. It will also easily allow concurrent operations that aren't easily done in Python 2. I've written an asyncio function to consume the HTTP stream from salt-api and something like that would be a great addition to Pepper. It would allow us to display live minion returns on the Pepper CLI as they come in to Salt in addition to all the programmatic utility of watching the event stream via libpepper.

[sijis]

@whiteinge I'm gonna be poking around the libpepper.py file as i currently have a dependency on it right now. I briefly tried but setup.py flipped out about the version not being compliant.

the asyncio stuff sounds fantastic.

You should see some hack/attempt in the next day or so from me.

[sijis]

I'm still having some issues with setup.py, as the version isn't pep-0440 compliant (I probably have to do something with git tag/describe).

I'll probably submit another PR or two as i work through this.

[whiteinge]

I'm happy to move the git hash out of the version number and into the project metadata as the pep suggests if that would make things easier on you. I'm fuzzy on how to actually reference that metadata after the install has been done though.

[sijis]

The exception here https://github.com/saltstack/pepper/blob/master/pepper/__init__.py seems to gather version details post-install. It's just looking for the version.json file.

The simplest thing I can think of is manually adding the version to the json fie, including the project metadata you want added.

Moving the git hash would definitely help.

[whiteinge]

The idea is:

1. If you're running Pepper out of the Git repo directly (for development) that file calls out to git describe on request by calling into the setup.py file.
2. If you run setup.py sdist for PyPI or to make an installer it runs git describe and stores the result in version.json.

We could keep that same workflow with the following changes:

1. Look to see if -g exists in the git describe output. If so,

2. Break the output of git describe into it's constituent parts:

   >>> re.search('(?P<version>.*)-(?P<num_commits>[0-9]+)-g(?P<sha>[0-9a-fA-F]+)', '0.3.0-22-g867a264').groupdict()
   {'num_commits': '22', 'sha': '867a264', 'version': '0.3.0'}

3. Modify the setup.py file to only put sha into the setup_kwargs metadata maybe as git_hash and assemble the actual version number with the pep-recommended "dev" text and use the number of commits as the incrementer. E.g., 0.3.0-dev22.

Do you think that would work?

[sijis]

I think its a solid idea.

[whiteinge]

Added!

[whiteinge]

Per fbe6886 and #64 let's declare Python 3 support a thing and any problems from here on out will be considered bugs.