Opinions about Enthought Traits/TraitsUI for Python desktop development

Question

I'm looking for opinions and experiences about using Traits / TraitsUI / enaml for Python desktop development.

The documentation and the Enthought support looks promising, so I wanted to know real first-hand experiences of developers using this stack.

Update:

My main focus of interest is to migrate old several desktop database applications: CRUD / querying / reporting. Then, I'm particulary interested in the data access layer: now, I'm using PosgtreSQL and peewee (a minimalistic ORM):

• Is there any built in or side-project support for SQL databases?
• If so, is there any ORM support? (I suppose SqlAlchemy is the 'standard' here)

Zinck

Answer 1

I first started using Traits and TraitsUI to build GUI's as a postdoc researcher in Mechanical Engineering. My previous experience with building GUI's was with MATLAB's GUIDE, and I found TraitsUI to be very straightforward and easy to get started with by comparison. TraitsUI has a very linear progression of progress versus effort, and for the limited amount of GUI building I did with it, it was more than sufficient.

As a professional developer (full disclosure: I work at Enthought), my perspective has shifted somewhat. First, it is important to make the distinction between Traits (the typing, validation, notification, and dependency system) and TraitsUI (the GUI layer built into and based on Traits). I use Traits all the time, and it undergirds a lot of the code I write. Particularly for its dependency and notification utilities, I consider it to be invaluable.

It doesn't take too long, however, to start bumping into the limitations of TraitsUI for application building. As I mentioned before, TraitsUI is sufficient for small- to mid-sized applications, but it gets difficult to create more-complex layouts, and we were spending a lot of time wrestling with TraitsUI to produce larger, more involved and flexible application interfaces.

That led to the more-or-less blank-slate development of Enaml. Enaml uses a constraints-based layout system at its core and integrates with Traits. From the outset, it addresses the layout weaknesses of TraitsUI. Every one of us that has used both systems prefers Enaml, and we consider it the tool of choice for GUI-building moving forward. The level of control and flexibility to lay out GUI's is remarkable --there are some nifty demos to check out in the repo.

That said, there is a slightly (but only slightly) steeper initial learning curve since it is helpful to have a grasp of certain concepts such as MVC separation from the outset. An experienced developer would see the value in this right away, but it might be more of a hurdle for a new user with a science or engineering background. It is only a slight hurdle, though, and easily cleared. Also, while the feature set is nearly complete, there are still a few holes. There is steady progress on filling them in, but Enaml is technically still in beta.

Overall, if you are trying to decide which tool set to learn, my recommendation is to learn Enaml. It's what we are and will be using going forward.

[UPDATE - Jan 2018]

Since this answer continues to get views and generate conversations, an update on this opinion is long-since overdue, the first answer dating from late 2012. Enaml has largely been the work of one main developer. When he left Enthought in early 2013, he forked the enaml repository and started developing it in the nucleic/enaml repository. We (Enthought) decided not to develop a competing fork and introduced a thin interface library enthought/traits-enaml to provide ongoing compatibility with changes in nucleic/enaml. Around the same time, we also introduced enthought/qt_binder to provide easy access to low-level Qt widgets in the Traits/TraitsUI framework which provided much of the same kind of layout flexibility that Enaml provided.

Now Traits/TraitsUI is the stack we use for most application GUI building. We continue to maintain and develop Traits, TraitsUI, and the other libraries in the Enthought Tool Suite (Chaco, Kiva, Envisage, etc) in Python 2 and 3, and they continue to meet our needs, especially in the enthought/envisage pluggable-application framework.

My amended recommendation is if you want to build a rich-client application (not a web app, that is) in Python, I would say to learn Traits and TraitsUI.

Protocol

thanks for taking the time to elaborate your extremely detailed answer. I added more context to my original question, if you don't mind answering or pointing me to an specific Enthought forum, thanks again! – Zinck

Unfortunately, I am out of depth on the rest of your question. Let me recommend you to the Enthought-dev list ([email protected]). I'm sure you will get some more specific help there. – Protocol

@TimD I'm interested in making use of Enaml alongside Traits, but with Chaco plots too - is it possible to combine all three? – Nikolaos

It seems neither enaml nor Traits are actively developed any longer. What library would you recommend in its place? – Saucy

@Saucy Traits is definitely still under active development by Enthought staff and others. enaml is no longer under development by Enthought. Rather, its home is github.com/nucleic/enaml, last activity in June 2016, so it appears to be stagnant. – Protocol

Answer 2

Disclaimer: I work as a developer and trainer at Enthought.

To answer the secondary part of the question, there isn't any ORM or database support baked-in to Traits, so you'd have to roll your own. This is largely because Traits was developed to support scientific application development, rather than enterprise app development (but that is is why Traits does have NumPy support backed in).

There's an unfortunate awkwardness caused by the fact that most ORMs (such as SQLAlchemy, Django's ORM, and I see Peewee as well) and Traits both use declarative-style interfaces and metaclasses to make defining object structures very easy, but at the downside of not playing very nicely together. If you want to avoid an explicit bridging layer then you need to have a solid understanding of both Traits and the ORM.

If I were developing this sort of app, I'd probably end up avoiding the use of the ORM and writing directly from traits to the DBAPI layer, possibly defining some custom trait types for this purpose (eg. Property trait factories whose fget and fset execute database queries).

All of that said, and admitting to my bias in favour of Enthought's technologies, there are some tools out there which may be more suited to sitting simple CRUD UIs on top of a database. One possibility is Dabo, but there are others out there such as Camelot.

Retrench