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...