On Mon, Dec 21, 2015 at 6:33 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 21 December 2015 at 15:19, Toshio Kuratomi <a.badger@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