Future maintenance

[stefan6419846]

Thanks for your work on this fork, which seems to be the most active and up-to-date one.

Unfortunately, GitHub makes it hard to work with forks or even discover them as they usually are hidden in the search results and in-repository search for forks is not available. Additionally, while there is a package on PyPI, it is out-of-date and does not correspond to this repository directly.

What are your plans for the future of your fork? I considered working on an own fork to keep this package available for my use cases, but with your existing work this could become easier. What I am currently thinking of:

• Move development into the pdfrw organization.
• Perform a fresh import of your fork into this organization for future maintenance.
• Try to keep maintaining the original pdfrw package on PyPI.

[federicobond]

Hi Stefan, I am interested in volunteering to get this done too. The outline you propose looks like a good plan. Are you the owner of the pdfrw organization?

cc/ @sarnold

[federicobond]

We should aim to get the test suite running in CI too.

[stefan6419846]

Are you the owner of the pdfrw organization?

Yes, I am. For the time being, it just is a placeholder.

We should aim to get the test suite running in CI too.

It mostly does in this repository. Some tests have been disabled although, while they should be safe to enable as there is no visual difference (internal changes in reportlab for example).

[federicobond]

Pinging @t-houssian and @Lucas-C who might be interested in this too.

[Lucas-C]

Thanks for the ping :)

@MartinThoma may also be interested by the subject:
he is the maintainer of https://github.com/py-pdf/pypdf (formerly PyPDF2), and "currently helping to clean up the Python PDF ecosystem", to quote one of his recent emails 😊

Maybe the best option would be to maintain this package inside the https://github.com/py-pdf organization, which is already active?

[federicobond]

Maybe the best option would be to maintain this package inside the https://github.com/py-pdf organization, which is already active?

I think that's a great idea. It could bring greater visibility and increased collaboration between projects.

[t-houssian]

@federicobond Thanks for the ping as well! I sadly don't have the time currently to help out much on this but do think that what @Lucas-C has mentioned is a great idea. I used this fork in a project of mine called fillpdf (https://github.com/t-houssian/fillpdf). I released this fork because it was the best I could find to use in my project.

I created that fillpdf project because of how hard it was to work in the current pdf filling libraries so I think any clean up and making things more user friendly would be awesome. Feel free as well to add fillpdf to the ecosystem and use any of the code from it.

Best of luck y'all!

[MartinThoma]

Thanks for pinging me 🤗 Yes, I've spend quite some time since April 2022 in merging PyPDF2 back into pypdf + setting up CI/tests + docs + merging over 100 PRs + fixing several hundred issues. Now we have at least one other super active pypdf developer again and I hope that PyPDF3 / PyPDF4 developers and users will move back to pypdf 🤞

It seems to me that pdfrw is solving a sub-set of the problems that pypdf is solving. For this reason I would love if the two projects (and especially the developers around them) could converge. I approached Patrick Maupin in April 2022. Sadly I don't know pdfrw well enough to really judge if merging the two would be reasonably possible.

I was thinking that we might be able to define a "pypdf-core" which is similar to pdfrw, but nobody did any work in that direction so far. I'm also uncertain about which use-cases current pdfrw users actually have. Looking at SO, I'd rather recommend them to use pypdf.

Another activity besides blog posts + answering questions is nudging the fpdf / fpdf2 people to make their relationship clear to the community. @Lucas-C and me recently received a super nice e-mail by the original author; I'm in good hope here 🎉

pdfrw in the py-pdf GitHub organization

I'd be open to move pdfrw into the py-pdf GitHub organization. I would love an exchange between PDF-related projects / developers and sharing of issues/solutions/test cases.

The official git seems to be https://github.com/pmaupin/pdfrw / (1700 stars) whereas https://github.com/sarnold/pdfrw only has 24 stars. I'm interested in bringing the Python-PDF communities closer together, not in fracturing the communities even more. So I'd rather not move https://github.com/sarnold/pdfrw into py-pdf at this stage.

The pdfrw GitHub organization

What does https://github.com/pdfrw do? I don't see anything in there.

[federicobond]

Thank you for your input @MartinThoma, very appreciated!

It seems to me that pdfrw is solving a sub-set of the problems that pypdf is solving. For this reason I would love if the two projects (and especially the developers around them) could converge.

I agree this would be very desirable for the ecosystem.

I'm also uncertain about which use-cases current pdfrw users actually have. Looking at SO, I'd rather recommend them to use pypdf.

I can add my 2 cents here: we began using PyPDF a few years ago at our company to include a stamp on each page of some files that are uploaded to our system. Its performance was pretty bad: it took whole seconds and consumed quite a bit of memory to process moderately long files. We ended up switching to pdfrw and saw a huge improvement. This could no longer hold now, but pdfrw worked well enough for us and was easy to debug that we remained with it since.

I would love an exchange between PDF-related projects / developers and sharing of issues/solutions/test cases.

That would be awesome! Also increasing the bus factor for these projects.

The official git seems to be https://github.com/pmaupin/pdfrw / (1700 stars) whereas https://github.com/sarnold/pdfrw only has 24 stars.

I believe sarnold's fork is just pmaupin master + some small fixes/improvements, most of which we would need to land into master eventually (someone correct me if I'm wrong). Other than that, the projects haven't really diverged.

What does https://github.com/pdfrw do? I don't see anything in there.

I believe it's just @stefan6419846 squatting the name in case it was going to be used.

[Lucas-C]

I would love an exchange between PDF-related projects / developers and sharing of issues/solutions/test cases.

That would be awesome! Also increasing the bus factor for these projects.

I totally agree! 😊

In fact, maybe we could consider merging https://github.com/PyFPDF (which is mostly fpdf2) into https://github.com/py-pdf?
I'm all for joining efforts, and I'd be happy to help on other PDF libraries!

Would you be open to this @MartinThoma?
This is not the main topic here, but I use the opportunity to drop this idea 😋

Also, maybe at some point the org should have a code of conduct & some projects management guidelines?
I'm thinking about some basic directions on how to handle issues, reviews, releases, etc.

(edit:) I see that the only public member of the py-pdf org is Matthew Peveler: https://github.com/orgs/py-pdf/people
You are not a member of the org @MartinThoma?
Having public org membership, and being able to know clearly who has the rights to release new versions seems important to me 😊

[stefan6419846]

What does https://github.com/pdfrw do? I don't see anything in there.

I believe it's just @stefan6419846 squatting the name in case it was going to be used.

This is correct. I just created this organization to block the name when thinking about the future of the project and creating this issue as well. As responses have been quite sparse until yesterday (with my e-mails to Patrick and Steve being unanswered for nearly two months now as well), I did not yet take this further.

I am open to move this to the aforementioned py-pdf organization nevertheless.

I was thinking that we might be able to define a "pypdf-core" which is similar to pdfrw, but nobody did any work in that direction so far. I'm also uncertain about which use-cases current pdfrw users actually have. Looking at SO, I'd rather recommend them to use pypdf.

Speaking of my use-case: I mostly use pdfrw for working with PDF forms.

[MartinThoma]

In fact, maybe we could consider merging https://github.com/PyFPDF (which is mostly fpdf2) into https://github.com/py-pdf?
I'm all for joining efforts, and I'd be happy to help on other PDF libraries!

Sounds awesome to me! We should talk about permissions/expectations beforehand, though. I would suggest that you open an issue/discussion in https://github.com/PyFPDF/fpdf2 to discuss this :-)

The two roles I can give are:

I would make you @Lucas-C an owner of py-pdf, but would appreciate if we had a discussion before adding new owners (for members, I don't care too much)

Although owners have all permissions on all repositories, I would expect them/me not to interfere with them except if the repositories maintainer(s) are inactive for a long time (e.g. 3 months?) or if something security-critical happens (e.g. a dependency was introduced that is malicious/typo-squatting). As both, pypdf and fpdf are pretty big, we should write such things down within py-pdf (maybe make a github page at https://py-pdf.github.io/ )

[MartinThoma]

[pypdfs] performance was pretty bad: it took whole seconds and consumed quite a bit of memory to process moderately long files. We ended up switching to pdfrw and saw a huge improvement.

I've heard that before 🤔 When I have some time I need to create benchmarks + investigate that 🕵️

[Lucas-C]

would make you @Lucas-C an owner of py-pdf, but would appreciate if we had a discussion before adding new owners (for members, I don't care too much)

Although owners have all permissions on all repositories, I would expect them/me not to interfere with them except if the repositories maintainer(s) are inactive for a long time (e.g. 3 months?) or if something security-critical happens (e.g. a dependency was introduced that is malicious/typo-squatting). As both, pypdf and fpdf are pretty big, we should write such things down within py-pdf (maybe make a github page at py-pdf.github.io )

Sounds great to me! 😊
I'll open this issue during week, when I have some time available.

[brokenshield]

Hey, I'm just a user, but I know how hard it it to keep a project going, so from a user perspective: do what you got to do! Also: thank you for your continued work. It is appreciated.