Distribute a Python 3 compatible version on PyPI

[GoogleCodeExporter]

Hi. According to the homepage, this library is Python 3 compatible. However if 
you try to install it from PyPI eg. with the command `pip install python-ntlm` 
then installation fails with syntax errors (print function missing brackets and 
so on).

The problem is the package at https://pypi.python.org/pypi/python-ntlm has only 
works on Python 2 AND has no compatibility information in its metadata.

Please upload a Python 3 compatible package to PyPI. You could have one package 
that's compatible with both Python 2 and 3, or two separate packages, so long 
as you set the version metadata appropriately.

Thanks. This would be really appreciated. 
-Matt

Original issue reported on code.google.com by matt.hickford on 5 Feb 2014 at 3:02

[GoogleCodeExporter]

Hi Matt.
I just came in the project. I tested a bit with python3 and I think there is 
bugs in the python 3 version that are not in the python2 version. So I'm not 
willing to release the python3 version yet.
I will update the metadata saying that python-ntlm does not support python3 so 
far.

Original comment by deron...@gmail.com on 2 Oct 2014 at 2:14

[GoogleCodeExporter]

Hi there, 

Would you like some help? I'm have a package that relies on this one, and I 
would love to have it work on Python 3. I'm happy to help fix bugs and test. 

thanks,
Rachel

Original comment by rcord...@gmail.com on 3 Oct 2014 at 9:26

[GoogleCodeExporter]

I would love to.
Feel free to contribute and submit patch. If they applies and doesn't break 
things, I will commit them.
Currently we need a way to distribute the python 3 version and I don't know 
distribute enough to do it. (there is already a setup.py in the python26 
directory that occupies "python-ntlm" on pypi. How can we cope with this to 
distribute the python 3 version ? Do we have to use a different name ? Can we 
make the current setup.py ship the both versions ?)

Something even more amazing would be supporting python 2 & 3 in the same file 
using six, rather than maintening two separates versions, with their own set of 
bugs and features (but:
1. I am lazy
2. I don't use ntlm anymore
3. I don't have enough IIS infrastructure to test that I did no regressions)

Every contribution is welcome :)

Original comment by deron...@gmail.com on 21 Oct 2014 at 2:15

[GoogleCodeExporter]

Ideally there'd be one package—one code base—compatible with both Python 2 
and 3. This is possible—the helper library 'six' is an aid—but it'd be a 
significant piece of work to port python-ntlm. I wouldn't attempt to do this 
without first setting up thorough tests and continuous integration.

Alternatives:
* Create a second package on PyPI (perhaps python3-ntlm) from the second code 
base. This is awkward for devs and users both.
* Do clever switching in setup.py to choose between the code base. I've not 
seen this done before. If it worked, it would be nice for users, but still 
awkward for devs.

Original comment by matt.hickford on 21 Oct 2014 at 9:04

[GoogleCodeExporter]

Please don't follow Matt's suggestion. requests had to deal with this for 
chardet and python3-chardet and it was absolutely awful. As of ~1.5 years ago, 
this was incredibly error-prone and a reason why I forked chardet to make it 
work under one codebase. The reality is that testing infrastructure is needed 
and if it will help, Rackspace will give you a huge discount for hosting since 
this is an open source project. If you email me, I can put you in contact with 
the person who organizes this. python-ntlm is used in OpenStack (if I remember 
correctly) so Rackspace will have an extra incentive to help you set up jenkins 
and other services to help you test this.\

Original comment by graffatcolmingov on 21 Oct 2014 at 9:18

[GoogleCodeExporter]

To be clear, I wasn't advocating that third option, just listing it. The first 
option would obviously be best.

Original comment by matt.hickford on 21 Oct 2014 at 9:53

[GoogleCodeExporter]

I would third having one-codebase thing. It can be a giant PITA to get working, 
especially when you do things close to the wire like this one does, but it's 
worth it.

Are you against moving to github? Travis integrates really nicely with github 
and tests across multiple versions of Python beautifully.

If you want, I'm happy to do the work of creating the repo in github, setting 
up travis and watching pull requests. I created a library that uses python-ntlm 
which I would love to port to 3: https://github.com/linkedin/pyexchange so I 
have some motivation there.

No worries if you don't, just thought I'd offer.

Original comment by rcord...@gmail.com on 28 Oct 2014 at 8:17

[GoogleCodeExporter]

It would be a really good thing. The problem is, there is no more official 
maintainers. I know the original creator (samwyse) won't work anymore on it, 
and the package manage is okay to create new release wherever they come from.

The important thing is: we need an alive maintainer that can change the 
google-code front page saying the project has moved on github. I'll ask.

PyExchange kicks ass but you should make it transport indepandant : some HTTP 
libraries like requests supports HTTP Digest authent with md5-sess, which 
exempt us to use python-ntlm

Original comment by deron...@gmail.com on 27 Nov 2014 at 4:20