dead project?

[pythonmobile]

The last update on pypy was in 2010. Are there any plans for a new version -- at least bug fixes?

[willnorris]

it's certainly true that there isn't really any active development. @rodrigoprimo stepped up recently to merge a number of outstanding pull requests, but aside from his work the project is without an active maintainer. Rodrigo, did we ever sort out what is needed to push a new version to PyPI?

[pythonmobile]

Thanks @rodrigoprimo - I hope python-openid can be updated soon on pypy.

[rodrigoprimo]

Hi @pythonmobile and @willnorris,

So far I have approved two pull requests which I did myself. After that I discovered that only the first test file was being called by run_tests.sh (see commit f8e8e8f).

Because of that, I noticed that several tests are broken. Most of them are errors due to import problems that might be easy to fix. Others were broken after one of my pull requests (#58) and I don't know the OpenID protocol well enough to tell if the problem is the tests or the changes.

Right now I would like to focus on fixing the broken tests before updating the package on pypy or analysing the other pending pull requests. However I don't have much time available to do this and it might take me a few weeks or even months.

Any help is appreciated.

[dairiki]

I've started looking at the failing tests. I've fixed a couple of the easier cases at #64.

The problem with at least some of the remaining broken test modules seems to be that they are written in a somewhat archaic/hokey manner to be run only using the script in admin/runtests. They fail when run under nose. These are generally cases where test parameters are read from a data file and then test cases are generated programatically. I don't think there is a clean, test-framework-neutral way to do this sort of thing. Nose has its own way to do it, as does the new unittest module (in python 2.7, or unittest2 for older pythons).

(See test_urinorm.py for any example of what I'm referring to.)

What is the official test framework for the project, at this point?

If it is nose, I can convert the pyUnitTests stuff to nose-specific stuff. The parametrized tests would be implemented using test generators.

If it is the custom admin/runtests script, I guess we can keep going down that road.

My personal preference would be to use the new unittest/unittest2. This minimizes dependencies, and is I think the easiest way to make python setup.py test "just work" to run the tests. (In this case the pyUnitTests functions to load the parametrized test suites would be replaced by a load_tests function.)

Edited for clarity, 2013-07-12T21:50Z.

[rodrigoprimo]

Hi @dairiki,

Thanks for fixing some of the tests. I have approved your pull request. I'm new to the python-openid project and Python is not my main language so unfortunately I can't be of much help.

@willnorris added me to this project because no one was maintaining it and I was asking him about two pull requests I had sent.

Regarding which test framework to use, I choose nose to show that the some tests are broken simply because it was already included in the environment created for travis-ci (see https://github.com/openid/python-openid/blob/master/.travis.yml) so I thought this was the framework used for the project.

I found an e-mail @willnorris sent to the OpenID code mailing list in 2010 asking for help to fix and improve the test suite (http://lists.openid.net/pipermail/openid-code/2010-July/000135.html) but no one answered.

So, if there are no objections, I suggest that we choose and use whatever framework those that are involved in the project now are more familiar with (unittest/unitest2).

[ghost]

The project is dead?

[willnorris]

My initial comment above still holds true... the project is without an active maintainer.

[flying-sheep]

the python3-openid project isn’t though, so you could simply give its author commit rights here and let him update this with his fixes

[willnorris]

Sure, if the python3-openid authors are interested, I can add them here.

[flying-sheep]

hi @necaris, are you?

[ziima]

Hi, I've been putting the library together in my fork for some time now. I'd be glad to upload the changes into upstream and it looks like, I'll be able to maintain the library for a while, since I'm going for Python2/3 support.

[necaris]

@ziima Are you using https://github.com/necaris/python3-openid as the basis for Python 3 support? I'd be happy to merge that in here and help with maintenance.

[necaris]

@willnorris @flying-sheep are you able to give me / @ziima the ability to upload new versions to PyPI?

[ziima]

@necaris: Hi, I'm not. I looked at it, but it contained too many commits for me to be able to cherry-pick any of those. I started with cleanup of the library itself before I can add Python 3 support. Anyhow, if you can provide a pull requests towards the Python 3 support, you might save me some work :)

[necaris]

@ziima In the process of making it Python-3 compatible some cleanup had to occur, so that is included in python3-openid. I am not very excited to rebase all that work on top of yours, though.

Conversely, I have an issue open for Python 2.7 support, so if you were willing to help with that, we could converge there.

[ziima]

@necaris: I'm not very excited to return Python2.7 support into a project which already dropped it either. Still hope, we can figure something out.

[necaris]

@ziima Indeed, it seems like a step backwards to add Python2 support.

[flying-sheep]

it’s possible to make a clean switch, so that python 2 users still get the latest python2-supporting version when pip installing: https://stackoverflow.com/questions/40114100/uploading-different-versions-python-2-7-vs-3-5-to-pypi

if the current version gets a Requires-Python: 2.7 field and the replacement gets Requires-Python: >=3.5 or so, everyone is happy.

together with a major version change, API breakage will also not confuse anyone.

[necaris]

@flying-sheep since python3-openid doesn't support Python 2, that seems like it would mean:

• a new PyPI release from here, with the appropriate Requires statements in setup.py
• merging upstream Python 3 support, from @ziima's work or mine or both, as a new major version
• a new release as the Python 3-only version
• only supporting Python 3 going forward for the new version (after all, it's 2018) but possibly backporting cleanups to the older version branch

Does that sound right? Is that acceptable to all? If so, I'm 👍 and happy to help with it, if I can get access to this and the PyPI credentials as well.

[ziima]

I'm not sure python3-openid keeps the API. I had to add some backward compatibility into master to match API in 2.2.5.

[necaris]

There are some API differences in python3-openid, that's true -- partly because Python 3 and Python 2.3 (as supported by this package) are really not compatible, but also partly because I haven't made a concerted effort to match any recent updates.

[willnorris]

@willnorris @flying-sheep are you able to give me / @ziima the ability to upload new versions to PyPI?

I no longer have access to the OpenID org on GitHub, and don't think I ever had access to the PyPI package, so am not going to be able to help here. Sorry.

[flying-sheep]

and i never had anything of the like, sorry!

[necaris]

On Sun, Jan 28, 2018 at 10:56:52AM +0000, Philipp A. wrote: and i never had anything of the like, sorry!

So it sounds like we couldn't replace the existing PyPI package even if we wanted to! Since that's the case, I will probably be keeping my package Python 3 only unless I get help backporting it!

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #62 (comment)

[flying-sheep]

we can file a request to pypi to take it over.

that happened with tqdm as well.

[ziima]

I don't think Pypi have any procedure to take over a project. They're super cautious after what happened with django-registration and I don't think they'll give access to anybody on any project anytime soon.

[flying-sheep]

as said: when the tqdm community recognized that the project owner didn’t react anymore, they asked to take over, created a community project and it became upstream tqdm.

[willnorris]

@tnarg: are you "tnarg" on PyPI as well? If so, it looks like you're the owner of record of the python-openid package. Could you help some of the folks here gain access to that so they can update it.

You all may also need to talk to someone at the OpenID Foundation about taking over maintenance of the GitHub repo as well, since I don't know anymore who has access to it. There used to be a code@openid.net mailing list, though I don't know if it's active anymore.

[necaris]

@tnarg: any chance you can help here?

[ziima]

Hi guys, I've just released python-openid2 2.3.0 https://pypi.org/project/python-openid2/

Python3 support should be available soon.

[ziima]

I've released python-openid2 3.0 with python3 support and as much compatibility with python-openid as possible.

[hugovk]

@ziima It's now possible to request the transfer of the PyPI name for an abandoned project via PEP 541. See:

• https://www.python.org/dev/peps/pep-0541/#abandoned-projects

And file an issue here:

• https://github.com/pypa/pypi-support/issues/new?template=pep541-request.md

After a decade of no releases, I think it might be a good idea to transfer python-openid for your fork.

[necaris]

👍 thanks for the info @hugovk ! @ziima's fork since it maintains Python 2 compatibility is probably a better option than python3-openid but I think either is better than an untouched project.

[ziima]

@hugovk: Transfer is already in process pypi/support#496 I'm waiting for it to be finished.

[ziima]

Transfer complete. I'll try to transfer python-openid2 to python-openid is a reasonable time.