I'm trying to package your module as an rpm package. So I'm using the typical build, install and test cycle used on building packages from non-root account.

• "setup.py build"
• "setup.py install --root </install/prefix>"
• "pytest with PYTHONPATH pointing to sitearch and sitelib inside </install/prefix>

Here is pytest ouptput:

+ PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/asciidoc-10.0.0-2.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/asciidoc-10.0.0-2.fc35.x86_64/usr/lib/python3.8/site-packages
+ /usr/bin/pytest -ra --import-mode=importlib
=========================================================================== test session starts ============================================================================
platform linux -- Python 3.8.12, pytest-6.2.5, py-1.10.0, pluggy-0.13.1
benchmark: 3.4.1 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000)
Using --randomly-seed=1646692969
rootdir: /home/tkloczko/rpmbuild/BUILD/asciidoc-py-10.0.0
plugins: forked-1.3.0, shutil-1.7.0, virtualenv-1.7.0, expect-1.1.0, flake8-1.0.7, timeout-1.4.2, betamax-0.8.1, freezegun-0.4.2, aspectlib-1.5.2, toolbox-0.5, rerunfailures-9.1.1, requests-mock-1.9.3, cov-2.12.1, flaky-3.7.0, benchmark-3.4.1, xdist-2.3.0, pylama-7.7.1, datadir-1.3.1, regressions-2.2.0, xprocess-0.18.1, black-0.3.12, asyncio-0.15.1, subtests-0.5.0, isort-2.0.0, hypothesis-6.14.6, mock-3.6.1, profiling-1.7.0, randomly-3.8.0, nose2pytest-1.0.8, pyfakefs-4.5.1, tornado-0.8.1, twisted-1.13.3, aiohttp-0.3.0, localserver-0.5.0, anyio-3.3.1, trio-0.7.0, cases-3.6.4, yagot-0.5.0, Faker-9.3.1
collected 0 items / 2 errors

================================================================================== ERRORS ==================================================================================
________________________________________________________________ ERROR collecting tests/test_collections.py ________________________________________________________________
ImportError while importing test module '/home/tkloczko/rpmbuild/BUILD/asciidoc-py-10.0.0/tests/test_collections.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
tests/test_collections.py:2: in <module>
    from asciidoc.collections import AttrDict, DefaultAttrDict, InsensitiveDict
E   ModuleNotFoundError: No module named 'asciidoc.collections'; 'asciidoc' is not a package
___________________________________________________________________ ERROR collecting tests/test_utils.py ___________________________________________________________________
ImportError while importing test module '/home/tkloczko/rpmbuild/BUILD/asciidoc-py-10.0.0/tests/test_utils.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
tests/test_utils.py:5: in <module>
    from asciidoc import utils
E   ImportError: cannot import name 'utils' from 'asciidoc' (/usr/bin/asciidoc.py)
============================================================================= warnings summary =============================================================================
../../../../../usr/bin/asciidoc.py:1664
  /usr/bin/asciidoc.py:1664: DeprecationWarning: invalid escape sequence \s
    '(\s+(?P<name2>[^<>\s]+))?'

../../../../../usr/bin/asciidoc.py:1665
  /usr/bin/asciidoc.py:1665: DeprecationWarning: invalid escape sequence \s
    '(\s+(?P<name3>[^<>\s]+))?'

../../../../../usr/bin/asciidoc.py:1666
  /usr/bin/asciidoc.py:1666: DeprecationWarning: invalid escape sequence \s
    '(\s+<(?P<email>\S+)>)?$', s)

../../../../../usr/bin/asciidoc.py:5866
  /usr/bin/asciidoc.py:5866: DeprecationWarning: invalid escape sequence \d
    + '([\d\.]*)$'

-- Docs: https://docs.pytest.org/en/stable/warnings.html
========================================================================= short test summary info ==========================================================================
ERROR tests/test_collections.py
ERROR tests/test_utils.py
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 2 errors during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
====================================================================== 4 warnings, 2 errors in 0.47s =======================================================================
pytest-xprocess reminder::Be sure to terminate the started process by running 'pytest --xkill' if you have not explicitly done so in your fixture with 'xprocess.getinfo(<process_name>).terminate()'.

Moved from closed #41 https://github.com/asciidoc/asciidoc-py3/pull/41#issuecomment-430328794 https://github.com/asciidoc/asciidoc-py3/pull/41#issuecomment-430379163 https://github.com/asciidoc/asciidoc-py3/pull/41#issuecomment-430401257

Based on looking into using a setup.py as result of discussion in #44, at this time, I don't believe it's possible without doing a much larger restructuring of asciidoc. While https://github.com/asciidoc/asciidoc/pull/71 puts down the basics of what's necessary, it still leaves the very unfortunate issue that asciidoc relies on knowing its actual installation location so that it can then load the various conf files and other things. There's no real good way to fix this while also using setup.py that doesn't then require some amount of weird hacking in the path as it gets installed (which is bad). The whole idea of installing it to "any directory" is from an old time and there's no reason to continue to supporting it, especially as moving to a full "pythonic" setup would make it possible to install asciidoc from pypi as well as make it easier for maintainers going forward to build this into package maintainers and the such.

Ideally, I'd say that the best way forward would be to fully embrace setup.py and turn asciidoc into a more "proper" python module such that you'd have an asciidoc folder that contains all python files (as well as __init__.py) which would remove the need for the asciidocapi.py file (as asciidoc would now be normally importable), move the conf/image files inside that folder (and use pkg_resources to load them), and then one could also start to break apart asciidoc.py into smaller module files, add unit testing, etc.

However, this would be a fairly large change and I'd leave it up to @elextr to determine when (if ever) would be an appropriate time that this might be done.

The decode method on string objects doesn't exist in Python 3.6 (https://docs.python.org/3/library/stdtypes.html#str.encode). Line 263 in particular is an offender. There may be other uses but I haven't looked. I was able to trigger it by using xhtml as the output format.

Tested the following elements, no issue after the change:

• display help
• display version
• dry run on the conversion of an asciidoc file
• conversion of an asciidoc file
• refusing to run if a 2nd file is provided

Note the change from eval(str(...)) to the use of the builtin vars(...) that provides the same result but safer. Along with #33 it closes: #4

Problems seen with inconsistent newlines in the Table Of Contents HTML pulled in from the configuration file. While the rest of the contents in the resulting HTML file honored the newline style configured by the user, this specific snippet of HTML always used "\r\n".

This root of this problem existed for some time, but in earlier versions, the newline style was always "\n". The symptoms changed as a side effect of the issue "Extra line padding in source and literal blocks" (#139). In this issue, the newline style changed to "\r\n", and was noticed by users.

Change the System Attribute Evaluation function to use the newline setting from the global "config" instead of using the default newline.

Closes #154

Right now, the test suite on Travis generates the sources and then confirms that the files it generates matches the file it generates for each step of the test suite. This will only catch things that break asciidoc from generating a particular file, but not regressions, nor is it easy for new developers to catch regressions, as it requires them checking out a prior commit, generating the test suite output, and then going to their new commit and finally testing the suite there.

It'd make sense to actually check in the generated .html files in tests/data/ so that Travis can properly test against them for regressions (as well as then changes to these sources are captured within a given PR as well).

As part of the formation of the AsciiDoc Working Group at the Eclipse Foundation, the AsciiDoc trademark was transferred to the Eclipse Foundation in order to protect it. Since the AsciiDoc Python project predated the creation of the Working Group, and in fact originated the language, it is permitted to continue using "AsciiDoc" in the project name, even without demonstrating compliance (though my hope is that it eventually will, in some form). However, what is required is to add a notice to the README and website footer that AsciiDoc is a trademark of the Eclipse Foundation, Inc. That's the change proposed by this PR.

If you have any questions are concerns, please feel free to raise them.

Congratulations to @MasterOdin (and of course to all the other contributors) on this work! I know what it means to struggle with the asciidoc-code :-) But there is a drop of bitterness, isn't it? Now we have two (I guess - more or less - 95% terminated) ports, asciidoc-py3 and github.com/asciidoc3/asciidoc3 ... We should try to merge somehow?

Some have trouble using it in a Pelican.

Sample code test.adoc:

{attach}file.txt

Good output for asciidoctor --no-header-footer test.adoc:

<div class="paragraph">
<p>{attach}file.txt</p>
</div>

Bad output for asciidoc --no-header-footer test.adoc:

<div class="paragraph"><p></p></div>

How to save or render attributes with curly braces? Setting the attribute doesn't help asciidoc --no-header-footer -a attach={attach} test.adoc:

<div class="paragraph"><p></p></div>

UPDATE: But asciidoc --no-header-footer -a attach={} test.adoc produce:

<div class="paragraph"><p>{}file.txt</p></div>

It'd be nice to have a tagged version of asciidoc with Python 3 support, so distro people could package it. Not sure how early it is to be asking for this, though.

Looks like something is wrong with latest release. Building asciidoc as rpm package I found that some resources are missing

RPM build errors:
    Downloading https://github.com/asciidoc/asciidoc-py//archive/10.2.0/asciidoc-10.2.0.tar.gz to /home/tkloczko/rpmbuild/SOURCES/asciidoc-10.2.0.tar.gz
    Macro expanded in comment on line 11: %{name}-shebangs.patch

    Macro expanded in comment on line 11: %{name}-shebangs.patch

    File not found: /home/tkloczko/rpmbuild/BUILDROOT/asciidoc-10.2.0-2.fc35.x86_64/etc/asciidoc
    File not found: /home/tkloczko/rpmbuild/BUILDROOT/asciidoc-10.2.0-2.fc35.x86_64/usr/share/man/man1/*
    File not found: /home/tkloczko/rpmbuild/BUILDROOT/asciidoc-10.2.0-2.fc35.x86_64/usr/share/man/man1/testasciidoc.1*
    File not found: /home/tkloczko/rpmbuild/BUILDROOT/asciidoc-10.2.0-2.fc35.x86_64/etc/asciidoc/filters/latex
    File not found: /home/tkloczko/rpmbuild/BUILDROOT/asciidoc-10.2.0-2.fc35.x86_64/etc/asciidoc/filters/music
    File not found: /home/tkloczko/rpmbuild/BUILDROOT/asciidoc-10.2.0-2.fc35.x86_64/etc/asciidoc/filters/*/*.py[co]

Typical make install DESTDIR=</install/prefix> shows me directory structure like below:

[tkloczko@devel-g2v asciidoc-10.2.0-2.fc35.x86_64]$ tree -d
.
├── share
│   └── doc
│       ├── dblatex
│       ├── doc
│       ├── docbook-xsl
│       └── images
└── usr
    ├── bin
    ├── lib
    │   └── python3.8
    │       └── site-packages
    │           ├── asciidoc
    │           │   ├── blocks
    │           │   │   └── __pycache__
    │           │   ├── __pycache__
    │           │   └── resources
    │           │       ├── dblatex
    │           │       ├── docbook-xsl
    │           │       ├── filters
    │           │       │   ├── code
    │           │       │   │   └── __pycache__
    │           │       │   ├── graphviz
    │           │       │   │   └── __pycache__
    │           │       │   ├── latex
    │           │       │   │   └── __pycache__
    │           │       │   ├── music
    │           │       │   │   └── __pycache__
    │           │       │   ├── __pycache__
    │           │       │   └── source
    │           │       ├── icons
    │           │       │   └── callouts
    │           │       ├── javascripts
    │           │       ├── stylesheets
    │           │       └── themes
    │           │           ├── flask
    │           │           └── volnitsky
    │           └── asciidoc-10.2.0.dist-info
    └── share
        └── doc
            └── asciidoc

40 directories

In this case share should be under usr/.

Right now, the asciidoc-py parser does not fully follow the parsing rules of asciidoctor, differing in some cases. As part of the roadmap (#173), the plan is to slowly fix these instances where parsing rules differ, and bring asciidoc-py into compliance with the spec such as it currently exists. The 11.0 release would hopefully be fully spec compliant in this regard. However, to ease the developer time on working on this new parsing while still supporting 10.x releases until 11.0 is released, the new parsing stuff will be added to the 10.x releases over time and hidden behind a future-compat attribute flag. If that flag is enabled, then users would use the new parsing rules, and so give people the ability to see what they might need to change about their document to make it ready for 11.0. The flag should not be advertised until most of the stuff from 11.0 has been added so as to make the breaking changes to documents (if any) fixable in one shot, as opposed to risk breaking things on users under a point release.

The file is licensed under GNU Free Documentation License, ver. 1.3 or later version which is not compatible with GPLv2+. As such, need to remove this file, and then make it available under some other mechanism. For 10.x, the file is marked as "deprecated", but will continue to exist so as to not be a breaking change, but ideally we'll get a 11.x release out sometime this year that will remove the file, so as to bring this package out of license violation.

For now, I've put the file in https://github.com/asciidoc-py/extra-resources as its new home as I work out possible alternative installation mechanisms for the file for 11.x to ease the upgrade path for anyone who relies on it.

Dear Developers,

I am trying to convert AsciiDoc documentation into GemText.

I am doing it manually, basically: AsciiDoc → Plain Text → GemText This is not ideal but this is what I am able to do.

It would be great if you may add in any future release the support for GemText, which is quite simple and should not result in a big task, because rather than add complexity is more stripping down to the very minimum.

Here the specification about GemText:

• https://gemini.circumlunar.space/docs/gemtext.gmi
• https://gemini.circumlunar.space/docs/cheatsheet.gmi

Thanks in advance.

cicorione