On Wed, May 26, 2010 at 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 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 :)
It's impossible to predict what will be compatible with what in the future. There are problems with being too permissive in versions, but there are other problems with being too restrictive. It's really hard to troubleshoot a false restriction: Setuptools just says "unable to fulfill requirement SQLAlchemy>=0.5,<=0.6" or something like that, without telling you where the require() call is or which other packages are imposing the restriction. This is especially a pain for newbies, who don't understand enough about sys.path and the EGG-INFO files and setup.py to find the restriction and evaluate it. So I come down on the side of, don't declare an incompatibility unless you're sure it's an incompatibility. The same applies with lower versions. If Pylons requires 'Routes>=1.12', it should have a good reason for disallowing 1.11 (i.e., it would break Pylons), and not simply that Routes 1.12 was the current version when Pylons X.X was released. Because maybe the user wants to stick with Routes 1.11 because 1.12 makes some undesired changes. It's really up to the application to disallow versions it doesn't want, because a version that's fine for one application may not work for another. Also, people have both old and new applications. Old applications may need to stick with old libraries, while new applications want to use the latest. Pylons can't be both permissive and restrictive; it has to choose one or the other. Being permissive allows both cases to work. Being restrictive requires users to hack Pylons' setup.py to allow the newer version to be used -- and to reapply the hack whenever upgrading Pylons. Pylons should probably include a 'requirements' file listing versions that are known to work with the release. The docs can tell people to install this if they want to be conservative, or regular Pylons if they want the latest of everything (and the potential disadvantages of doing so). Then we should also encourage PYLONS APPLICATIONS to declare a 'requirements' file listing versions the application has been tested with. >> 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 ;) Pylons itself depends on WebHelpers. The SQLAlchemy dependency is only in the application. -- Mike Orr <[email protected]> -- 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.
