who is maintaining this project?

nicolas33 commented 6 years ago

There's nobody in the public members of the imaplib2 org at https://github.com/orgs/imaplib2/people .

I'm wondering who is active at maintaining the source code. One person? A team ? There are currently 2 PR not addressed.

nicolas33 commented 6 years ago

BTW, is Piers still around?

davidben commented 6 years ago

@graingert ?

nicolas33 commented 5 years ago

We have no response for months. I think we can say that there's no active imaplib2 upstream anymore. This is a problem for the offlineimap project.

For the use of offlineimap I've applied the current pending PR #4 and #6. We have applied another change (see https://github.com/OfflineIMAP/offlineimap/pull/623).

IOW, I've decided to maintain imaplib2. However, there are 3 important limitations:

I intend to maintain imaplib2 for offlineimap only. Everything will take place in the offlineimap project. I'll neither package imaplib2 nor maintain any "official" repository dedicated to imaplib2. If you want imaplib2 but not offlineimap, you should extract the file offlineimap/bundled_imaplib2.py from the offlineimap repository. Please, send your patches for imaplib2.py to the offlineimap project directly.
Starting from imaplib2 v2.100 (tagged: imaplib2-v2.100) I'm taking the patches in the lazy mode. This means that I won't make deep checks/tests of the changes. Hence, the quality and the stability might become a bit more fluctuating. For more stability, you might like to only consider the imaplib2 versions released with the stable versions of offlineimap. Don't expect changelogs dedicated to imaplib2. They will be part of the offlineimap changelogs.
All of this applies to the py2 version of imaplib2 only. Sadly, offlineimap has few chances to be ported on py3 so I don't aim to maintain the py3 version of imaplib2.

I'll make the announce in the offlineimap community while releasing the next offlineimap version.

danespen commented 4 years ago

I wonder if you can help, I'm trying to locate a source repository for imaplib2. The version here is 2.45. Debian has a package called python3-imaplib2 that is version 3.05. So it looks like someone took over imaplib2 but I'm unhappy extracting the package from a .deb .

graingert commented 4 years ago

Hello, I'm still around

nicolas33 commented 4 years ago

I have no idea what is this v2.45 and where this comes from. I've released a v2.201 for offlineimap available here: https://github.com/OfflineIMAP/offlineimap/blob/master/offlineimap/bundled_imaplib2.py

nicolas33 commented 4 years ago

Hello, I'm still around

Hi @graingert

Do you still aim to maintain this project? It looks like people have forked imaplib2 during your offline time. Do you intend to merge this stuff at some point?

danespen commented 4 years ago

Well, sorry if I'm causing confusion, pretty sure i got 2.45 here, not from the oflineimap bundled version. I'm still confused about the Debian version. If someone associated with Debian made the python3 changes they should have at least contributed the changes back or set up a forked project somewhere.

I don't know if I'll ever release the project I'm doing but if I do, I'd like the libraries I'm using to be available.

danespen commented 4 years ago

I stopped using the 2.45 version, it had python3 issues and just plain didn't work for me. The 2.45 version installed in a 'imaplib2' directory with a initpy file and a imaplib2.py file in that folder. When I put an 'import imaplib2' in my code, nothing from imaplib2.py got into my program. I ran some traces and it looked like the 'import imaplib2' in the init.py failed. (I saw nothing in the trace). The only way that second import worked is when my current directory was the imaplib2 directory.

I did some reading but wasn't able to figure out how that is supposed to work. My program does 'import imaplib2', which brings in the init.py file which does exactly the same 'import imaplib2'. Why is the second import supposed to go somewhere else? In my case, it mostly didn't.

So, I was able to get that version to sort of work by discarding the imaplib2 directory and the init.py file.

I still had some python3 issues which I was able to code around but then I found python3-imaplib2. The python3 version is of course a DEB which doesn't do us Fedora users much good, I was able to extract the imaplib2.py file and use that. The Debian version doesn't use a subfolder or init.py.

graingert commented 4 years ago

I can hand the imaplib2 pypi name and github org over to anyone willing to maintain it

graingert commented 4 years ago

I was previously merging changes from the sourceforge repo

tari01 commented 4 years ago

@danespen look at the imaplib2.py and imaplib2.py3 files here in the repo. The Python 3 code is versioned to 3.05. If you intend to use it, you must apply these changes: https://github.com/imaplib2/imaplib2/pull/4/commits/786b2a4fb0d7acbcb3a5c5be9992c32540eaac65

danespen commented 4 years ago

Well thanks, I missed that. Actually, I think I dd my first install of imaplib2 using pip3. Not sure where that goes for code but it wouldn't use a py3 file (I don't think). So, it looks like the code is here, it's just well hidden.

nicolas33 commented 4 years ago

You might like to know that Piers wrote the python3 version shortly before retiring. We tried to use it in offlineimap while adding support for python3. It appeared that imaplib2 for python3 is not ready to use in production and has issues. I'd not expect this to be working without further developments.

danespen commented 4 years ago

Thanks for that. I'm still of a mind that I want some kind of python access to the IDLE extension. My existing app seemed to work with imaplib2. Is there an email thread about the problems?

I retired 4 years ago. Still like to dabble.

nicolas33 commented 4 years ago

There are some known issues tracked here: https://github.com/OfflineIMAP/offlineimap/labels/Py3 They might not all apply to imaplib2, of course.

chris001 commented 4 years ago

@tari01 Regarding https://github.com/imaplib2/imaplib2/commit/786b2a4fb0d7acbcb3a5c5be9992c32540eaac65 Is there any documentation or url explaining why when it was using threading.TIMEOUT_MAX (9,223,372,036,854.0 or 9.2 Trillion floating point or greater than 2^43 ) for the timeout parameter ? On which architectures does it fail? Why does it fail on those arch and not fail on others? Why not just use a threading.TIMEOUT_MAX value of of 2^32 (~4 billion) if it's caused by lack of 64 bit values on some arch?

tari01 commented 4 years ago

@chris001 I think you should ask @iliastsi about the details, he came up with the fix. All I know is imaplib2 doesn't work without it on 32-bit systems.

chris001 commented 4 years ago

Thanks. I think it would work fine if we reduce that large number threading.TIMEOUT_MAX to the largest INT or FLOAT available on a 32-bit system. What's your idea @iliastsi ?

thekix commented 3 years ago

Hello,

I have some comments. Are only my opinion:

The upstream and Debian/Fedora libraries should be the same. Now, in Debian (I am not sure about Fedora) the upstream and the deb-library are different. The difference is the pull requests are applied in Debian.
I think the library updates should be more dynamic. The last pull was some years ago.

Therefore, I would make this proposals:

About the pull request #5 IMO should be applied
About the pull request #4, IMO we should include a new internal variable _timeout with a default value (perhaps, no timeout like #4 or 2^32 like @chris001 said). Then include a method (we can use it before the get_response() call) to set the timeout, something like:

    def set_timeout(self, timeout):
        self._timeout = timeout

@iliastsi What do you think? Could you provide a new patch?

About the future, I would like to remove imaplib2 and merge the code with imaplib (stdlib). I would like to start including functions here (imaplib2) and send patches to stdlib.

@graingert What do you think? Could you update the repo? Do you need help?

Best regards, kix.

graingert commented 3 years ago

Merry Christmas. I was considering moving this repo into jazzband

nicolas33 commented 3 years ago

I was considering moving this repo into jazzband

Sorry, what does that mean?

graingert commented 3 years ago

It's the collective maintenance GitHub organisation @jazzband

bkircher commented 3 years ago

was considering moving this repo into jazzband

Anything is better than the status quo it seems. The state on PyPI is also heartbreaking: https://pypi.org/search/?q=imaplib2

Who is actually using imaplib2 besides offlineimap? imaplib2 is not packaged for Fedora. @thekix Are there any other packages in Debian that are dependent on imaplib2 you know of?

If offlineimap is really the only project using imaplib2, wouldn't github.com/OfflineIMAP organization be the natural new home?

graingert commented 3 years ago

@bkircher I've moved the repo to jazzband

graingert commented 3 years ago

closing in favour of #13

bkircher commented 3 years ago

Cool, thx!

jazzband / imaplib2

who is maintaining this project? #7