blogpost: invalid Python module name: /usr/bin/asciidoc

109 views
Skip to first unread message

Tong

unread,
Dec 24, 2009, 12:10:25 PM12/24/09
to asciidoc
I've just downloaded latest blogpost from

http://hg.sharesource.org/blogpost/archive/c97a330f9778.tar.bz2

When I ran it, I got:

$ ./blogpost.py c ttt.doc
blogpost: invalid Python module name: /usr/bin/asciidoc

And adding the last line in ~/.blogpost as follows won't work either.

$ type asciidoc
asciidoc is /usr/bin/asciidoc

$ tail -2 ~/.blogpost
#ASCIIDOC = ['asciidoc']
ASCIIDOC = ['python', '/usr/bin/asciidoc']

Please help.

thanks

Stuart Rackham

unread,
Jan 3, 2010, 10:28:32 PM1/3/10
to asci...@googlegroups.com

I think this is because /usr/bin/asciidoc is the actual Python script file,
Python modules must have .py extension, it should be named /usr/bin/asciidoc.py
and then create a symbolic link to it named /usr/bin/asciidoc so you can use the
name asciidoc to invoke asciidoc. The AsciiDoc Makefile does this for you, see
the progsymlink target in
http://hg.sharesource.org/asciidoc/file/4040350988d8/Makefile.in


Cheers, Stuart


>
> thanks
>
> --
>
> You received this message because you are subscribed to the Google Groups "asciidoc" group.
> To post to this group, send email to asci...@googlegroups.com.
> To unsubscribe from this group, send email to asciidoc+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
>
>
>

Tong

unread,
Jan 4, 2010, 10:38:43 AM1/4/10
to asciidoc

On Jan 3, 10:28 pm, Stuart Rackham <srack...@gmail.com> wrote:

> > $ ./blogpost.py c ttt.doc
> > blogpost: invalid Python module name: /usr/bin/asciidoc
>
> > And adding the last line in ~/.blogpost as follows won't work either.

> . . .


>
> > $ tail -2 ~/.blogpost
> > #ASCIIDOC = ['asciidoc']
> > ASCIIDOC = ['python', '/usr/bin/asciidoc']
>

> I think this is because /usr/bin/asciidoc is the actual Python script file,
> Python modules must have .py extension, it should be named /usr/bin/asciidoc.py
> and then create a symbolic link to it named /usr/bin/asciidoc so you can use the
> name asciidoc to invoke asciidoc. The AsciiDoc Makefile does this for you, see
> the progsymlink target inhttp://hg.sharesource.org/asciidoc/file/4040350988d8/Makefile.in

Thanks, Stuart.

My asciidoc is Debian binary release. It doesn't have asciidoc.py
anywhere, only /usr/bin/asciidoc. So I created the symlink the other
way around:

$ dir /usr/bin/asciidoc*
-rwxr-xr-x 1 root root 220309 2009-11-01 05:20 /usr/bin/asciidoc*
lrwxrwxrwx 1 root root 8 2010-01-04 10:27 /usr/bin/asciidoc.py ->
asciidoc*

But I still get the

blogpost: invalid Python module name: /usr/bin/asciidoc

error.

I've changed my ~/.blogpost 3 times as the following:

- #ASCIIDOC = ['python', '/usr/bin/asciidoc']
- ASCIIDOC = ['python', '/usr/bin/asciidoc']
- ASCIIDOC = ['python', '/usr/bin/asciidoc.py']

but neither work.

Anything else?

PS, My asciidoc:

$ apt-cache policy asciidoc
asciidoc:
Installed: 8.5.1-1
Candidate: 8.5.1-1
Version table:
*** 8.5.1-1 0
300 http://debian.mirror.rafal.ca testing/main Packages
50 http://debian.mirror.rafal.ca unstable/main Packages
100 /var/lib/dpkg/status

thanks

Stuart Rackham

unread,
Jan 4, 2010, 2:13:59 PM1/4/10
to asci...@googlegroups.com
Tong wrote:
>
> On Jan 3, 10:28 pm, Stuart Rackham <srack...@gmail.com> wrote:
>
>>> $ ./blogpost.py c ttt.doc
>>> blogpost: invalid Python module name: /usr/bin/asciidoc
>>> And adding the last line in ~/.blogpost as follows won't work either.
>> . . .
>>
>>> $ tail -2 ~/.blogpost
>>> #ASCIIDOC = ['asciidoc']
>>> ASCIIDOC = ['python', '/usr/bin/asciidoc']
>> I think this is because /usr/bin/asciidoc is the actual Python script file,
>> Python modules must have .py extension, it should be named /usr/bin/asciidoc.py
>> and then create a symbolic link to it named /usr/bin/asciidoc so you can use the
>> name asciidoc to invoke asciidoc. The AsciiDoc Makefile does this for you, see
>> the progsymlink target inhttp://hg.sharesource.org/asciidoc/file/4040350988d8/Makefile.in
>
> Thanks, Stuart.
>
> My asciidoc is Debian binary release. It doesn't have asciidoc.py
> anywhere, only /usr/bin/asciidoc. So I created the symlink the other
> way around:
>
> $ dir /usr/bin/asciidoc*
> -rwxr-xr-x 1 root root 220309 2009-11-01 05:20 /usr/bin/asciidoc*
> lrwxrwxrwx 1 root root 8 2010-01-04 10:27 /usr/bin/asciidoc.py ->
> asciidoc*

The problem with this approach is that blogpost follows symlinks to the the
actual file (/usr/bin/asciidoc) so there's effectively no change. Rename
asciidoc to asciidoc.py and create an asciidoc symlink to asciidoc.py.


Cheers, Stuart


>
> But I still get the
>
> blogpost: invalid Python module name: /usr/bin/asciidoc
>
> error.
>
> I've changed my ~/.blogpost 3 times as the following:
>
> - #ASCIIDOC = ['python', '/usr/bin/asciidoc']
> - ASCIIDOC = ['python', '/usr/bin/asciidoc']
> - ASCIIDOC = ['python', '/usr/bin/asciidoc.py']
>
> but neither work.
>
> Anything else?
>
> PS, My asciidoc:
>
> $ apt-cache policy asciidoc
> asciidoc:
> Installed: 8.5.1-1
> Candidate: 8.5.1-1
> Version table:
> *** 8.5.1-1 0
> 300 http://debian.mirror.rafal.ca testing/main Packages
> 50 http://debian.mirror.rafal.ca unstable/main Packages
> 100 /var/lib/dpkg/status
>
> thanks
>

Tong

unread,
Jan 6, 2010, 9:44:26 AM1/6/10
to asciidoc
On Jan 4, 2:13 pm, Stuart Rackham <srack...@gmail.com> wrote:

> . . . blogpost follows symlinks to the the
> actual file (/usr/bin/asciidoc) so there's effectively no change. . .

Thanks for the explain. It works now as expected.

Tong

unread,
Jan 6, 2010, 10:53:04 AM1/6/10
to asciidoc
On Jan 4, 10:38 am, Tong <suntong...@gmail.com> wrote:

> My asciidoc is Debian binary release. It doesn't have asciidoc.py
> anywhere, only /usr/bin/asciidoc. So I created the symlink the other
> way around:
>
> $ dir /usr/bin/asciidoc*
> -rwxr-xr-x 1 root root 220309 2009-11-01 05:20 /usr/bin/asciidoc*
> lrwxrwxrwx 1 root root      8 2010-01-04 10:27 /usr/bin/asciidoc.py ->
> asciidoc*
>

> But I still get the . . . error.

Hi Stuart,

I raised a Debian bug report hoping that the problem could be avoided
in future Debian releases, but my bug report was rejected.

You know Debian has a very strict policy what kind of files should be
at what places. Some people might think it unnecessary, but for over
4G of tools seamlessly working together, sticking to the strict policy
is a must.

As I don't know Debian policy well, I asked the Debian developer to
propose a proper installation way. Here is what I got:

,-----
| If its used a library it should it used in proper locations for
python libs
| like /usr/lib/python2.5. Best way would to provide a proper setup.py
which
| would make it much easier to install the api/lib in the correct
place.
| /usr/bin is not a place for libs.
`-----

I'm wondering if you could make such (re)arrangement so that all the
Debian users can all benefit from asciidoc and blogpost out of the
box?

Thanks a lot!

Stuart Rackham

unread,
Jan 6, 2010, 3:00:21 PM1/6/10
to asci...@googlegroups.com

asciidoc.py (which Debian renamed to asciidoc) *is* the executable, it just also
happens to function as a Python module. It's the file name not it's function
that seems to be the sticking point, I was not aware of any Debian name
restriction that says an executable cannot have a .py file name extension.

Cheers, Stuart


>
> Thanks a lot!
>

Alexander Wirt

unread,
Jan 6, 2010, 3:14:01 PM1/6/10
to asciidoc
Hi,

*snip*


> asciidoc.py (which Debian renamed to asciidoc) *is* the executable, it just also
> happens to function as a Python module. It's the file name not it's function
> that seems to be the sticking point, I was not aware of any Debian name
> restriction that says an executable cannot have a .py file name extension.

it can, but this is extremly awful. And in general, if it can be used
as a
module it should be in the modulepath. That makes life for everybody
easier.

Alex

Stuart Rackham

unread,
Jan 6, 2010, 4:45:24 PM1/6/10
to asci...@googlegroups.com

I was a bit loose characterizing asciidoc.py as a Python module/library --
asciidoc.py doesn't behave like a Python library (in the normal sense of
importing it directly and using it) -- it behaves more like a runnable script
and is never imported or referenced directly by client applications. The actual
"library" that handles all this is asciidocapi.py which is not part of asciidoc
(it is included with client applications).

I would characterize the technique as unusual rather than awful in that the
consequences simplify installation (no need to write, maintain and run a
setup.py, no separate library dependencies) and there is no downside (apart from
being unusual).

The details can be found here: http://www.methods.co.nz/asciidoc/asciidocapi.html

On a philosophical note, one of the design goals was to have as few external
dependencies as possible -- asciidoc is a single executable file with no
external dependencies apart from the Python interpreter and standard libraries.
Dependencies are the bane of software distribution.


Cheers, Stuart


>
> Alex
>

Alexander Wirt

unread,
Jan 7, 2010, 3:30:32 AM1/7/10
to asciidoc

Hm, what do you think of the following approach. I'll install
asciisdoc.py into i.e. /usr/share/asciidoc/asciidoc.py and make
/usr/bin/asciidoc just a shell wrapper which calls /usr/share/asciidoc/
asciidoc.py.

Alex

Stuart Rackham

unread,
Jan 7, 2010, 2:39:32 PM1/7/10
to asci...@googlegroups.com

This would not work because the asciidocapi.py library won't find asciidoc.py in
/usr/share/asciidoc (by default, it searches the PATH for the asciidoc.py
executable).

Why not simply leave the executable name as asciidoc.py and add an asciidoc
symlink so the user can invoke it with the name asciidoc?

Cheers, Stuart

>
> Alex
>

Phillip Lord

unread,
Jan 29, 2010, 7:29:17 AM1/29/10
to asci...@googlegroups.com
Stuart Rackham <srac...@gmail.com> writes:
>>> On a philosophical note, one of the design goals was to have as few external
>>> dependencies as possible -- asciidoc is a single executable file with no
>>> external dependencies apart from the Python interpreter and standard libraries.
>>> Dependencies are the bane of software distribution.
>> Hm, what do you think of the following approach. I'll install
>> asciisdoc.py into i.e. /usr/share/asciidoc/asciidoc.py and make
>> /usr/bin/asciidoc just a shell wrapper which calls /usr/share/asciidoc/
>> asciidoc.py.
>
> This would not work because the asciidocapi.py library won't find asciidoc.py
> in /usr/share/asciidoc (by default, it searches the PATH for the asciidoc.py
> executable).
>
> Why not simply leave the executable name as asciidoc.py and add an asciidoc
> symlink so the user can invoke it with the name asciidoc?

I've just been trying to update to the new version of blogpost (because
the proxy support would be good for me!) and have hit this problem.
The email thread seemed to have reached an impasse and I thought to
bring the issue up again.

I think that there is a problem with asciidocapi.py -- it's searches and
finds a file called "asciidoc" (as well as others) but then immediately
excepts if it finds this...


for fname in ['asciidoc.py','asciidoc.pyc','asciidoc']:
cmd = find_in_path(fname)
if cmd: break
else:
# Finally try current working directory.
for cmd in ['asciidoc.py','asciidoc.pyc','asciidoc']:
if os.path.isfile(cmd): break
else:
raise AsciiDocError('failed to locate asciidoc.py[c]')
cmd = os.path.realpath(cmd)
if os.path.splitext(cmd)[1] not in ['.py','.pyc']:
raise AsciiDocError('invalid Python module name: %s' % cmd)


which is not perfect from a user point of view. If it can't handle
"/usr/bin/asciidoc", surely it shouldn't be looking for it?

The shell wrapper approach would not be too bad for me, incidentally. It
wouldn't work seamlessly, of course, but at least I could make it work
with configuration rather than fiddling with /usr/bin files -- I try not
to do this as I work off quite a few machines -- my home space is
sync'd, but for the /usr/bin fix, I'd have to fiddle with my machines
manually. And, refiddle with them for every asciidoc update.

If there is a debian package for blogpost, or the asciidocapi.py, then
the latter could be patched to force the correct location into the
system path; not ideal, but it would be a small, one-line patch.

Failing this, is it not possible for asciidocapi to do an eval rather
than an import if it finds a bare "/usr/bin/asciidoc", or something
equivalent? I'm afraid my python isn't strong enough to know for sure.

Phil

Tong

unread,
Feb 2, 2010, 6:15:24 PM2/2/10
to asciidoc

On Jan 29, 7:29 am, Phillip Lord <phillip.l...@newcastle.ac.uk> wrote:

> The email thread seemed to have reached an impasse and I thought to
> bring the issue up again.

Second to Phil's suggestion. I also hope that the two side can come
back to the negotiation table and reach some kind of compromise.

Phil has looked into the python side. Let me balancing it with looking
at the Debian side. Many people don't understand Debian's very strict
policy quite well, including me. So if someone could explain the
bottom-line for Debian, I think that will improve the mutual
understanding.

I know many packages release binary executables with different names,
using symlinks pointing to the actual one (e.g., netcat/nc, par2/
par2create/par2verify, etc). I know traditionally perl/tk scripts can
be called with or without the .pl/.tk extension. What's the bottom-
line here for Debian?

thanks

Phillip Lord

unread,
Feb 3, 2010, 12:42:05 PM2/3/10
to asci...@googlegroups.com


For myself, I can see the value in debians policy; for sure, it's better
to type "asciidoc" rather than "asciidoc.py". But I appreciate Stuarts
desire to reduce dependencies.

The flip side is that this used to work -- blogpost just called asciidoc
as an executable, so that this issue didn't arise. Again, I can see the
point of using it as a library rather than having an external shell
call.

The practical upshot of all of this, though, is that at the moment the
new version of blogpost doesn't work with debian asciidoc or, by
inheritance, ubuntu. A pity because the inclusion of wordpress.conf had
just fixed one headache.

At the moment, the only option I can see is running both from installs
within my homespace, which is the sort of thing I am trying to get away
from.

Phil

Stuart Rackham

unread,
Feb 3, 2010, 3:50:34 PM2/3/10
to asci...@googlegroups.com

Just to be clear on this, I don't have any beef (philosophically or otherwise)
with Debian and am extremely appreciative of great work done by the Debian
maintainers, and as a general principle I agree that libraries should not live
in bin directories.

In this case though it boils down to the single question: whether or not Debian
allows executable program names to end in '.py' (I don't know the answer to
this). The AsciiDoc API library (asciidocapi.py) executes the AsciiDoc script by
first importing it, and herein lies the problem: Python won't import a file
unless it has a .py or .pyc extension (unless someone knows how to import files
with arbitrary names).

Now I could revert to shelling 'asciidoc' as before, but this would be much
slower and not as flexible. Neither would it resolve the real problem viz that
any other apps using the AsciiDoc API would not run on Debian.

Cheers, Stuart

>
> Phil
>


Alexander Wirt

unread,
Feb 3, 2010, 4:20:26 PM2/3/10
to asci...@googlegroups.com

I don't have a problem with asciidoc.py or asciidoc, but not both. This would
pollute the namespace to much. Unfortunatly the binary was named asciidoc
since ages in debian and many tools depend on the binaryname. So I can't just
rename it to asciidoc.py.

Alex

Alexander Wirt

unread,
Feb 3, 2010, 4:21:02 PM2/3/10
to asci...@googlegroups.com
Tong schrieb am Dienstag, den 02. Februar 2010:

>
>
> On Jan 29, 7:29�am, Phillip Lord <phillip.l...@newcastle.ac.uk> wrote:
>
> > The email thread seemed to have reached an impasse and I thought to
> > bring the issue up again.
>
> Second to Phil's suggestion. I also hope that the two side can come
> back to the negotiation table and reach some kind of compromise.
>
> Phil has looked into the python side. Let me balancing it with looking
> at the Debian side. Many people don't understand Debian's very strict
> policy quite well, including me. So if someone could explain the
> bottom-line for Debian, I think that will improve the mutual
> understanding.

I never said its a policy decision, its my decision.

> I know many packages release binary executables with different names,
> using symlinks pointing to the actual one (e.g., netcat/nc, par2/
> par2create/par2verify, etc). I know traditionally perl/tk scripts can
> be called with or without the .pl/.tk extension. What's the bottom-
> line here for Debian?

Having binaries with two files in $PATH is polluting the namespace. From 4055
binaries in /usr/bin/ on my devel system is exactly 1 (xgettext) which is
twice in the namespace. Having everything twice is a burden for everybody
using completion in a shell.

Your example are false: netcat/nc is an alternative and par2 is a multicall
binary which behaves differently if its called with a different name. The
most popular example for such a binary is busybox.

Alex

Stuart Rackham

unread,
Feb 3, 2010, 5:04:02 PM2/3/10
to asci...@googlegroups.com

With the help of a Google search I think I may have answered my own question --
it looks like you can use Python imp module to load arbitrarily named source files:

$ echo 'print "Hello World!"'>mod1

$ echo 'import imp
> imp.load_source("foo","mod1")' > test.py

$ python test.py
Hello World!

Hopefully this will side-step the issue, I'll post a patch when I get some spare
time.

Cheers, Stuart

>
> Alex
>

Tong

unread,
Feb 3, 2010, 5:24:38 PM2/3/10
to asciidoc

On Feb 3, 5:04 pm, Stuart Rackham <srack...@gmail.com> wrote:

> With the help of a Google search I think I may have answered my own question . . .

Hoooray!

Looking forward to your patch.

Alexander Wirt

unread,
Feb 4, 2010, 1:52:50 AM2/4/10
to asci...@googlegroups.com
Stuart Rackham schrieb am Donnerstag, den 04. Februar 2010:

*snip*

> >>Now I could revert to shelling 'asciidoc' as before, but this would
> >>be much slower and not as flexible. Neither would it resolve the
> >>real problem viz that any other apps using the AsciiDoc API would
> >>not run on Debian.
> >I don't have a problem with asciidoc.py or asciidoc, but not both. This would
> >pollute the namespace to much. Unfortunatly the binary was named asciidoc
> >since ages in debian and many tools depend on the binaryname. So I can't just
> >rename it to asciidoc.py.
>
> With the help of a Google search I think I may have answered my own
> question -- it looks like you can use Python imp module to load
> arbitrarily named source files:
>
> $ echo 'print "Hello World!"'>mod1
>
> $ echo 'import imp
> > imp.load_source("foo","mod1")' > test.py
>
> $ python test.py
> Hello World!
>
> Hopefully this will side-step the issue, I'll post a patch when I
> get some spare time.

This are great news. Thanks for your help and sorry for the inconvenience.

Alex

Phillip Lord

unread,
Feb 4, 2010, 7:45:40 AM2/4/10
to asci...@googlegroups.com
Stuart Rackham <srac...@gmail.com> writes:
>> I don't have a problem with asciidoc.py or asciidoc, but not both. This would
>> pollute the namespace to much. Unfortunatly the binary was named asciidoc
>> since ages in debian and many tools depend on the binaryname. So I can't just
>> rename it to asciidoc.py.
>
> With the help of a Google search I think I may have answered my own question --
> it looks like you can use Python imp module to load arbitrarily named source files:
>
> $ echo 'print "Hello World!"'>mod1
>
> $ echo 'import imp
>> imp.load_source("foo","mod1")' > test.py
>
> $ python test.py
> Hello World!
>
> Hopefully this will side-step the issue, I'll post a patch when I get some
> spare time.

Ah, this looks ideal, and does seem to solve the problem nicely.
Excellent stuff!

Phil


Phillip Lord

unread,
Feb 4, 2010, 5:12:47 PM2/4/10
to asci...@googlegroups.com
Stuart Rackham <srac...@gmail.com> writes:
> With the help of a Google search I think I may have answered my own question --
> it looks like you can use Python imp module to load arbitrarily named source files:
>
> $ echo 'print "Hello World!"'>mod1
>
> $ echo 'import imp
>> imp.load_source("foo","mod1")' > test.py
>
> $ python test.py
> Hello World!
>
> Hopefully this will side-step the issue, I'll post a patch when I get some
> spare time.


Stuart

I took the liberty of making a patch myself -- a bit forward, I realise,
hope you don't mind. I've never done this with mercurial before, so
apologies if I have got it wrong.

It actually needed patching in two places, because there's a reload in
also.

As well as being a mercurial newbie, my python isn't that good either.

Cheers

Phil

change80.diff

Stuart Rackham

unread,
Feb 5, 2010, 10:36:33 PM2/5/10
to asci...@googlegroups.com
Hi Phillip

Thank you very much for the patch. I included the original code for backward
compatibility and refactored the import to a private method:

http://hg.sharesource.org/asciidoc/rev/18d442cc6fa3

I also added the new asciidocapi.py to blogpost:

http://hg.sharesource.org/blogpost/rev/55dcb4418dee

I haven't given it much in the way of testing so get back to me if there are
problems.

Cheers, Stuart

Phillip Lord

unread,
Feb 6, 2010, 1:52:05 PM2/6/10
to asci...@googlegroups.com

Stuart

This seems to work for me, at least if I merged it in correctly to my
working copy (I ended up in vim, for some reason, which I wasn't
expecting hg merge to do!).

While I am on a roll with mercurial, I've attached another patch; we
discussed this a while back, getting blogpost to read both categories
and status from file.

Cheers

Phil


read_from_file.diff

Stuart Rackham

unread,
Feb 9, 2010, 8:36:03 PM2/9/10
to asci...@googlegroups.com
Phillip Lord wrote:
[...]

> While I am on a roll with mercurial, I've attached another patch; we
> discussed this a while back, getting blogpost to read both categories
> and status from file.

Thanks for the patch. I haven't forgotten the orginal discussion
http://groups.google.com/group/asciidoc/browse_frm/thread/36ff073c79cbc20a/bc18d5604f2ec4f5
though it probably seemed like it, it was quite a long time ago.

I've been trying to get my head around it again. Just to summarise (correct me
if I'm wrong):

- The --read-categories option is an alternative to the --categories=CATEGORIES
option, it allows categories to be specified in the AsciiDoc source file.

- The --read-status option is an alternative to the --publish and --unpublish
options, it allows the publication status be specified in the AsciiDoc source file.

Both options throw an error if the AsciiDoc source does not have the requested
attribute.


Cheers, Stuart

Phillip Lord

unread,
Feb 10, 2010, 8:38:57 AM2/10/10
to asci...@googlegroups.com
Stuart Rackham <srac...@gmail.com> writes:
> Phillip Lord wrote:
> [...]
>> While I am on a roll with mercurial, I've attached another patch; we
>> discussed this a while back, getting blogpost to read both categories
>> and status from file.
>
> Thanks for the patch. I haven't forgotten the orginal discussion
> http://groups.google.com/group/asciidoc/browse_frm/thread/36ff073c79cbc20a/bc18d5604f2ec4f5
> though it probably seemed like it, it was quite a long time ago.

Don't worry, I don't want to sound like a nag, I just thought that a
patch would make the process easier.

Also, if I am practical, I'm effectively running on a fork of the
mercurial version now; versioning makes this possible, but I still run
the risk of getting conflicts.

>
> I've been trying to get my head around it again. Just to summarise (correct me
> if I'm wrong):
>
> - The --read-categories option is an alternative to the
> --categories=CATEGORIES option, it allows categories to be specified in the
> AsciiDoc source file.
>
> - The --read-status option is an alternative to the --publish and --unpublish
> options, it allows the publication status be specified in the AsciiDoc source
> file.
>
> Both options throw an error if the AsciiDoc source does not have the requested
> attribute.


Yep, that's it. In my case, I pretty much always use blogpost with the
"post" command, then let attributes sort everything else out. For me,
this works superbly.

I'd love to be able to add a "--read-tags" option as well, which does
the same as the read-categories, but as far as I can tell none of the
XML-RPC interfaces support it. Pity.

I can work around all of this, of course; I could write a driver script
that calls blogpost appropriately, but I though others would like the
functionality.

Phil

Stuart Rackham

unread,
Feb 10, 2010, 8:31:16 PM2/10/10
to asci...@googlegroups.com

OK, I've come up with a general approach to AsciiDoc attributes that I hope fits
the bill:

- Blogpost always scans AsciiDoc source files for the following blog parameters:
categories, status, title, doctype, posttype.

- The parameters are entered as AsciiDoc attribute entries. The parameter name
prefixed with 'blogpost-' forms the corresponding attribute name e.g.

:blogpost-status: published
:blogpost-categories: blogpost,AsciiDoc,Weblog client,WordPress

- An --attributes=ATTRIBUTES option can be used to enforce selected AsciiDoc
attribute entries. ATTRIBUTES is a comma-separated list of parameter names e.g.

--attributes=status,categories

- Parameter precedence is (from highest to lowest):

1. Command-line options.
2. AsciiDoc attribute entries.
3. Blogpost cache.

Diff attached.


Cheers, Stuart

blogpost-attributes.diff

Phillip Lord

unread,
Feb 11, 2010, 6:53:26 AM2/11/10
to asci...@googlegroups.com

Stuart Rackham <srac...@gmail.com> writes:
> Phillip Lord wrote:
>> Stuart Rackham <srac...@gmail.com> writes:
>> Yep, that's it. In my case, I pretty much always use blogpost with the
>> "post" command, then let attributes sort everything else out. For me,
>> this works superbly.
>
> OK, I've come up with a general approach to AsciiDoc attributes that I hope
> fits the bill:
>
> - Blogpost always scans AsciiDoc source files for the following blog
> parameters: categories, status, title, doctype, posttype.
>
> - The parameters are entered as AsciiDoc attribute entries. The parameter name
> prefixed with 'blogpost-' forms the corresponding attribute name e.g.
>
> :blogpost-status: published
> :blogpost-categories: blogpost,AsciiDoc,Weblog client,WordPress
>
> - An --attributes=ATTRIBUTES option can be used to enforce selected AsciiDoc
> attribute entries. ATTRIBUTES is a comma-separated list of parameter names
> e.g.
>
> --attributes=status,categories
>
> - Parameter precedence is (from highest to lowest):
>
> 1. Command-line options.
> 2. AsciiDoc attribute entries.
> 3. Blogpost cache.


Stuart

This sounds very sensible; I hadn't thought about included posttype in
the attributes (currently I do this by having different directories and
two makefiles, with different command lines). But this will allow
arbitrary growth of attributes if new things (such as tags) come along
without a massive bloat in the command line.

I should also be able to port all my existing blogpost source without
any problems, which is a nice side effect.

I'll try the patch out as soon as possible and get back to you! Many
thanks.

Phil

Stuart Rackham

unread,
Feb 17, 2010, 1:08:43 AM2/17/10
to asci...@googlegroups.com

The changes are now in the trunk:

http://code.google.com/p/blogpost/source/detail?r=fcc9c093e444e14cbf69cce9e5e7b12382dfdbcf


Cheers, Stuart


>
> Phil
>

Phillip Lord

unread,
Feb 25, 2010, 7:35:06 AM2/25/10
to asci...@googlegroups.com
Stuart Rackham <srac...@gmail.com> writes:
>> I'll try the patch out as soon as possible and get back to you! Many
>> thanks.
>
> The changes are now in the trunk:
>
> http://code.google.com/p/blogpost/source/detail?r=fcc9c093e444e14cbf69cce9e5e7b12382dfdbcf
>


Stuart

Thought I'd replied to this, but can't see my email anywhere. I've tried
the trunk out now with this modification and it works very well. It's an
excellent addition to blogpost.

Many thanks!

Phil

Stuart Rackham

unread,
Feb 25, 2010, 3:10:30 PM2/25/10
to asci...@googlegroups.com

Thanks for the feedback.

Cheers, Stuart


>
> Many thanks!
>
> Phil
>

Reply all
Reply to author
Forward
0 new messages