Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
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
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
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
I would love to see this.
Original issue reported on code.google.com by
matt.hickford
on 5 Feb 2014 at 3:02