The title says it all… right? Ha.. no. I came across this statement from another developer who had ‘evaluated’ Cement recently. Cement was being evaluated by some of the Open Stack developers for a unified CLI. In quote:
Dean and I had several conversations after the session about how to implement the plugin loading. We both reviewed cement2, a library identified by some of the Quantum developers, and found it unsuitable (I categorized it as the unholy love child of a Zope developer and a Java developer, but that may be a bit harsh).
Whats funny is, I’ve only tried Java once (and hated it), and though I evaluated Zope Interface, I spent the extra time writing my own interface system that would provide a simpler way of defining interfaces into the framework. It definitely has similaries to Zope, but other than a brief introduction… I’ve not used Zope very much at all. I’m really not exactly sure what lead to this characterization, but if anything.. it makes for a good title.
Honestly, it’s perfectly OK if somebody doesn’t care to use something I created. My number one audience is myself, and if nobody else likes what I do… that’s fine. It’s still worth every bit of time and code I’ve put into it. If someone thinks they can do it better I encourage them to do that. Its not hard right, just hack up a wrapper around argparse, and your set right? Right.
What I do find slightly annoying, and probably the only reason I’m saying anything here about it, is that this guy didn’t even take the time to ping me about the project at all. They didn’t ask, “Is it possible to do X”, or “What would you think about adding/changing/expanding X”. I’m always open to feedback, and working in requests from the community. In general, if someone finds an issue or has a request… I almost always drop everything and start working on it as soon as possible. I personally feel that Cement is the perfect fit for a large project like a Unified CLI due to its capabilities for extensions, plugins, and the fact that you can replace every single one of the built-in framework handlers with your own custom handler. If you don’t like the default Argument handler, then write your own and plug it into the application meta. Not happy with the default logger? Create your own. I’ve worked very hard to make that process dead simple. I would have loved Open Stack to embrace Cement for its Unified CLI, but I hope they do alright with their other choice. For anyone interested, the other project is called Cliff and is
written, I mean being written, by the very talented and perhaps slightly brash, Doug Hellman. I have no doubt that Cliff will continue to expand and begin to gain many of the features that Cement already provides. By that time I’ll hopefully be working on Cement 3.
I’m happy to announce the release of Cement 2.0.0. This isn’t just the next incremental version, but rather the culmination of nearly an entire year of redesign, recoding, and redeveloping an already successful framework.
Just short of a year ago, I took the lessons I learned writing Cement version zero and decided to completely re-write the framework from scratch. There were plenty of things done right in Cement zero, but there were also far too many things that I knew I could have done better. I decided to skip the 1.0.0 milestone and jump straight ahead for 2.0.0 based on the fact that I was only re-using less than 5% of existing code. The 0.8.x branch had been stable for a long time and I figure in the near future I will grace it as 1.0.0 and let it die with zero bugfix releases. But honestly, I don’t want anyone using Cement less than 2.0.0.
This release finalizes a number of minor design/interface/incompatible changes that I had been wanting to make, and needed to make before calling it ‘stable’. The truth is, other than cosmetics, the 2.x code base has been pretty solid for several months. With this release however, I am comfortable saying that I have no intentions to break it just to sneak in some functionality here or there. The 2.0.x branch has a long life ahead of it, and I look forward to the next stage in its development. My plans moving forward are:
- Audit and refactor code using pyLint
- Improve detailed unit testing
- Improve performance (profiling)
- Improve the documentation further
- Improve existing (external) extensions
- Add more (external) extensions
I hope that anyone coming to the project for the first time, or in a long time, will immediately recognize the amount of time and effort I’ve put into this code base to make it as stable, efficient, and user friendly as possible. With 100% test coverage, and exhaustive documentation, the Cement CLI Application Framework is ready for primetime use. Be it a quick script, or a full blown enterprise class application, I hope that Cement will clearly be the framework of choice for all your CLI application needs. If its not, you probably haven’t spent enough time in the documentation to see that, even if it isn’t exactly what you need… it provides the interfaces for customizing everything from logging down to config file parsing and all the bits in between.
Good luck my friends… and be sure to let me know how you’re using Cement out in the world.