On Mon, Dec 21, 2015 at 6:33 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 21 December 2015 at 15:19, Toshio Kuratomi <a.bad...@gmail.com> wrote: > > On Sun, Dec 20, 2015 at 01:29:10PM -0500, Ben Rosser wrote: > >> > >> What's the right thing to do here? Replace pdfminer? Ship > python3-pdfminer-six, > >> have it provide python3-pdfminer, and keep using the original package > for > >> Python 2? Do nothing, and wait and see what happens upstream? > >> > > It's a tough thing to decide as there's many unanswerable questions -- > will > > the pdfminer upstream change their mind about having dual py2 and py3 > > compat? Will pdfminer.six development tail off and die? You can't > predict > > the future so anything has some risk of backing the wrong horse. > > > > Luckily, if circumstances change with the upstreams we can always change > our > > minds about what the right thing to do is. If you are worried about > that, > > I think implementing a plan that makes it as easy as possible to change > > which fork we're packaging and promoting later is optimal. So keeping > the > > python-pdfminer package name but packaging the source for pdfminer-six > seems > > to make sense to me. That way, as long as they stay API compatible, > > packagers of dependent packages don't have to do anything if you have to > > switch from one upstream fork to another. > > +1 from me for this approach - since you're tackling this as the > current maintainer of python-pdfminer, it's your call as to which > upstream project that distro package actually represents. > > With the pdfminer-six upstream package aiming to be "like PDF miner, > only with Python 3 support", originally based on a pull request > against the pdfminer code, and everything licensed under MIT/X, it > makes a lot more sense to go down than path than it does to either: > > * carry the Python 3 support as a downstream patch; or > * expose the upstream complexity to downstream users > > As Toshio notes, it's also possible that if the pdfminer.six fork sees > sufficient interest, the original pdfminer maintainer may reconsider > their willingness to accept the additional code complexity back into > the main project. > > Cheers, > Nick. > > Makes sense to me. I guess I will take that route, then, and push an update to the current pdfminer package for Rawhide that switches over to using the pdfminer-six sources. Thanks for the feedback, everyone! Ben Rosser
_______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
