python 3 port of asciidoc
zaxebo1 opened this issue · 61 comments
I tried to run asciidoc on python3.4 , it failed
But it ran successfully on python 2.7
If it does not run on python 3.x , then is there any timeline/roadmap that it will be ported to python 3.x ???
I think that the port to Python 3 just requires community help. The steps to get it to work have been itemized several times, but no one as of yet has taken the time to create a PR.
See:
On 13 July 2015 at 10:44, zaxebo1 notifications@github.com wrote:
I tried to run asciidoc on python3.4 , it failed
But it ran successfully on python 2.7
If it does not run on python 3.x , then is there any timeline/roadmap that
it will be ported to python 3.x ???
The asciidoc python implementation is Python 2 only. There is currently
nobody working on a port to Python 3 that I am aware of.
Cheers
Lex
—
Reply to this email directly or view it on GitHub
asciidoc-py/asciidoc-py#83.
@mojavelinux:
oops, that was very fast answer. You are really active in asciidoc-python too(apart from the awesome asciidoctor). Kudos to your hard work 👍
It's safe to say that if it has to do with AsciiDoc, I'm probably paying attention to it :) I'm also trying to keep a handle on my inbox, so I've been staying on top of notifications lately.
I absolutely see an AsciiDoc Python 3 project emerging eventually that's a rewrite based on what we've learned in Asciidoctor. I don't think AsciiDoc should be tied to a specific language or platform. While Asciidoctor is available for Ruby, JavaScript and the JVM, a Python implementation would be a separate initiative.
In the interim, I think it's reasonable that AsciiDoc Python can be "upgraded" to work with Python 3 without any changes to the implementation.
I absolutely see an AsciiDoc Python 3 project emerging eventually that's a rewrite based on what we've learned in Asciidoctor.
I think in few days I will announce humble donation/sponsorship of- (1) either asciidoc-python port from python2 to python3 OR (2) for completion of asciidoctor-latex backend. Don't know if anybody will take that within a definite timeframe . And i don't know, which one of these two to sponsor/donate first.
I don't think AsciiDoc should be tied to a specific language or platform.
hypothetically if somebody were to write asciidoc implementation from scratch, then the ideal language will be haxe (http://haxe.org) for implementing it .
If we write a program in haxe, then i can get that program compiled to PHP, python3, java,C#, nodejs, C++ - all from single source code. Then we get ultimate deployment . Companies working on any language/VM can deploy it . Just thinking!
http://haxe.org/documentation/introduction/compiler-targets.html
https://en.wikipedia.org/wiki/HaXe
https://groups.google.com/forum/#!forum/haxelang
Paulfitz had even started haxe to ruby compiler ( https://github.com/paulfitz/haxe ), but it is not mature and official.
But still Haxe language with the official targets is very much used by game developers and also by myself to write Utilities. It is quite stable and mature and has good community. When i want to deploy on python, but i want type safety by compiler, then Haxe is ultimate choice too.
On 13 July 2015 at 11:09, Dan Allen notifications@github.com wrote:
It's safe to say that if it has to do with AsciiDoc, I'm probably paying
attention to it :) I'm also trying to keep a handle on my inbox, so I've
been staying on top of notifications lately.I absolutely see an AsciiDoc Python 3 project emerging eventually that's a
rewrite based on what we've learned in Asciidoctor. I don't think AsciiDoc
should be tied to a specific language or platform. While Asciidoctor is
available for Ruby, JavaScript and the JVM, a Python implementation would
be a separate initiative.
I agree with Dan that AsciiDoc Python needs to be re-designed, the current
streaming design was good back in the days of small computers, but now that
War and Peace will fit in memory several times over it has become a
hindrance to doing some of the great things Asciidoctor is pioneering.
In the interim, I think it's reasonable that AsciiDoc Python can be
"upgraded" to work with Python 3 without any changes to the implementation.
It is possible, but I think it is still hard to see why you would do it,
unless someone really didn't have access to Python 2. Python 2 has no
end-of-life yet, and there are alternative implementations such as
IronPython which has only been at 2.7 for six months and Jython at 2.7 for
two months. Neither of those has a Python 3 implementation, and I
understand from Stuart that there are users of Asciidoc on Jython.
Cheers
Lex
—
Reply to this email directly or view it on GitHub
asciidoc-py/asciidoc-py#83 (comment).
(continuing on to my own previous comment, and just for the sake of serving as a future reference (in hypothetical case of a asciidoc rewrite emerging), I am giving this example below:)
as a simple example: daff tool ( https://github.com/paulfitz/daff ) has been written in haxe language. From this one source code in haxe, he has compiled the source code to the following platforms:
a) compiled it to pure "python" and offering the installation of daff by "pip"
b) compiled it to pure "php" and offering the installation of daff by "Composer"
c) compiled it to pure "ruby" and offering the installation of daff by "gem"
d) compiled it to pure "javascript-nodejs" and offering the installation of daff by "npm"
....
In the same way as example above^ , anybody in future undertaking to write asciidoc from scratch may consider to rewrite it in haxe language for once, and get it compiled maturely to various languages/VMs : PHP, python3, java, C#, nodejs, C++ - all from single source code.
Various unofficial attempts to write compilers from Haxe to >> lua, rust (from Mozilla), ruby, C , Swift language(from Apple),LLVM .... are in various infant stages. So your same haxe source code can be in future automatically be compiled/compatible to other platforms/language/VMs
Hi, I am new here. Reading all above, is there any concentrated effort to implement Python 3 version of asciidoc.py? I am personally interested in the result, and I can occasionally help with the implementation. Is there any big picture of the asciidoc.py design?
I did try both asciidoc.py and AsciiDoctor (Ruby). Actually, I like both but I am not fluent in Ruby. In my opinion, it would not be bad to follow similar design both in AsciiDoctor and AsciiDoc projects. In my opinion, both projects could benefit and live together. As a result, the AsciiDoc format would become stroger as a de facto standard.
The situation is still as I commented above, nobody is doing any porting of the existing Asciidoc to Python 3 that I am aware of, nor am I aware of anybody considering a re-design in Python3 or any other language.
I'm not sure what design docs asciidoctor has, but asciidoc has none, so there is no "big picture" design of the implementations.
For the asciidoc language, there was a thought of making efforts to standardize it, to remove any artifacts of particular implementations, but I don't think it has progressed much due to time restrictions of all interested parties.
Hi elextr,
I have forked the repository and created py3dev branch for the experiments (see https://github.com/pepr/asciidoc.git). Thinking more about it, I have chosen a kind of pragmatic/experimental approach:
asciidoc.pycopied toasciidoc3.pyand converted by 2to3- manually fixed some extra
list()wrappers and some false replacements - new
xopen()function used to replace the built-inopen() - functions for encoding/decoding removed
- Reader1, and Writer classes modified
- the approach to BOM changed
Just now, it can process some sources to produce HTML. Anyway, it is definitely not ready to be used. I will work more on it. The next step is to fix everything related to encodings.
After fixing the big bugs, I plan to modify the asciidocapi.py so that it could be used both from Python 2 and Python 3. Testing the Python version, it will use or asciidoc.py, or asciidoc3.py.
Neat, good to see someone start the process. I havn't time to look at
anything in detail, but some comments below.
On 17 September 2015 at 16:39, Petr Prikryl notifications@github.com
wrote:
Hi elextr,
I have forked the repository and created py3dev branch for the
experiments (see https://github.com/pepr/asciidoc.git). Thinking more
about it, I have chosen a kind of pragmatic/experimental approach:
- asciidoc.py copied to asciidoc3.py and converted ty 2to3
- manually fixed some extra list() wrappers and some false replacements
- new xopen() function used to replace the built-in open()
- functions for encoding/decoding removed
I can't see where you handle the {encoding} attribute?
- Reader1, and Writer classes modified
- the approach to BOM changed
Just now, it can process some sources to produce HTML. Anyway, it is
definitely not ready to be used. I will work more on it. The next step is
to fix everything related to encodings.Ok I guess thats where you put the {encoding} handling back in :)
After fixing the big bugs, I plan to modify the asciidocapi.py so that it
could be used both from Python 2 and Python 3. Testing the Python version,
it will use or asciidoc.py, or asciidoc3.py.One thing that you will have to look at is the regexes in both code and
config files, its mixed if they are marked unicode, and some of those not
marked unicode might need checking that they still do the same thing,
since unicode is universal now.
And ensure the re.L locale flag is never turned on (its deprecated in 3.5
and going (about time, worst idea ever) in 3.6).
A good idea would be to generate the test suite results with a clean
asciidoc master and use that to check the python 3 version.
Not sure what a2x and the filters need beyond 2to3, I guess its try it and
see :)
Cheers
Lex
—
Reply to this email directly or view it on GitHub
asciidoc-py/asciidoc-py#83 (comment).
I can't see where you handle the {encoding} attribute?
I have put back the {encoding} handling (into xopen()), but I did not test it (having no sources). What is clear that the explicit encoding is known only after reading it from header. This way, I have to modify reading the files. This will be a problem to be solved especially when the title contains non UTF-8 sequences (because the :encoding: is placed after the title). I would appreciate some help with tests. I have no experience with the tests/testasciidoc.py framework.
After fixing the big bugs, I plan to modify the asciidocapi.py so that it
could be used both from Python 2 and Python 3. Testing the Python version,
it will use or asciidoc.py, or asciidoc3.py.
So far, I have added only the asciidocapi3.py -- partly modified, Version class tested, but the other things do not work.
> One thing that you will have to look at is the regexes in both code and config files, its mixed if they are marked unicode, and some of those not marked unicode might need checking that they still do the same thing, since unicode is universal now.
All files are open in the text mode now. (The files with the explicit encoding must be solved -- see above.)
And ensure the re.L locale flag is never turned on (its deprecated in 3.5 and going (about time, worst idea ever) in 3.6).
I am not sure what do you mean by that.
> A good idea would be to generate the test suite results with a clean
asciidoc master and use that to check the python 3 version.
Yes. I would appreciate some help here. The tests should be shared by both versions.
> Not sure what a2x and the filters need beyond 2to3, I guess its try it and see :)
Later ;)
Hi everyone,
Two new developers wrote me via Czech Python Users mailing list, so it is likely they are willing to participate.
I do not have a big experience with open source development in teams, but I feel we should find a better communication media or form than just this issue thread. Can you suggest some that would be mentioned here or in the README to be found by everyone who may be interested?
I also suggest to join the effort with AsciiDoctor team (probably through @mojavelinux). I guess it would be good for both Python and Ruby implementation, and some things can be discussed in concert to make the AsciiDoc format more standard and widespread.
So, where and how to communicate? I think it should not be underestimated.
Regards,
Petr
On 17 September 2015 at 20:22, Petr Prikryl notifications@github.com
wrote:
I can't see where you handle the {encoding} attribute?
I have put back the {encoding} handling (into xopen()), but I did not
test it (having no sources). What is clear that the explicit encoding is
known only after reading it from header. This way, I have to modify reading
the files. This will be a problem to be solved especially when the title
contains non UTF-8 sequences (because the :encoding: is placed after the
title).
Havn't tried, but I think a partly read file can be passed to a
codecs.streamreader, so if you start reading the file using a
codecs.streamreader for utf-8-sig
and after detecting the :encoding: line pass the partly read file to a
streamreader for the specified codec to read the rest of the file it might
work. The docs require all text before and including the :encoding: line
to be ascii.
I would appreciate some help with tests. I have no experience with the
tests/testasciidoc.py framework.
Afraid all I can do is point you to the docs
http://asciidoc.org/testasciidoc.html.
After fixing the big bugs, I plan to modify the asciidocapi.py so that it
could be used both from Python 2 and Python 3. Testing the Python version,
it will use or asciidoc.py, or asciidoc3.py.So far, I have added only the asciidocapi3.py -- partly modified, Version
class tested, but the other things do not work.> One thing that you will have to look at is the regexes in both code and
config files, its mixed if they are marked unicode, and some of those not
marked unicode might need checking that they still do the same thing, since
unicode is universal now.All files are open in the text mode now. (The files with the explicit
encoding must be solved -- see above.)
What I mean is that much of Asciidoc is done using regexes, most from the
config files, a few in the code, some were marked to use Unicode matches,
but some were not. Since Python 3 all regexes are Unicode so those that
were not marked as such should be checked that they still match the same
thing. For example does a \s explicitly mean Ascii whitespace or is it ok
for it to match Unicode whitespace? If its not OK the regex needs to be
marked as Ascii or the pattern adjusted to be explicitly [ \t\v\r\n\f].
And ensure the re.L locale flag is never turned on (its deprecated in 3.5
and going (about time, worst idea ever) in 3.6).I am not sure what do you mean by that.
I don't think it is on by default, but I just mentioned it so you avoided
using the locale flag.> A good idea would be to generate the test suite results with a clean
asciidoc master and use that to check the python 3 version.
Yes. I would appreciate some help here. The tests should be shared by both
versions.> Not sure what a2x and the filters need beyond 2to3, I guess its try it
and see :)Later ;)
—
Reply to this email directly or view it on GitHub
asciidoc-py/asciidoc-py#83 (comment).
On 17 September 2015 at 21:52, Petr Prikryl notifications@github.com
wrote:
Hi everyone,
Possibly two new developers wrote me via Czech Python Users mailing list,
so it is likely they are willing to participate.I do not have a big experience with open source development in teams, but
I feel we should find a better communication media or form than just this
issue thread. Can you suggest some that would be mentioned here or in the
README to be found by everyone who may be interested?
The best would be to use github, if you allow comments and issues on your
fork would be a start.
I also suggest to join the effort with AsciiDoctor team (probably through
@mojavelinux https://github.com/mojavelinux). I guess it would be good
for both Python and Ruby implementation, and some things can be discussed
in concert to make the AsciiDoc format more standard and widespread.Ask, but I don't know how much time Dan has for actual work.
As for standardization of Asciidoc the markup (as distinct from
Asciidoc(tor) the implementations), Asciidoctor so far has been careful to
ensure old documents will still process without changes, documents have a
long lifetime. Of course new features will require changes in the document.
I would suggest that if you feel the need to make a Python 3 port of the
current Asciidoc then get that working first. Then consider the additional
features.
But the way the current Python Asciidoc is implemented has severe
limitations for the long term, and from my first look will make adding some
of the new Asciidoctor features difficult. So in the long term the Python
implementation needs a re-design, probably more like the approach I
understand that asciidoctor uses., and it may even be possible to make the
configuration files compatible.
So, where and how to communicate? I think it should not be underestimated.
As I said above, enable issues, pull requests and comments on your github
fork as a first pass, that allows contributors to provide input to the
process.
Cheers
Lex
Regards,
Petr
—
Reply to this email directly or view it on GitHub
asciidoc-py/asciidoc-py#83 (comment).
As @elextr suggested, you can participate at...
Python 3 port development place
... that can be found here https://github.com/pepr/asciidoc/tree/py3dev (that is in the branch py3dev). The Issues were enabled.
Feel free to join!
Petr
That's great news @pepr! I'm very excited to see this finally happening.
Keep in mind you can also e-mail the asciidoc Google group list for general discussion about it, when it isn't linked to a specific issue. https://groups.google.com/forum/#!forum/asciidoc
So maybe in the mean time can asciidoc switch the shebangs to #! /usr/bin/env python2 or something?
@nik9000 That seems like a reasonable idea to me. In fact, the Fedora package modifies the script in that way.
I can open a PR if you'd like.
I'd vote for such a PR.
Sounds like a good idea now distros are making python3 the default.
Hi everyone,
Do you have any idea how to put together people interested in Python 3 port of Ascidoc?
Unfortunately, I do not have a lot of time to focus on the implementation systematically now, but I would help with the pieces.
Petr
P.S.
Python 3 port development place
... that can be found here https://github.com/pepr/asciidoc/tree/py3dev (that is in the branch py3dev). The Issues were enabled.
@elextr that probably isn't sufficient, there are a number of other scripts which need updating:
- asciidocapi.py
- filters/code/code-filter.py
- filters/graphviz/graphviz2png.py
- filters/latex/latex2png.py
- filters/music/music2png.py
- tests/asciidocapi.py
- tests/testasciidoc.py
and maybe here https://github.com/asciidoc/asciidoc/blob/master/a2x.py#L210
Ahh, filters, good point.
The asciidocapi.py file is meant to be imported into other python programs, so its shebang is never used, don't know why it has one.
The test program is for developers, who can always run python2 testasciidoc.py ..... but sure can do it too.
The internal execution of python you posted is for windows only. I know nothing about Python on windows, does it install python2?
@elextr: Python on Windows works just fine. You can install more versions side by side. Since Python 3.3 (I believe), there is the Python Launcher for Windows (PEP 397) as the part of the standard distribution. The .py and .pyw file extensions are associated with the launcher, or you can call it explicitly as py.exe or pyw.exe. It interprets the shebang line, and launches the wanted version of Python (and subversion if said explicitly). It is searching for python2 or python3 even in shebang line designed for UNIX -- you can write a portable script. This way, the Python Launcher for Windows fills the gap of a missing UNIX launcher in Windows.
I am using Python almost exclusively on Windows. (At my job, I work on Windows.) Python works just fine. I have always used the official distribution from python.org.
@pepr Thanks for that, so to be clear, on windows a command like python foo.py will examine foo.py for a shebang and run the right version, no need to run the command python2 foo.py, and as I read it that may not even work at all because python2 is not installed to PATH.
Therefore the command run by a2x should stay python.
@elextr: Almost. The usual way in the past was to install the versions of Python to C:\PythonXY\, where X is the major version of Python and Y is the minor version of Python. It can still be done this way if you tell it explicitly to the installer. (Otherwise, it now puts the Python to Program Files, I believe. Anyway, the principle is the same.) The python.exe and pythonw.exe are located in that directory; so, the directory was added to the PATH. All versions Python executables were always named python.exe -- without the 2 or 3. So, I was used to copy the executable to python2.exe or python3.exe to be able to choose explicitly the version. When testing with specific minor version of Python, I had to use the absolute path. The good idea also was to keep in PATH only the ones for the major versions (the latest 2 and the latest 3).
From Python 3.3, the new launcher py.exe is located in C:\Windows\ that is always in PATH. This way, it is better not to put any Python version to the PATH, and call py foo.py explicitly (the .exe from py.exe can be left out). Then even python foo.py does not work (if you do not put the C:\PythonXY into PATH).
Earlier, the py.exe launched the latest Python 2 that was found, recently it was changed to launch Python 3 by default -- if shebang is not used inside the script. Otherwise, shebang always wins. The PEP 397 shows how to tune the configuration, and how to write shebangs, where the executable is searched, how to prescribe a minor version, etc.
For the a2x command, I suggest not to use the fixed name of the interpreter. Instead, the absolute path can be obtained as sys.executable (the sys module is already imported into a2x).
Ok, well as I have no access to any Windows to test it, I will leave it to someone else to make a PR and someone (other than the OP) to test it.
You have access to Windows via AppVeyor. It's a CI system like Travis except it runs on Windows machines. We use it for Asciidoctor and it works great. https://www.appveyor.com/
Hi, any progress here?
@everpcpc No new things by myself (not having time to do that). Anyway, I still believe it could be a nice joint project for CS undergraduate students. If that would be the case, I would suggest a refactoring process from what is towards what it should be. I have a first hand experience (from another project) that "rewriting from scratch" is the way to dig the grave.
When needed, I use the asciidoctor (Ruby) implementation by @mojavelinux. Or the old Python implementation.
Hi all,
you can find the brand-new 100% Python3 port AsciiDoc3 at www.asciidoc3.org and on github.com/asciidoc3/asciidoc3. All 170 AsciiDoc testcases are passed! Have fun with 'Text based document generation using Python 3.x'.
Greetings from Munich, BG
Why not simply PR to https://github.com/asciidoc/asciidoc3 instead of creating a brand new project @asciidoc3 ?
Its probably better that implementations have separate sites, as @mojavelinux noted on another post, the Asciidoc.org and asciidoc github should be for discussions of the Asciidoc language itself after Asciidoc Python 2 EOLs.
The very last thing we want is a markdown type splintering of implementations with differences and confused and angry users.
@asciidoc3 communicate communicate communicate.
I agree I don't see the need for a separate organization. That broadcasts a lack of collaboration. Let's talk about how we can fuse these efforts.
Hi, I see this project description has now a link reference to "https://github.com/asciidoc3/asciidoc3", right under the project description homepage. Is this mean you guys are endorsing "asciidoc3" as the future of asciidoc for python3 now? I am confused about the comments here, and the direction of "asciidoc3". Why not continue on "https://github.com/asciidoc/asciidoc3" instead? The separation is just confusing, especially it's not a fork (no commit histories are in there.)
TBH, Asciidoc Python and Asciidoctor folks know nothing about asciidoc3. There was no communication until it just popped up.
As you may know both @mojavelinux and I are active on both Asciidoc Github and Asciidoctor Github, but other than an initial announcement there has been no further input from asciidoc3 people.
Also concerns have been raised about the asciidoc3 project changing the license for re-used code from Asciidoc Python without permission, and thats the only issue on its github.
@elextr , then why the description of this project reference asciidoc3 right on the GitHub description ? It says
NOTE: This implementation is written in Python 2 which end of lifes Jan 2020, see https://github.com/asciidoctor/asciidoctor or https://github.com/asciidoc3/asciidoc3 instead. Text based document generation. AsciiDoc is a text document format for writing notes, documentation, articles, books, ebooks, slideshows, web pages, man pages and blogs. A… http://asciidoc.org/
@zemian well, as the statement says, the Python 2 implementation here has a limited remaining lifespan.
There are some people who have invested heavily in tooling around Asciidoc Python who may find it easier to convert to asciidoc3 which is somewhat related, than to asciidoctor which is totally unrelated. It would be churlish to not list an alternative Python implementation, but its up to them to do their own research and decide if its appropriate.
Also there seems to be a group that care about the implementation language of Asciidoctor being Ruby.
Okay, thanks for the info @elextr. Yeah, I get what you saying, and I appreciate you and @mojavelinux work on bringing awesome asciidoc into Ruby and Java. Kudo to you guys! :)
It's just that it's confusing to see asciidoc3 mentioned right in the front of this project page, and yet I see this issue raised concerns regarding asciidoc3. And the fact that asciidoc3 project did not honor as a fork from here seems very dispirit as community project. I read asciidoc3 that it says it modified about 30% of the code from here to port over to python3, but yet it does not consider it's a fork any more? I am not sure how that logic works, but a fork is a fork to me. I only have one word say at this point... "confusing" :-P
It's just that it's confusing to see asciidoc3 mentioned right in the front of this project page, and yet I see this issue raised concerns regarding asciidoc3.
Well, there is not any other Python 3 implementation, so although its not perfect as this issue says, there is no similar alternative if you want a Python implementation that is possibly backward compatible for plugins/extensions. Simply ignoring it is not being helpful to Asciidoc users.
Everybody here is so busy elsewhere, that writing a long treatise on the relative merits of alternative implementations just isn't gonna happen, but at least they are mentioned somewhere potential users of Asciidoc Python might see them.
writing a long treatise on the relative merits of alternative implementations just isn't gonna happen
Of course if you wanted to do so, we could post it, probably in README. 😁
@zemian
then why the description of this project reference asciidoc3 right on the GitHub description ?
You are absolutely correct. That repository should not be mentioned in the project description. It's not a sanctioned fork and it is in violation of the GPL due to how it was set up. I have updated the project description accordingly.
Simply ignoring it is not being helpful to Asciidoc users.
Actually, quite the opposite. It's harmful to condone the behavior and it hurts the AsciiDoc community to do so. We need to handle this as a serious matter out of respect for the creators of AsciiDoc Python and OSS in general. What I'd like to do is request to have the fork removed if the owner of it does not update it to comply with the terms of the GPL.
I've reached out to the Free Software Foundation for assistance with this matter.
@mojavelinux two things:
-
who voted you sheriff, please consult before you make unilateral decisions "in the interest of Asciidoc", but ok if you feel so strongly then remove it.
-
IANAL but yes, agree its in violation of the original license, the GPL 2+ allows to distribute it under the terms of a later license, but does not allow to change the license itself, only the copyright holders can do that.
Yes getting FSF input is a good idea.
who voted you sheriff, please consult before you make unilateral decisions "in the interest of Asciidoc", but ok if you feel so strongly then remove it.
I'm not sheriff, but that fork is in violation of the license and therefore the license dictated the reference had to be removed immediately. Even worse, mentioning it there could be interpreted as condoning it.
If we're going to talk about unilateral decisions, I never agreed to have the description updated in the first place. I'm absolutely fine with moving past it as a simple misunderstanding. I have no grudge. But for the sake of argument, it was not me who made the first unilateral move here.
I am very interested to see if the FSF will help us here as I consider this an egregious violation of the license. Just because the project is in maintenance mode does not mean the GPL can be violated, especially so blatantly.
Well, since anyone can find asciidoc3 on github, pretending that it doesn't exist isn't a terribly good way to bring the asciidoc community together. I think your "condoning it" interpretation is overreach, but as I only provided it as information I don't care a lot if its removed. But I was not aware that I had resigned from the position of Asciidoc Python maintainer, so making a decision to provide information to assist users to handle its EOL is entirely within my remit.
Your post a few minutes ago as of writing, this is the first contact with asciidoc3 regarding the license issue from anyone who might be taken as officially representing the rest of the Asciidoc community.
If we want to unify the Asciidoc community then we should start out in a way that shows its worth all implementations engaging. And explaining their mistake clearly and allowing time for them to respond (its only a single person project IIUC) would probably be better than waving the FSF in a way that sounds like a threat.
The FSF website notes that its always the intention to educate and correct mistakes rather than prosecute. As I often say, never assume malice where ignorance is an adequate explanation 😁.
I here what you are saying, but this is not the first time the owner of that repository has been contacted about the situation. This is pretty far beyond being able to play dumb about it. From what I'm reading, the owner has a disregard for the open source license and is choosing to continue to violate it.
That said, I feel like my statement was very fair and even tempered. There is a violation, action is required, and if a correction is not made, we need to seek legal assistance to rectify it. This is all very much in the spirit of an open source license. Otherwise, what's the point of a license if it isn't enforced?
But I was not aware that I had resigned from the position of Asciidoc Python maintainer
My understanding is that we are both maintainers. We should consult each other on major decisions (and I am happy to comply). If that's not accurate representation of the leadership situation, I'm happy to discuss (though we should probably discuss that in a different thread so we don't sidetrack the discussion at hand).
since anyone can find asciidoc3 on github, pretending that it doesn't exist isn't a terribly good way to bring the asciidoc community together
Creating a fork that erases history of the project (as this person has done) is not a good way to bring the AsciiDoc community together either. We should not take this lightly. It's a serious offense. No adult could possibly think that erasing the history of an open source project is an honest thing to do. Linking to it sends a message that what was done is okay, which it is not. We can certainly provide information about the EOL and how users can handle it, but we should not recommend a project that undermines this project and community, and OSS in general.
Btw, your additional explanation on the issue in the repository in question is well stated. Thanks for adding that.
I think we can close this PR as the asccidoc-py3 project is now up and running.
I agree with @aerostitch given the status mentioned in asciidoc-py/asciidoc-py#15.
agreed