Closed michaeljones closed 10 years ago
I'll fix this blank lines bug today, thanks very much for the catch.
I hated making this format decision. This is a rusty spot in general, I'd argue not just for vex but for Python's libraries ecosystem...
I hate stdlib ConfigParser's API and find its format to also be pointlessly ad hoc and to smell old, otherwise I would have used that. That's really the wheel reinvented here more than YAML.
I've actually used Yaml heavily in the past, because I found it pleasant as a user for entering small amounts of data (it's pretty nice on the writer's side). But it has some attributes I found undesirable for this job. I wanted something really simple and limited.
First, I've found pyyaml to be surprisingly slow for cases that aren't, say, one read at the start of a long-running process like a web app, many times slower than JSON for example, WITH the C extension compiled, for non-pathological tasks. While I don't normally worry very much about how slow things are, vex is parsing vexrc at every start and I am a little conscious of not increasing that because speed figured in my original reasons for leaving virtualenvwrapper.
Second, yaml is an incredibly complex beast with a lot of internal behavior; parsing yaml emits many different types and the consuming code has to handle that, which in mature tools I've written can be as much code as just parsing a simpler format to begin with, and debugging what happened isn't always straightforward as it could be. It's kind of a dream the first day but you still have work to do on the 30th. Now many features are supported, but to use them I am telling the user to use some strange notation in the outer reaches of yaml and so on, it kills the original appeal for me.
Third, the normal way of doing yaml is pyyaml, which introduces some user-unfriendly kinks; its compile requires libyaml's headers which throws beginners working in a virtualenv for a loop. I really want to help beginners be happier with virtualenv and every additional step to climb there is unhappy-making. I see it as a big feature that you can 'pip install vex' and it will drag in virtualenv for you and you are basically set up without actually having to edit any shell rc files, which also confuses the crap out of newbies.
JSON just doesn't feel right as a human-readable config format for a shell tool (outside Node, anyway). Everything else sort of isn't used.
It's so easy to just write a simple parser which I can start out very constrained, and then loosen in the specific places which need it (like the blank lines), to ensure things don't get too crazy. It's huge for me that I can ensure the format and the parse output are only as complex as I need, given that there is nothing perfectly suited already existing the constraint is enough for me.
In addition, the meta-issue that while it is early enough days to make a breaking change, I would rather keep backward compatibility within reason, and so far I am not convinced I have enough specific reason to annoy people that much.
Thanks for such a comprehensive response. I'll be honest, I'm not used to thinking in terms of speed and ease of install. It seems like you have it well thought out. Cheers!
Saw this on HN, looks really interesting. I've been setting it up but found that the vexrc parsing seems to fail on blank lines which seems a little unforgiving.
I would also recommend switching to yaml as a well defined and readable config format but I'm sure you have your reasons.
Cheers, Michael