Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the maintainer's vision for asciidoc-py? #84

Closed
MasterOdin opened this issue Oct 30, 2019 · 7 comments
Closed

What is the maintainer's vision for asciidoc-py? #84

MasterOdin opened this issue Oct 30, 2019 · 7 comments

Comments

@MasterOdin
Copy link
Collaborator

@MasterOdin MasterOdin commented Oct 30, 2019

Watching the discussion going on in https://groups.google.com/forum/#!topic/asciidoc/GAk4b_VUmHc, one of the posters repeatedly said that the python implementation is not actively maintained or developed. Given that no one tried to say otherwise, it makes me wonder where the maintainer(s) (just @elextr these days?) of the asciidoc python implementation would like to take this project, or their vision of its future. Is this project truly considered dead and should the README just indicate that and point everyone to asciidoctor and these repos/organization archived? Should anyone interested in actually working on a python implementation just make a fork of the project and work on that (a la asciidoc3)? Just keep making PRs to throw into the void to hopefully see a python3 version formally released?

For my part, I would contribute more to this project, but I'm greatly discouraged on spending time on this when I see some of my PRs languish for upwards of 6 months with zero motion. I realize that time is not free for anyone, nor are maintainers required to devote their lives to the project, and I would just like to establish some sort of concrete idea of direction and it really is not clear to me.

@elextr

This comment has been minimized.

Copy link
Contributor

@elextr elextr commented Oct 31, 2019

The project is an open source volunteer contributed project. So really the vision for the project is whatever people make it. If people want to contribute and move it forward it will happen.

When Stuart retired from the project I offered to check and merge PRs but noted that I didn't have time for any pro-active development on this project. Unfortunately a combination of "real life" and working on something else has meant I am now having even less time, as you have noticed. I am however reluctant to merge stuff without testing it.

but I'm greatly discouraged on spending time on this when I see some of my PRs languish for upwards of 6 months with zero motion.

I can only apologise, and emphasise that its not any reflection on the quality of your work, so I have invited you to this repository as a collaborator so you can merge stuff yourself. Obviously it would be good for you to have others test and check stuff if they are available.

The following is purely my own opinion, and you may disagree.

Not everyone is happy to use the Asciidoctor Ruby implementation, an example I am aware of is kernel developers, since they have built their system themselves they already have Python which is needed to build the kernel IIUC, but they can't just "grab Ruby from the distro" to run Asciidoctor since there isn't any distro. There are also other places where Python is available, but not Ruby, so a Python implementation is a good thing.

Also for anyone who has invested in specific customisation of the Python version thats not portable to Asciidoctor, and unlikely to any other future implementation. On the other hand we havn't heard anything much from them, so I would suspect either they have transitioned, or have taken to local maintenance without offering back, and I don't care much about their needs in that case.

From a technical point of view the current Asciidoc Python implementation has some real restrictions due to being a streaming converter, the amount of context it maintains is minimal, and it can't go back and insert anything at the start of the output based on later content (which is why TOCs are done in browser by javascript). Streaming conversion was a good idea back when memory was tight, but any recent machine is likely to have enough to handle all of war and peace in memory, several times over, so its less useful now.

So some major surgery is needed to move the current implementation forward in my opinion. However its possible that may be able to be performed incrementally.

@MasterOdin

This comment has been minimized.

Copy link
Collaborator Author

@MasterOdin MasterOdin commented Oct 31, 2019

I can only apologise, and emphasise that its not any reflection on the quality of your work, so I have invited you to this repository as a collaborator so you can merge stuff yourself. Obviously it would be good for you to have others test and check stuff if they are available.

I appreciate that, and figured it was a time commitments elsewhere more so than anything else. As for the testing bit, I agree, though I think getting Travis-CI up (can you please activate travis-ci.com for this repo @elextr?) and running with the PRs that ensure a proper baseline test suite is constantly running for testing will go a long way to ensure no compliance breaks with changes, though most of my focus at the moment will be on just ripping out the aap with make based implementation.

From a technical point of view the current Asciidoc Python implementation has some real restrictions due to being a streaming converter, the amount of context it maintains is minimal, and it can't go back and insert anything at the start of the output based on later content (which is why TOCs are done in browser by javascript). Streaming conversion was a good idea back when memory was tight, but any recent machine is likely to have enough to handle all of war and peace in memory, several times over, so its less useful now.

So some major surgery is needed to move the current implementation forward in my opinion. However its possible that may be able to be performed incrementally.

I would agree there are definite steps that the implementation can make incrementally towards a better implementation. Removing the global state usage, get rid of the recursive subprocess calls to asciidoc (as you note, streaming is no longer really necessary), etc. will go I think a long way. Can also continue to modernize the codebase where it languishes in 2.4 standards.

@elextr

This comment has been minimized.

Copy link
Contributor

@elextr elextr commented Oct 31, 2019

can you please activate travis-ci.com for this repo @elextr?

I thought it was activated on all asciidoc organisation, maybe it needs more, will investigate

@hoadlck

This comment has been minimized.

Copy link

@hoadlck hoadlck commented Oct 31, 2019

While I agree there are many things that can be done to improve AsciiDoc going forward, there has already been many improvements. The port to Python 3 is something that many people will be able to get some good out of. Not to mention to changes in #57 so that AsciiDoc behaves like a normal Python package.

But, I think that it would help to get some release (even a release candidate) out there. I know that I have been hesitant to pick up the later version as there is no tag. I don't feel comfortable saying that I am using the version with the commit SHA "544574e66ca89c898151c1c6d34b88a76e44343f". Even though I have tried it out in tests, and it works properly for all of my requirements.

There is nothing like a release to get engagement. How about 9.0.0.rc1?

@MasterOdin

This comment has been minimized.

Copy link
Collaborator Author

@MasterOdin MasterOdin commented Oct 31, 2019

@elextr For travis-ci.org (what asciidoc/asciidoc used), you would need to go to https://travis-ci.org/organizations/asciidoc/repositories and toggle it on. For travis-ci.com (which is the recommended way to run Travis now), you can activate it repository wide (by going to https://travis-ci.com/organizations/asciidoc/repositories and hitting the "Activate" button which will take you back to GitHub where you can activate it for entire org or specific repositories).

@MasterOdin

This comment has been minimized.

Copy link
Collaborator Author

@MasterOdin MasterOdin commented Nov 6, 2019

@elextr, any chance you would be able to spend a minute or two getting Travis up? I'd greatly appreciate having CI in-place before even thinking about tagging a 9.0.0.rc1 release.

@elextr

This comment has been minimized.

Copy link
Contributor

@elextr elextr commented Nov 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.