asciidoc-py / asciidoc-py Goto Github PK
View Code? Open in Web Editor NEWLegacy python processor for AsciiDoc
Home Page: https://asciidoc-py.github.io
License: GNU General Public License v2.0
Legacy python processor for AsciiDoc
Home Page: https://asciidoc-py.github.io
License: GNU General Public License v2.0
There's a handful of places that remain in source code.
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).
To clarify the syntax of header I made this example and I want your opinion.
Thanks
Header'Syntax.txt
Hi all,
From this commit: 099bca3 the module does not compile with succes
Check this:
root@contrib-stretch:/tmp/asciidoc-master# git checkout 099bca3769c4a83aa459f09ba86f754ba8cbc45a
Previous HEAD position was 4cabf7d... Update CHANGELOG.txt
HEAD is now at 099bca3... Add makefile target for spell checking (#81)
root@contrib-stretch:/tmp/asciidoc-master# autoconf
root@contrib-stretch:/tmp/asciidoc-master# ./configure
checking for a sed that does not truncate output... /bin/sed
checking whether ln -s works... yes
checking for a BSD-compatible install... /usr/bin/install -c
configure: creating ./config.status
config.status: creating Makefile
root@contrib-stretch:/tmp/asciidoc-master# make
Fixing CONF_DIR in asciidoc.py
Fixing CONF_DIR in a2x.py
aspell check -p ./doc/asciidoc.dict doc/a2x.1.txt
make: aspell: Command not found
Makefile:169: recipe for target 'doc/a2x.1.txt' failed
make: *** [doc/a2x.1.txt] Error 127
From: Google Group
Ramin Dehghan Posted:
I'm very excited to be introduced to AsciiDoc through the Fedora community as a documentation tool. It really makes life as a "documenter easier".
As a contribution to Fedora and AsciiDoc it would be nice if a moderator would add Fedora Docs in the "Documents written using AsciiDoc" list.
AsciiDoc really does take documentation to a whole new level and the wide range of use by the Fedora community should not be underseen.
Cheers!
Hello,
are checklists supported? I can't find any reference to them in the AsciiDoc manual, yet third-party howtos say that you can obtain a checklist by using the following format:
= Checklist Test
.List Title
- [x] Checked Item
- [ ] Unchecked Item
The above code does format the list title and the bulleted list, but outputs the [x]
and [ ]
literally.
I am using the latest version of the master branch and this command:
a2x -f pdf test.asciidoc
Thanks for your attention.
CNAME in gh-pages lists asciidoc.org which clashes with python 2
gh-pages are manual (AFAIK) and need to be updated.
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.
This is to separate the discussion of this from #20, as well as track possible work on this (given that #20 is probably going to be merged before this is done).
asciidoc implements being able to use external filters/code to augment the central asciidoc process. However, it does this by using subprocess.Popen
and by setting shell=True
. Asciidoc handles putting together the arguments to the program as well as trying to handle properly quoting things. The benefit here is that theoretically, it allows asciidoc to utilize shell builtins (like globing and environment variables).
However, the downside is that it opens itself up to potential attack vectors. An example is this filter tag: [music,slidy-example__1.png" -; rm -rf /tmp/test #]
which would ends up getting executed as: '"/usr/local/opt/python/bin/python3.6" "/Users/mpeveler/Github/asciidoc3/filters/music/music2png.py" -m -o "/Users/mpeveler/Github/asciidoc3/doc/slidy-example__1.png" -; rm -rf /tmp/test #" -'
I'm able to get the music filter to pass as one would expect, but attach an attack (rm -rf /tmp/test
) to be secondarily executed off the Popen. I'm not sure the ability to use glob or environment variables in these execution statements is worth this security hole, or even trying to do "proper" quoting. In short, just use shell=False
and let python handle the quoting of arguments for us.
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?
Right now, asciidoc uses optparse (a depreciated module) in two places and getopt in all others. It might be preferable to replace usage of both of these with argparse which would allow for much cleaner and shorter implementation of the command line arguments for the code as opposed to these two older formats.
Hi, a Gentoo user reported an issue when compiling a UTF-8 encoded document under a C locale (see https://bugs.gentoo.org/705122). It seems that the issue is that the call to open()
in get_source_options()
opens the file in text mode without a specific encoding, in which case open()
apparently defaults to an encoding that matches the locale. I saw that #5 included a proposed fix for that (by passing an encoding to open()
), but that was never merged, and it looks like the changes were not part of the successor PRs. I would think that this would also affect people using other locales that are incompatible with UTF-8.
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.
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.
Moved from closed #41 #41 (comment) #41 (comment) #41 (comment)
Asciidoc includes a number of Javascripts from other projects (ASCIIMathML.js for example). If anyone uses them it might be worthwhile comparing those to the upstream project to see if a newer version is useful (and compatible).
Hi, I was in the master branch to build the code by using the make
command, it throwed the following error:
a2x: ERROR: "xmllint" --nonet --noout --valid "/path/to/asciidoc-py3/doc/asciidoc.1.xml" returned non-zero exit status 4
I also tried to run the xmllint command above from my terminal, and the output is:
/path/to/asciidoc-py3/doc/asciidoc.1.xml:5: validity error : Validation failed: no DTD found !
<refentry lang="en">
^
But when I removed the --valid
option in the above command, it ran successfully.
P.S. The output of xmllint --version
is:
xmllint: using libxml version 20904
compiled with: Threads Tree Output Push Reader Patterns Writer SAXv1 FTP HTTP DTDValid HTML Legacy C14N Catalog XPath XPointer XInclude Iconv ICU ISO8859X Unicode Regexps Automata Expr Schemas Schematron Modules Debug Zlib Lzma
Hello.
Wish I could do this in asciidoc document:
["graphviz", "helloworld.svg", format="svg"]
---------------------------------------------------------------------
digraph helloworld {
hello->world;
}
---------------------------------------------------------------------
and get html and PDF output right, with scalable graphics (no pixels), my primary target being PDF.
I have made a short patch that I'd like to submit to your comments and criticism and perhaps merge.
Regards.
This is a note for self to try to solve this issue.
In the lates release (9.0.0 rc2) the test target for make has been switched to the run of testasciidoc.py which causes issues in minimal build environments.
The 1st one is that it doesn't allow to change the CONF_DIR so testasciidoc try to pull the conf file from etc but this is not installed yet. A better solution is required.
Then there are other issues like source-highlight not found and other things like that.
I disabled the run of the tests in Debian for now but it would be nice to have a proper run later, hence this issue opened.
Hello! I was taking a look at this project (specifically @MasterOdin 's fork/Pull Request #2 since it seems there's going to be incoming changes) as I, and many others, are interested in the state of Asciidoc for Python 3. One thing I noticed is some rather inconsistent spacing between classes/functions and other PEP 8-related formatting quirks.
I would be happy to go through and make all of those tedious adjustments and send a PR, but I wanted to check that it's something that may be wanted before I get neck deep in the code doing so (or in case I missed some intentional reasoning such as compact source code).
If this is not desired, feel free to close this issue!
As I did with "Header Syntax" I tried the same with this topic, To make a better understanding of the Document Structure, The problem is: "I don't know to render this ascii into an image".
Thanks
Document_Structure.txt
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 #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.
Python 3.4 is End of Life: https://devguide.python.org/devcycle/#end-of-life-branches
In Fedora, we're going to remove all Python2 packages due of Python2 EOL in 2020.
One of those packages is going to be dblatex, due upstream is quite dead for 2 years and no Python3 port of dblatex is available (at least I am not aware of it).
Do you plan to replace dblatex in asciidoc-py3? Is there any alternative?
With Python 3.7, I see a lot of deprecation warnings here:
Would like to be able to update readme with proper link to Travis for this project and not the py2 version.
I use a2x to generate a man page from an asciidoc text file. In asciidoc-8.6.8, the --destination-dir option of a2x was documented as "Output directory." and it worked as documented. With asciidoc-8.6.9, the documentation says that the option "is only applicable to HTML based output formats". The option continues to work with 8.6.9 as before, but a warning is printed: "a2x: WARNING: --destination-dir option is only applicable to HTML based outputs"
Lex Trotman says there is no such limitation in the current code and the warning message is wrong:
https://groups.google.com/forum/#!topic/asciidoc/5ByGKFq1fMs
Would you be interested in a Mac Homebrew formula for asciidoc-py3 so it could be easily installed on macOS? Might make it easier to get people to test it.
The current Mac Homebrew asciidoc
formula points to the Python2 implementation. Setting up a parallel formula could make migration to the Python3 version easier, assuming the port is successful.
if its only a single file that specifies installation then it probably isn't a problem.
It would be a single file (and maybe a README to go with it), but it needs to be maintained in a separate repo that functions as a Homebrew "tap". This is their mechanism for supporting third-party formula definitions.
I've set up an example of how this could be done in my apjanke/personal
tap here: https://github.com/apjanke/homebrew-personal/blob/70f8de6ab173170bc0e6088ba99599fb36001e1a/Formula/asciidoc-py3.rb. Once there are tagged releases of the py3 port, one could be added as the "devel" version, in addition to the "head" definition.
And then is it possible to have the Python 2 entry advise using the -py3 version after its made available?
The asciidoc-py3 project looks a little young to be listed in core Homebrew yet. But you could set up this "custom" asciidoc-py3 formula for use during the port/migration, and if the migration to py3 is successful, the main Homebrew asciidoc formula could be changed to use the new py3 version, which would migrate all the existing users over when they did a brew upgrade
. Then the custom formula could then go away, unless you wanted to keep it around for testing pre-release versions.
(Discussion migrated from #40 (comment))
Attempting to convert the following fragment on its own:
[cols="1,3,3"]
|===
|Language Feature |Markdown |AsciiDoc
|Includes
|_n/a_
a|
[source,text]
----
\include::intro.adoc[]
----
|===
causes the following error:
asciidoc: FAILED: <stdin>: line 2: unexpected error:
asciidoc: ------------------------------------------------------------
Traceback (most recent call last):
File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 6121, in asciidoc
has_header = document.parse_header(doctype, backend)
File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 1562, in parse_header
has_header = (Title.isnext() and Title.level == 0 and AttributeList.style() != 'float')
File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 2048, in isnext
lines = reader.read_ahead(2)
File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4525, in read_ahead
while i < count and not self.eof():
File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4500, in eof
return self.read_next() is None
File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4504, in read_next
result = self.read()
File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4411, in read
result = self.read_super()
File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4405, in read_super
result = Reader1.read(self, self.skip)
File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4354, in read
self.open(fname)
File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4244, in open
self.f = open(fname, 'r', encoding='utf-8')
FileNotFoundError: [Errno 2] No such file or directory: 'intro.adoc'
asciidoc: WARNING: test.asciidoc: line 12: filter non-zero exit code: "/usr/bin/python3" "/mnt/e/Github/asciidoc-py3/asciidoc.py" -b html5 --attribute "source-highlighter=pygments" -a "indir=/mnt/e/Github/asciidoc-benchmarks" -a "blockname=table" -s -: returned 1
asciidoc: WARNING: test.asciidoc: line 12: no output from filter: "/usr/bin/python3" "/mnt/e/Github/asciidoc-py3/asciidoc.py" -b html5 --attribute "source-highlighter=pygments" -a "indir=/mnt/e/Github/asciidoc-benchmarks" -a "blockname=table" -s -
Replacing the \include
here with something else works as expected in that the text is surrounded by a source highlighter box.
The output of asciidoc-py right now:
Expected output from asciidoctor:
From my understanding, the \include
here should be escaped (https://asciidoc.org/userguide.html#_system_macros) as it has a leading \
, but it's not, causing the include to be interpreted literally, and so then throws the error about not being able to load intro.adoc
. Doing \include::intro.adoc[]
on its own does work as expected and then just prints the text literal and does not attempt to actual include the file.
As asciidoc-py3 is a consumer of aspell
to ensure the quality of its own releases and one would assume that the asciidoc-py3 developers have a strong understanding of the overall asciidoc syntax, it would be nice for the overall asciidoc project to provide a filter for aspell (similar to the existing nroff, TeX, and SGML filters).
Split this from #44 (comment) to allow me to better track this work, what's left, etc.
Currently, asciidoc "uses" the A-A-P, while is not really supported anymore, not in any distro distribution, python2 only, etc. Ideally, transition away from it to something more universal, like make
as nothing that happens here is that unique.
The A-A-P was setup in the following way:
common.aap:
$VERS
and $DATE
) (Added variables to makefile in #54)main.aap
common.aap
(done in #54)common.aap
into asciidoc.py
, a2x.py
, and configure.ac
(done in #54)tags
file and then run ctags over asciidoc.py
, asciidocapi.py
, tests/testasciidoc.py
./doc/main.aap
./examples/website/main.aap
vers_update
, docs
, website
and then does:
asciidoc-$VERS
asciidoc-$VERS.tar.gz
) from all files listed in MANIFEST
filezip
command exists, and if so creates a zip (named asciidoc-$VERS.tar.gz
) using the previously created symlink directorypython ./asciidoc.py --doctest
, python ./asciidocapi.py
, executes ./doc/main.aap test
, and then python ./tests/testasciidoc.py run
if there are *.html files in ./tests/data
./doc/main.aap:
./doc/asciidoc.dict
as a dictionary for it (done in #81)clean_testfiles
and then generates the output from running asciidoc on the files in ./doc./examples/website/main.aap:
~/webs/asciidoc
and then copies the files necessary for the website to that directory. Does execute ./main.aap distribution
as part of this to ensure all necessary files have been generated.The actual installation steps of asciidoc have always been handled by the Makefile.in
file.
While one could try and place individual makefiles in the root folder, in docs, in examples/website/ and then do stuff with includes or hierarchal make executes, getting the pathing working correctly (especially if wanting to do a make execute from root into a sub-folder, have to update the $pwd first, then change it back after done execution) and other stuff makes it (to me) not worth trying to maintain 3 different makefiles. My goal is to unify all parts listed above into one topfile Makefile that can be used to build, update, install all parts of asciidoc.
Commands under the the sub-directories (doc and website) will be prefixed with doc_
and website_
respectively. An example of this is doc_spell
runs the spell for the doc files and website_spell
runs the spell for website files. There may be a top-level command to run both of these (e.g. make spell
).
Processing the following file:
Line 1
// comment
-- Line 2
produces "Line 1" only.
Could you please tell me whether this is a bug or I missed something in User Guide?..
Thank you!
Here is the usage screen for tests/testasciidoc.py:
./tests/testasciidoc.py --help [21:43:54]
illegal command options
Usage: testasciidoc.py [OPTIONS] COMMAND
Run AsciiDoc conformance tests specified in configuration FILE.
Commands:
list List tests
run [NUMBER] [BACKEND] Execute tests
update [NUMBER] [BACKEND] Regenerate and update test data
Options:
-f, --conf-file=CONF_FILE
Use configuration file CONF_FILE (default configuration file is
testasciidoc.conf in testasciidoc.py directory)
--force
Update all test data overwriting existing data
Based on this, I would expect that usage would be that I can specify a test number as well as a backend for that number. It's not obvious that you can pass an integer (for NUMBER) or a string (for BACKEND) or both and the order doesn't matter. These are loosely positional arguments, but is not obvious in how that is, unless you look at the arg parsing code.
Would it make sense to change it to be that testasciidoc.py update|run [--number NUMBER] [--backend BACKEND]
. This allows a more straightforward usage model (that can be explained concisely in a usage string). Can make it so the flags are either --number
or -n
, and --backend
or -b
.
I don't know if this is really an issue or if I'm doing something wrong.
I'm writing a kanji list and I want to add a different class on each kanji.
So I wrote this :
[testA]#薫# [testB]#病# [testC]#痴# [testD]#痘# [testE]#症# [testF]#疾# +
[testG]#癖# [testH]#匿# [testI]#匠# [testJ]#医# [testK]#匹# [testL]#区# +
But I get that :
<div class="paragraph">
<p>
<span class="testA">薫</span> <span class="testB">病# [testC]#痴</span> <span class="testD">痘</span> <span class="testE">症</span> <span class="testF">疾</span><br />
<span class="testG">癖</span> <span class="testH">匿</span> <span class="testI">匠# [testJ]#医</span> <span class="testK">匹</span> <span class="testL">区</span><br />
</p>
</div>
It seems that something wrong is happening, but only on certain characters (病 and 匠 for this example), I have no idea why.
When trying to specify custom css file, style is just partially applied:
CMD: python asciidoc.py -a stylesheet=my_styles/my_style.css doc/asciidoc.txt
after adding the path to stylesheets directory WARNING is displayed and no output is generated:
CMD: python asciidoc.py -a stylesheet=my_styles/my_style.css -a stylesdir=my_styles doc/asciidoc.txt
WARNING: include file not found: {working_dir}\my_styles\asciidoc.css
Problem could be solved if I rename my_style.css
to asciidoc.css
and adding both arguments stylesheet
and stylesdir
when calling asciidoc.py from CLI.
On the page http://asciidoc.org/publishing-ebooks-with-asciidoc.html Under "Styling your books" there is a link to http://epubzengarden.com/ That website no longer exists at that location.
How can I
?? Thank you!
When I read the "Quoted Text" Chapter of "Asciidoc User Guide", I found some ponctuation in the description are not in place (and may be I am wrong), So I tried to rewrite this part to express my Opinion.
Thanks
Example: [red]##r##[green]##g##[blue]##b##
rendered as:
<p>
Example: <span class="red">r</span>[green]g[blue]b
</p>
This one works correctly:
Example: [red]##r## [green]##g## [blue]##b##
running a2x with '-b xetex' on mac issues the following warning:
/bin/sh: unwraplatex.py: command not found
and
WARNING: file.adoc: line 3038: filter non-zero exit code: unwraplatex.py: returned 127
asciidoc install does not have unwraplatex.py in the filters
directory:
/opt/local/etc/asciidoc/filters:
total used in directory 0 available 244.8 GiB
drwxr-xr-x 39 root wheel 1248 Mar 10 20:28 ..
drwxr-xr-x 3 root wheel 96 Mar 10 20:28 source
drwxr-xr-x 7 root wheel 224 Mar 10 20:28 .
drwxr-xr-x 4 root wheel 128 Mar 10 20:28 music
drwxr-xr-x 4 root wheel 128 Mar 10 20:28 latex
drwxr-xr-x 4 root wheel 128 Mar 10 20:28 graphviz
drwxr-xr-x 4 root wheel 128 Mar 10 20:28 code
adding a copy of unwraplatex.py to my path resolves the error
For reasons which are too tedious to go into, our XML default catalog doesn't have the docbook XML entries in. We need to set SGML_CATALOG_FILES
and pass --catalogs
to xmllint but as asciidoc wraps xmllint that's harder. I'm currently using this patch as a workaround:
diff --git a/a2x.py b/a2x.py
index 2d7699a..5bb995f 100755
--- a/a2x.py
+++ b/a2x.py
@@ -49,2 +49,4 @@ LYNX = 'lynx' # alternate text file generator.
XMLLINT = 'xmllint' # Set to '' to disable.
+if "SGML_CATALOG_FILES" in os.environ:
+ XMLLINT += " --catalogs"
EPUBCHECK = 'epubcheck' # Set to '' to disable.
@@ -636,3 +638,3 @@ class A2X(AttrDict):
if not self.no_xmllint and XMLLINT:
- shell('"%s" --nonet --noout --valid "%s"' % (XMLLINT, docbook_file))
+ shell('%s --nonet --noout --valid "%s"' % (XMLLINT, docbook_file))
>>> from asciidoc3 import asciidoc3api
>>> asciidoc3 = asciidoc3api.AsciiDoc3API()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/insert_username/.virtualenvs/asciidoc3api-venv/lib/python3.7/site-packages/asciidoc3/asciidoc3api.py", line 156, in __init__
self.__import_asciidoc3()
File "/home/insert_username/.virtualenvs/asciidoc3api-venv/lib/python3.7/site-packages/asciidoc3/asciidoc3api.py", line 185, in __import_asciidoc3
self.asciidoc3 = asciidoc3
UnboundLocalError: local variable 'asciidoc3' referenced before assignment
asciidoc3==3.1.0.post5
It would be helpful for people new to AD to have a statement or paragraph in the Readme or elsewhere that states what asciidoc-py3 is relative to asciidoctor. I'm not looking for a contest, just information on where ad-py3 might be more appropriate and what the project goals are. For example adopting one or more of the highlighted differences? I'm personally aligned with python, but the Dr looks more polished/solid. Add some information to help me choose the best tool for the job. Thanks!
Wanted to use asciidoc to create current man pages for git, but cannot get asciidoc3 to run.
root@x064:[/home/root]pip3 install asciidoc3
Collecting asciidoc3
Downloading https://files.pythonhosted.org/packages/be/e9/defb4373cca5e1d42c d952ee7aeefc1dda0c03d5211c27b6f18e859bea43/asciidoc3-3.1.0.post4.tar.gz (770kB )
|################################| 778kB 7.7MB/s
Installing collected packages: asciidoc3
Running setup.py install for asciidoc3 ... done
Successfully installed asciidoc3-3.1.0.post4
WARNING: You are using pip version 19.2.2, however version 19.2.3 is available .
You should consider upgrading via the 'pip install --upgrade pip' command.
root@x064:[/home/root]asciidoc
ksh: asciidoc: not found.
root@x064:[/home/root]asciidoc3
Traceback (most recent call last):
File "/opt/bin/asciidoc3", line 11, in <module>
load_entry_point('asciidoc3==3.1.0.post4', 'console_scripts', 'asciidoc3') ()
File "/opt/lib/python3.7/site-packages/pkg_resources/__init__.py", line 489, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/opt/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2793 , in load_entry_point
return ep.load()
File "/opt/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2411 , in load
return self.resolve()
File "/opt/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2417 , in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
ModuleNotFoundError: No module named 'asciidoc3'
This is what seems to have been "installed"
root@x064:[/opt/lib/python3.7]find . | grep asciidoc
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/PKG-INFO
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/SOURCES.txt
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/dependency_links.txt
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/entry_points.txt
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/installed-files.txt
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/not-zip-safe
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/top_level.txt
Can always be user-error, but generally, it just installs. Maybe the .post4 bit is in the way, but I do not know what to correct. Suggestions welcome.
I am in interested to continuously document my Django project in Asciidoc. However, I did not get a comprehensive tutorial on doing that. Please give me some guideline.
It looks like the testasciidoc.py
program has some undocumented dependencies on GNU source-highlight, GNU LilyPond, and GraphViz. When they are missing, it emits a bunch of error messages and stack traces, but still exits with a successful status.
For example, here's what I get when running against the current code in master
, I get output that looks like this. (Full output here.)
$ ./tests/testasciidoc.py --force update &>test-update-out-with-missing-deps.txt
$ echo $?
0
Output:
/bin/sh: source-highlight: command not found
Traceback (most recent call last):
File "/usr/local/Cellar/asciidoc/8.6.9/etc/asciidoc/filters/graphviz/graphviz2png.py", line 168, in <module>
app = Application()
File "/usr/local/Cellar/asciidoc/8.6.9/etc/asciidoc/filters/graphviz/graphviz2png.py", line 68, in __init__
format_output = subprocess.Popen(["dot", "-T?"], stderr=subprocess.PIPE, stdout=subprocess.PIPE).communicate()[1]
File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 710, in __init__
errread, errwrite)
I think it would be better if it checked for its dependencies, and if they were missing, output a brief error message for each one identifying the missing program. And exited with a non-zero status if any dependencies were missing.
A number of projects (like docbook) have moved from SF to GH / GL. Need to go through and double check that all existing sourceforge links still point at a project being developed there, and if not, update them to the appropriate place.
Related to #113
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.