Near future of ayrton
It might look like ayrton
's development has stalled. First, yes, a little. Last
week I barely put any time on it. Second, development will be less release centered,
and only because I have three things in mind that are very interesing to me that
I want to implement, and it seems that more or less I will be doing them on a «I
want to hack on this right now» basis.
One is to replace sh
. So far I have been tiptoeing around it to make output go
to the terminal by default, which forces the intoroduction of Capture
, and to
not raise an exception if the command fails. But recently I tried to make an
ayrton
script to more or less automatize releases and I found out that sh
really messes with the subprocess' view of the terminal. In short, editors are
not usable if they're launched from sh
. I could not say that this is the last
straw; I still think that sh
is very good at what it does, but this definetely
is like a sequoia trunk after a few straws. This is called
issue #15.
Another is to try to make several changes on the way output is captured, piped and
redirected. I find this thing of messing with _out
too annoying. Piping could
be handled by |
, but currently is not possible to do it. Redirections could be
handled with >
, but as long as I don't have |
, it doesn't make much sense.
I'm already playing with checking the AST produced by the source, because I'm
trying to minimize the situations in which unknown names are resolved into
executables, and these things also require AST handling, so it should be more or
less easy to achieve.
There is another, more ambitious thing. So far I've been using Python3's syntax,
but this imposes some restrictions. I like sh
's keyword
arguments, but the syntax doesn't
allow you to put positional arguments after keyword arguments, like:
rsync (archive=True, src, dst)
So the goal is to use another parser. As this is the only modification in mind, it only makes sense to take Python3's parser, modify what I want, and ship with that. But the question is, where is the parser code?
The answer is not simple, but at least exists besides, the source code. I mean,
I tried to untangle how this works, but as Eli Bendersky
shows in this post,
it is not a simple thing. Luckily, what I plan to change is not implemented in
the parser itself, but in the syntax checker, which is implemented in the file
ast.c
. So, by simply copying that one and ast.py
, modifying the latter so it
uses my modified syntax checker, and modifying the setup.py
file, I should be
done. Let's see how it goes...