I decided to meditate for a few days rather than answer immediately and poorly.
After I took over maintenance of adodbapi in about 2003, I was struggling with how to properly document that most users (CPython) had to install pywin32 as a prerequisite. At that time the odbc sub-module had a couple of bugs, and ADO seemed to be all the future. Also pywin32's odbc module follows the api 1.0 version. I asked, and received a green light, to bundle adodbapi with pywin32. When you (Mark) gave that okay, you had one stipulation: that the module get "some support". During the last few years I have failed to provide that support. That fact causes me daily regret. I want the opportunity to correct my failure. I also want to enable someone else to be able to support the package should the need arise, like if I have a stroke or something. I have already survived cancer. I understand that pywin32 support is "largely" just you, but adodbapi support is _only_ just me -- a critical difference. Here is what I propose: 1) This time, rather than copy a selected (major) part of the adodbapi source files over to their pywin32 directory, I would copy _all_ of the files. 2) Adjust adodbapi/MANIFEST.in and setup.py to create a proper PyPi submission from that directory. 3) Adjust the pywin32 MANIFEST.in to include a subset of adodbapi files that actually works. 4) Put a simple go/no-go test of adodbapi (perhaps ACCESS database only) into the pywin32 test suite. 5) document in SourceForge that future updates will take place in the pywin32 repo. -- Vernon On Mon, Feb 26, 2018 at 5:53 PM, Mark Hammond <mhamm...@skippinet.com.au> wrote: > On 27/02/2018 5:40 am, Vernon D. Cole wrote: > >> Second: the effective "bus size" of the adodbapi repo is *one*. The other >> three authorized maintainers are inactive. Indeed, the way I got approved >> as a maintainer 15 years ago (has it really been that long?) was to >> document to SourceForge that the then-existing two maintainers were >> unresponsive. Moving the working source into the pywin32 repo would solve >> that problem. >> > > It's not immediately clear that it would though. pywin32 itself has the > exact same issue (ie, it's largely just me), and I don't use or know much > about adodbapi - so it seems somewhat likely you'd have the same "bus size" > - just on a different bus :) > > My research this morning suggests that by suitable editing of the >> MANIFEST.in file in the pywin32 root, and the /adodbapi/MANIFEST.in and >> ./setup.py we could effectively send two seemingly independent (but source >> locked) versions of adodbapi to PyPi. That should keep both >> CPython/pywin32 and IronPython use cases covered. Should I pursue that? >> > > When building pywin32 I don't send *any* versions of adodbapi to pypi, so > I'm really not sure what that means. I'm reluctant to agree that building > pywin32 will create many discrete wheels - I already need to upload wheels > for each python version supported and for 64 and 32 bits and making the > build and release process more convoluted doesn't sound like a win for me. > > So can you please explain in more detail what is being proposed here, and > why it would be preferred to splitting adodbapi into its own repo on > github, possibly including removal of it from pywin32 if the duplication > causes problems? > > Cheers, > > Mark > > -- >> Vernon >> >> >> I spent the morning reviewing the documentation for setuptools and wheels >> and such. >> >> >> >> On Sun, Feb 25, 2018 at 7:35 PM, Bob Kline <bkl...@rksystems.com <mailto: >> bkl...@rksystems.com>> wrote: >> >> On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond >> <mhamm...@skippinet.com.au <mailto:mhamm...@skippinet.com.au>> wrote: >> >> > 1) There's a relatively easy fix that can be made to the copy of >> adodbapi >> > which is inside pywin32. >> >> Right. Basically, I think what needs to happen is for the fork on >> GitHub to be brought in sync with the working code on SF. I'm going to >> guess it's not quite as simple as that, because we'd want to be >> careful to preserve any patches which got applied on GitHub, but >> didn't make it to the original repo. Don't know for sure that there >> are any, but we should check. >> >> > 2) There's a concern regarding some IronPython bindings for >> adodbapi which >> > aren't in pywin32 and Vernon was asking something whether they >> should also >> > be included in pywin32. >> >> As I understand it, the code to support IronPython is already included >> in what's on GitHub. I think Vernon's hoping that there's a way to >> script an export of just the adodbapi portion of your GitHub repo for >> the use of the IronPython users (who, as you correctly point out, have >> no use for the pywin32 bits). If that's possible (and I can't see why >> it wouldn't be, as GitHub is pretty easy to script), he would be able >> to avoid the tedium and risks involved in having to maintain the same >> code base in two different places. It would also eliminate the "where >> am I supposed to file bugs" confusion, as well as make it easier to >> persuade others to assist with maintenance of the code. Most of the >> adodbapi code is common for IronPython and CPython users, and I don't >> see that the presence of "if IronPython: ..." code in the >> mhammond/pywin32 repo does any harm (after all, it's already there and >> I'll bet no one has noticed). >> >> I hope that makes things a little clearer. But this explanation is >> speculation on my part, and I should really let Vernon say what he >> means for #2. >> >> Regards, >> Bob >> >> >> >
_______________________________________________ python-win32 mailing list python-win32@python.org https://mail.python.org/mailman/listinfo/python-win32
