jacob-carlborg / orbit Goto Github PK

I think this is a great idea, but I'm getting a strong "rubygems" vibe from it and that scares me because unless there are rigourous standards in place, packages turn out like gems and are nearly impossible for distros to package. (cf. http://blog.flameeyes.eu/2011/12/21/gems-make-it-a-battle-between-the-developer-and-the-packager). This is not a fate I'm fond of dealing with, and I have zero good memories of our large-scale rvm deployment at work, so I would like to offer what assistance and advice I might so as to ensure orbit doesn't fall into a miserable state. I'm not sure where or how far you're willing to take this conversation, so for now, I'd implore you to consider this document: http://dev.gentoo.org/~ulm/pms/head/pms.html if not skim the whole thing.

I've used a lot of package managers at this point, but I am now and will remain a Gentoo user because package management is properly standardised and pleasant to deal with. It's a lot like BSD ports, if you've used that, only improved in pretty much every way possible. There are a number of ideas in there that I would love to see cribbed or strongly encourage the adoption of, but the real takeaway for now is probably that there need to be guarantees built into the system to prevent the sorts of issues Diego deals with. Thanks!

Cheers,
Wyatt

PS: "I'll probably explore the possibility of having spec and orb files written in D."
Why not use rdmd? (TDPL, pg 2)

I haven't examined Orbit in detail, but one design decision that sticks out as strange is the dependency on Ruby.

Ruby and its associated tools are a big dependency to pull in for a trivial use. Ruby isn't installed by default on any distros I know of. That reason alone is enough for someone to not choose Orbit.

In any case, there's no justification. The reasons given in the wiki are

• "it's on of the best language available to create good looking DSL's". A DSL is not what's required here, is it? It's just structured information. SSJS gets one fine with just a JSON file. Besides, these things don't really have to be "good looking," they have to get the job done.
• "When the files are written in a complete language you have great flexibility and can take full advantage of Ruby". If we must write this stuff in a complete language, then we should rely on one that's guaranteed the user already has installed. The most obvious one is D, which already has a JSON package. Failing that and wanting a scripting language, Python is the safest choice, but will at least screw over Windows users, which is not a good thing.
• "There's no need to create a parser for a new config/spec format". I definitely agree that the creation of Yet Another Plaintext Format is something to be avoided like the plague. If JSON is really unsatisfactory (and I doubt it), then there's the choice of XML for power or YAML for prettiness.