On May 26, 1:05 am, artee <[email protected]> wrote: > > What's the issue with WebHelpers? The Pylons dependency is > > I don't remember details because it was a few months ago but it was > related to url_for helper and new pylons implementation (url class). > The same project, the same Pylons 0.9.7 but WebHelpers was changed > significantly. > Anyway, because Pylons consists of several external libraries
Sorry to be contrary, but I think this statement is somewhat incorrect. A typical Pylons-based projects--created via `paster create`--makes use of certain packages/libraries (by default), but Pylons itself doesn't necessarily depend on those packages--*your project* does. More below... > it would > be a good idea to add more strict version checking. > Using Pylons 0.9.7 in 2009 and 2010 should give us the same results :) > > > The same issue applies to SQLAlchemy. If you restrict SQLAlchemy to > > the 0.5 series, then applications that want to use 0.6 will have to > > I agree with you but SA is a separate package and Pylons can live > without it. > Without Webhelpers? No way ;) Not every Pylons-based app needs WebHelpers. For example, I have a web services package that renders only JSON, so there are no templates, no public files, no helpers, etc. I'm not sure whether Pylons uses WebHelpers internally (sorry, can't grep from here). If not, I'd say that the dependency should be *removed* from Pylons itself (i.e., from its setup.py) and let application developers decide whether they need it (though it could still be part of the default template when using `paster create`). The same thing is true of, for example, Routes. Pylons doesn't strictly depend on Routes (as far as I know); it depends on certain values being present in the environ. If I decide to swap Routes for something else, I don't want to be forced to download and install Routes. This could be handled with the `paster create` template, too-- the default dependencies would be injected into the new project's setup.py (right now, the template only has the Pylons dependency in its setup.py). As it is now, it seems that Pylons is using really low version numbers to make sure that if you "override" package versions in your project's setup.py, there's not a conflict. I don't know if it's the best approach or not, but so far, it hasn't caused me any problems, but I think this is mainly because I add all the Pylons-related dependencies to my setup.py. So, a proposal for Pylons 1.1 or later: remove all deps from Pylons' setup.py that are not used directly by Pylons. Add those deps instead to projects created by `paster create`. I haven't completely thought this through, so I don't no what all the ramifications might be. Thoughts? -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
