In a recent e-mail a fellow programmer who is also looking at Pylons for web application development raised the following question:
Paraphrased:
Pylons appears to have many dependencies. [list omitted] What happens if any of the packages Pylons depends on stops being developed?
A damn good question. This question has to be in the back of every developers mind irrespective of which tool set they work with and affects open source as well as closed source developers alike.
Admittedly my response (inset) was rushed and written in the wee small hours so I’ll try to clarify further below.
Hello [omitted],
Yes you are correct there are many requirements when developing web apps in Pylons. The minimum you will require is Paste and Myghty. PasteScript and PastDeploy are development time tools. Assuming you want to use javascript you would also add RailsHelpers, simplejson, prototype and possibly scriptaculous. If you use the postgres database you then add postgresql, psycopg2 and SQLAlchemy to the list. And it goes on.
I’m not sure what to advise as this is the case with any web framework. Even if you designed your own using WSGI you would be importing standard Python library code which will also change over time. The same issues exist with commercial frameworks and it’s even worse. If the proprietor goes out of business you don’t even have the source code to fall back on.
If we look back at the twisted/Nevow/Newfox stack we have the same issues. At present NewFox is stalled waiting for Nevow to be refactored while Nevow is being run against the current and no longer supported twisted 1 framework. When twisted 2 comes out it starts all over again.
The simple answer is that no matter which language and framework you use there will be dependencies. The upside of the this is that you get them all with source code.
If you look at alternative server side languages like PHP, .NET, Coldfusion, TuboGears, etc the same problems in longevity arise and this too worries me. This trend has been getting worse over the last few years rather than better.
What are your thoughts?
As you can see, my response, wouldn’t have gone a long way to allay his concerns.
After re-reading my response I know I’ve left quite a lot out and it may not make much sense to the casual reader as there have been dozens of exchanges between us over the last few years.
Our individual projects are targeted at totally different audiences yet the underlying requirements are very similar.
We are both developing Intranet applications based on Web2.0 technologies. In other words users interact with our applications via a web browser. All the logic and application software are on a central server or in his case several servers offering different resources and data to a central application server.
There are roughly 30 individual libraries or packages we are integrating into our respective applications. Some of these have reached a stable state being at version 1.0 or greater whilst others are still in beta. Packages we are using are maintained in various ways. Some are are complete packages available as Python .egg files, others are downloadable from cvs or subversion repositories whilst others are just source downloads in .tgz files. Keeping all this under control is and will remain a constant chore for the foreseeable future. Talk about shifting sands.
Where does this all lead?
My major concerns are maintainability and software lifespan. Are the days of long lived application software gone? How do we manage software longevity when the underlying support systems and codebase are constantly in flux?
I haven’t got the answers and I’m pretty sure no one else does either – at least not yet.
As I said to my colleague – What are your thoughts?
