Is this project dead? Please give us a proof of life scanny?

[andyr100]

This is a phenomenal project, it would be good to know if it is dead or not, so we can make other arrangements if needed

[ME-researchgroup]

Hope you're doing well @scanny. Could you please provide some clarity on the future of this project? A lot of people seem willing to help out.

[redsuperbat]

This library is really nice. 🙏
@scanny I'm also intrigued in knowing if you plan to continue this project. Seems like a lot of people want to help this project continue to grow 🌱

[flubshi]

It was already asked here: #870

Who is interested in maintaining the project? Maybe we can continue development in a GitHub organization. Is someone interested?

[sedrew]

@flubshi I am interested in the development of the project. I use a third of this project in my work. So, I created a fork of the project. Fixed bugs and added features. I still have one function local to change the visibility parameters of objects in the presentation. I will post it soon. https://github.com/sedrew/petpptx/releases/tag/v1.0.2b

[MartinPacker]

@sedrew, in principle I could allow md2pptx to use your fork as the "pptx" engine. I would guess my users could specify whether to try importing your module before falling back on @scanny's. (The default would be not to try to.)

Of course I would have to ensure md2pptx only used additional features if it had successfully imported petpptx. But then there aren't any additional features yet, are there?

[sedrew]

@MartinPacker There are not downgrade features in petpptx. Some open PR and Issue-resolve scanyI want to move my project. I have analyzed the forks of other contributions. Some fork provides a feature for adding and deleting columns. There are things related to optimization, but then me should abandon support for python 2.7

There is a small fix in petpptx

• Fix module 'collections' has no attribute 'Container' for latest python 3.10
• Add setter for font in Run

If there are suggestions for improving the pptx engine, I am glad to hear.

[MartinPacker]

@sedrew this is why I said "additional features". I'm only interested in your (or any) fork if it either adds features or fixes bugs.

[kascodeo]

Hi @MartinPacker, I had used this package in many projects till 2019. Recently encountered some errors only to find this project is not as active as before. Want to fix some bugs but realizing PRs may not be merged, I made a fork and uploaded package in python-pptx-fix. I will try to fix bugs as when i find time and may be add some minor features. If any one is willing to contribute they are more welcome!

[Dasc3er]

Hi all, what are your thoughts on creating a GitHub organization to manage the project?
Something similar was proposed in #870.

Creating an org would allow using a central fork to combine further development efforts, without risking blockers due to the owner not being responsive/focusing on the project. The only issue would be in finding people interested in maintaining the project overall and reviewing issues/PRs.
We could possibly contact owners of existing PRs and people writing about the status of this project in the issues.

[sedrew]

A good idea. I'm ready to join it. Let me know how you will create an organization

[kascodeo]

I am in too

[scanny]

I think a fork is the right approach. This limits risk for existing users and it minimizes the amount of "approval" you require to make changes. An organization seems like a good idea although I don't have a point of view on that.

A couple challenges you might want to be aware of.

1. "Good enough for my present purposes" is rarely good enough for shared software. Developing to solve the general case is (much) harder than adding some code that solves a particular problem or adds a single needed aspect of a general capability. In order to be "good" in the aspect of serving a general audience, the software needs to solve the general case.
2. An important class of bugs only appear at document open time and only in certain cases (repair-error bugs). These are difficult to debug and often occur long after the code is written. Prevention is the only remedy I've found effective for these.
3. The engineering rigor evident in this project is there for a reason. I (quickly) got tired of fixing bugs and unexpectedly breaking existing features when adding new ones. I concluded getting it right the first time was going to maximize the project velocity (even though each feature took longer) and minimize the time I spent in tasks I didn't care for. This rigor is essentially these three things:
   • Analysis and design (mostly) before implementation. Gathering the facts about the way PowerPoint works related to a particular feature and designing the API/interface elements to be added is more efficiently done up front. If you don't understand how it works, you'll end up discovering it the hard way during implementation and end up with rework or even a restart.
   • Acceptance tests are the primary regression indicator and drive test-driven development (outside in).
   • Unit tests exhaustively test all possible input/output cases and drive out low-level bugs.

While this rigor paid great dividends for me, it makes it much more work to add features, more than double I'd say. Also folks seem to struggle with analysis (describing the implementation in prose, technical writing essentially) and also struggle with testing. But without it I expect you'll find that you aren't able to get very far before the library becomes unreliable.

There is no shame in maintaining a private fork, that way you can pick and choose what features you add and when one of them breaks you have some familiarity with the implementation. Big plus is you don't have to worry about it breaking for anyone else.

In any case, I wish you good luck and am happy to consult on things as you go along. I won't be able to help you with things you can do for yourself, like researching the Microsoft API or the ISO spec, but if you want to understand how some aspect of the architecture works or why it was done that way I'll be happy to advise.

[kascodeo]

Hi @scanny, Thank you for your valuable inputs. I would also like to know if you were to write this library again what would be your approach. Would it be different or same. If it is different what could probably be it.

Regards,
@kascodeo

[scanny]

@kascodeo Turns out I have reason to use this library again in my current gig and will be adding some features and probably generally refreshing it as well, dropping Python 2.7 support, adding typing, that sort of thing.

This architecture is actually the third one I built. The first two were simpler to understand but turned out not to scale. So I don't think I'd make any fundamental changes there. I did have the idea to extract some of the common parts into separate libraries so they could be shared across python-docx and python-pptx, but never went very far with that. It would be challenging and also introducing cross-project coupling would be inconvenient when you wanted to make a breaking change.

A main common parts are the Open Packaging Convention (OPC) bits, so Package, Parts, Relationships, serializing and deserializing .pptx files (zip archives) etc. There's actually a python-opc project out there where I got part of the way.

The other part is DrawingML, so things like charts, text-boxes in docx, drawings somewhat like PowerPoint slides, some other things. That actually would be nice to have as a separate package if possible because charts are a lot of code and work and it would be nice to be able to add those to python-docx without rewriting all that code.