Very elegantly said, Lex. having multiple implementations is a good thing >
I absolutely agree. While I've certainly invested a lot of time and effort in Asciidoctor, I care about AsciiDoc the language (as well as the content written in it) just as much. And I believe a Python implementation is an important part of that story. I have no intention of keeping AsciiDoc coupled to a specific language platform (Ruby or otherwise). In fact, multiple compatible implementations can keep the language vibrant and evolving. I'm very excited about the journey ahead. The AsciiDoc community has a long and rich history, yet I hope it's just the beginning of a much longer one. It's a community I'm proud to be a part of. Best Regards, -Dan On Sat, Jan 5, 2019 at 2:49 AM Lex Trotman <[email protected]> wrote: > So to summarise: > > The current situation is that there are two versions of Asciidoc > Python, where the Python 3 is a port (ie a minimal set of changes) > from Python 2 to allow the project to continue past the EOL of > Python2. The Python 3 port is the way forward and I would not expect > much to change in the Python 2 implementation. Asciidoc Python is not > very "active", it is a volunteer project and contributions are welcome > for: > > - testing (there are proposed PRs available to test, hint hint) > - proposals for changes (such as adding functionality Asciidoctor has > added thus improving compatibility), and > - infrastructure (Eric has already kindly volunteered to help with the > website) > > There is another personal Python 3 port as well which (IIUC) was made > for the interest of the developer, who has noted that they can't offer > long term support, so it isn't the way ahead in its current form. It > also started badly because initially it illegally changed the license > of the files it copied from Asciidoc Python, which has made its > relationship with the rest of the community rather fraught, but > hopefully improving, as the developer has proposed adding their > improvements to Asciidoc Python 3 so only one version needs to be > supported. > > The most active Asciidoc implementation is Asciidoctor. It is a > separate greenfields implementation and not any sort of "port" of the > Python implementation. As such its internals are very different and > its mechanisms for extensions and configurations are different. > > It is implemented in a number of environments (Ruby, JVM, JS being the > main ones) and covers a wide range of use-cases and that means it > meets the needs of many people, but as noted in the thread, it doesn't > meet everybody's needs. Thats why having multiple implementations is a > good thing. Even though much more active than Asciidoc Python, > Asciidoctor is still resource limited so its not going to get a new > website every week. But Dan has noted that a new site is imminent. > > Asciidoc has traditionally had only one, or at least a leading > implementation, but the community acknowledges that to support > multiple implementations an implementation independent standard needs > to be defined for Asciidoc. That is proposed to be hosted under the > asciidoc.org URL with links to the various implementations which of > course will have their own sites and documentation. This work should > start this year if resources allow. > > A standard will of course define the language and allow for future > evolution in a controlled manner and allow for multiple > implementations that address various different use-cases. > > It is proposed that the standard be under asciidoc.org so it is > prominently the "reference" for the language, but that does mean some > changes to the current infrastructure of the asciidoc python project > that the asciidoc.org currently points to. As Dan has noted the > mechanism of creating the website for Asciidoc Python is not well > understood, and as its about to have a change now is a perfect time > for it to be updated and hopefully Erics expertise can extend to that > as well as tidying up the site, or others can help him. (on a > pragmatic note, PRs to Asciidoc Python 3 please). > > Dan has also noted that he is about to provide a proposal for the way > ahead that hopefully addresses this change process, so there will be > something more concrete to discuss soon. > > Finally a philosophical point if I may, these are fairly seismic > shifts, from one implementation to another leading to a standard with > multiple implementations. The Asciidoc community has so far traversed > the shifting landscapes in a fairly measured and friendly manner. We > have different backgrounds and expertise, and don't agree on > everything, and that might become more apparent as we move into the > next major change. But the fact that everybody is talking about it and > cooperating is a great example for other communities. > > Cheers > Lex > > -- > You received this message because you are subscribed to the Google Groups > "asciidoc" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/asciidoc. > For more options, visit https://groups.google.com/d/optout. > -- Dan Allen | @mojavelinux | https://twitter.com/mojavelinux -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/asciidoc. For more options, visit https://groups.google.com/d/optout.
