Highlighting buried treasure in Twisted

[glyf]

I've previously blogged about twisted.python.modules, but it assumes you know about another API inside Twisted, twisted.python.filepath.  Unfortunately this module is rather under-documented and under-publicized, despite being extremely useful.  Unlike a lot of Twisted, much of the code in twisted.python can be extracted and used by itself,

Comments

too much coupling

[zooko]

This kind of thing makes me sad.

There are lots of people who could benefit from twisted.python.filepath, and there are comparable packages which twisted could use in order to gain the benefit without the cost of maintaining the package (at least one of which is being considered for inclusion in the Python Standard Library), but it isn't going to happen -- non-Twisted-requiring projects aren't going to benefit from twisted.python.filepath, and Twisted isn't going to benefit from those other packages, because Twisted doesn't use good packaging technology so that it can use other people's code and other people can use its code in an easy, manageable way.

Frankly, suggesting that people could copy a few source files is the kiss of death, for the prospect of that code being re-used by other people.

Twisted is falling behind because of this. Please ponder the postscript to this page:

http://www.kieranholland.com/code/documentation/nevow-stan/

This guy says, as I interpret: Nevow is technically better, but Django is the future because it makes it easy for people to re-use components in isolation. The same could be said of many of the Twisted and Divmod offerings.

Re: too much coupling

[glyf]

there are comparable packages which twisted could use in order to gain the benefit without the cost of maintaining the package
Not true, as far as I'm aware. I believe you're talking about the many "object oriented" path abstractions for Python. Twisted uses FilePath for two main requirements, neither of which is OO nicety: security in contexts like a web server, and polymorphism to zip files. Do any of the path libraries you're talking about implement either of these requirements?Frankly, suggesting that people could copy a few source files is the kiss of death, for the prospect of that code being re-used by other people.
This is exactly the strategy that the module being considered for inclusion in Python under PEP 355 uses.Twisted doesn't use good packaging technology
Python doesn't have any good packaging technology. distutils is sparsely documented and difficult to do anything with without touching internal implementation details; setuptools is a mine-field unless your sys.path is set up exactly like PJE's. Granted, Twisted's setup.py is especially bad, but that is being worked on. If you're really concerned about it, consider addressing some of the tickets mentioned by the release automation status document on the Twisted wiki.Nevow is technically better, but Django is the future because it makes it easy for people to re-use components in isolation.
That's not the way I read it at all. From my perspective it looks like he's saying "Twisted is technically better, but Django has a much nicer website and therefore more people working to improve it." I don't think this has anything to do with packaging technology; Django is pitched at a much, much bigger audience than Twisted is, and will therefore generate more interest. Importantly, pretty much the entire audience is involved in building websites, and hence much more conversant with PR and graphic design than the Twisted audience is; I think we're lucky to be doing as well as we are on that front.

But by all means, help us deal with our release automation problems :).