Re: Adding Pylons 0.9.7 breaks 0.9.6 projects
On Aug 14, 2009, at 9:59 PM, Jorge Vargas wrote: On Fri, Aug 14, 2009 at 7:50 PM, kochharkochhar...@gmail.com wrote: Hi all, Hi, I have a package repository which contains packages for pylons 0.9.6.1 After adding pylons 0.9.7 and it's dependent packages, my 0.9.6.1 projects stopped working. From looking at the requires.txt in pylons 0.9.6 egg it appears that pylons is specifying it's dependencies in the FooPackage = x.y.z format. Consequently, when I re-create my project environments, they get newer versions of their dependencies which are not compatible with 0.9.6.1 (Notably Routes and WebHelpers) It seems bad practice for pylons to specify it's dependencies in the FooPackage=x.y.z format; it's too easy to break something. Is there a way around this so I don't need to create separate package repositories for 0.9.6.1 and 0.9.7 I don't see this as bad format as a newer version is (in general a better less buggy version) that said they are two ways of fixing this. 1- releasing 0.9.6.2 with a setup.py that excludes the new incompatible versions 2- using something like pip and it's requirements.txt file to fix such issue. Another alternative is to install both eggs with the -m (multi- version) option of easy_install, then explicitly require whatever version the app needs as early as possible during the app's initialization (like in middleware.py, or load_environment) -- Philip Jenvey --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Adding Pylons 0.9.7 breaks 0.9.6 projects
On Mon, Aug 17, 2009 at 11:21 PM, Mike Orrsluggos...@gmail.com wrote: On Mon, Aug 17, 2009 at 4:56 PM, kochharkochhar...@gmail.com wrote: Jorge Vargas wrote: On Fri, Aug 14, 2009 at 7:50 PM, kochharkochhar...@gmail.com wrote: I have a package repository which contains packages for pylons 0.9.6.1 After adding pylons 0.9.7 and it's dependent packages, my 0.9.6.1 projects stopped working. It seems bad practice for pylons to specify it's dependencies in the FooPackage=x.y.z format; it's too easy to break something. Is there a way around this so I don't need to create separate package repositories for 0.9.6.1 and 0.9.7 I don't see this as bad format as a newer version is (in general a better less buggy version) Except when the new versions are not backwards compatible and break existing applications. Most libraries don't preserve backwards compatability indefinitely. It's fine practice to follow the latest and greatest in development but release version specify explicit dependencies to be stable in the face of changes. Then you end up with the opposite problem: people can't install a newer version of a library that may have bugfixes or new features they want or need. It's reasonable to restrict an old version of something (Pylon 0.9.6) when an incompatibility is known. But setting closed requirements for everything just makes it harder to use a later version if it is compatible. And compatibility may be different in different cases. Something may be compatible for new applications but not for existing applications. In that case it's not right to prevent everybody from using it just because it's incompatible for some people. People can adjust their application's setup.py if they want to stick to a particular version or avoid a known-bad series. It's easy to make your setup.py more restrictive than Pylons'. It's impossible to make yours less restrictive without modifying Pylons' setup.py, which means it can't be easy_installed without manual intervention. correct me if I'm wrong but didn't the OP said that python 0.9.6 doesn't works with the newer version of X and Y as in it's API incompatible? if that is the case then what you say doesn't really applies as it is broken for everyone. Just to clarify I was suggesting putting a cap on 0.9.6.* not on 0.9.7 -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Adding Pylons 0.9.7 breaks 0.9.6 projects
Jorge Vargas wrote: Of course #1 is best so I suggest you confirm which versions are broken and propose a patch. Hi, I have a patch now, but I can't find any instructions on how to submit it. The Contribution link on pylonshq.com doesn't lead anywhere and google doesn't find any useful results either. I did find the mercurial repo at http://bitbucket.org/bbangert/pylons but I couldn't get my clone command to work with the v0.9.6 tag. Could someone point me to any instructions or notes on submitting a patch? Thanks, - Shailesh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Adding Pylons 0.9.7 breaks 0.9.6 projects
On Wed, Aug 19, 2009 at 11:54 PM, Jorge Vargasjorge.var...@gmail.com wrote: On Mon, Aug 17, 2009 at 11:21 PM, Mike Orrsluggos...@gmail.com wrote: On Mon, Aug 17, 2009 at 4:56 PM, kochharkochhar...@gmail.com wrote: Jorge Vargas wrote: On Fri, Aug 14, 2009 at 7:50 PM, kochharkochhar...@gmail.com wrote: I have a package repository which contains packages for pylons 0.9.6.1 After adding pylons 0.9.7 and it's dependent packages, my 0.9.6.1 projects stopped working. It seems bad practice for pylons to specify it's dependencies in the FooPackage=x.y.z format; it's too easy to break something. Is there a way around this so I don't need to create separate package repositories for 0.9.6.1 and 0.9.7 I don't see this as bad format as a newer version is (in general a better less buggy version) Except when the new versions are not backwards compatible and break existing applications. Most libraries don't preserve backwards compatability indefinitely. It's fine practice to follow the latest and greatest in development but release version specify explicit dependencies to be stable in the face of changes. Then you end up with the opposite problem: people can't install a newer version of a library that may have bugfixes or new features they want or need. It's reasonable to restrict an old version of something (Pylon 0.9.6) when an incompatibility is known. But setting closed requirements for everything just makes it harder to use a later version if it is compatible. And compatibility may be different in different cases. Something may be compatible for new applications but not for existing applications. In that case it's not right to prevent everybody from using it just because it's incompatible for some people. People can adjust their application's setup.py if they want to stick to a particular version or avoid a known-bad series. It's easy to make your setup.py more restrictive than Pylons'. It's impossible to make yours less restrictive without modifying Pylons' setup.py, which means it can't be easy_installed without manual intervention. correct me if I'm wrong but didn't the OP said that python 0.9.6 doesn't works with the newer version of X and Y as in it's API incompatible? if that is the case then what you say doesn't really applies as it is broken for everyone. Just to clarify I was suggesting putting a cap on 0.9.6.* not on 0.9.7 Yes, he is right for a new library version that's incompatible with 0.9.6. I'm just worried about going to == or = across the board, as some people have occasionally suggested. I don't know about his patch submission problem; hopefully somebody else can answer it. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Adding Pylons 0.9.7 breaks 0.9.6 projects
kochhar wrote: I have a patch now, but I can't find any instructions on how to submit it. The Contribution link on pylonshq.com doesn't lead anywhere and google doesn't find any useful results either. I did find the mercurial repo at http://bitbucket.org/bbangert/pylons but I couldn't get my clone command to work with the v0.9.6 tag. Could someone point me to any instructions or notes on submitting a patch? Trac ticket: http://pylonshq.com/project/pylonshq/ticket/638 Bitbucket change: http://bitbucket.org/kochhar/pylons/changeset/0d1f137c784c/ - kochhar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Adding Pylons 0.9.7 breaks 0.9.6 projects
Mike Orr wrote: On Mon, Aug 17, 2009 at 4:56 PM, kochharkochhar...@gmail.com wrote: Jorge Vargas wrote: On Fri, Aug 14, 2009 at 7:50 PM, kochharkochhar...@gmail.com wrote: I have a package repository which contains packages for pylons 0.9.6.1 After adding pylons 0.9.7 and it's dependent packages, my 0.9.6.1 projects stopped working. It seems bad practice for pylons to specify it's dependencies in the FooPackage=x.y.z format; it's too easy to break something. Is there a way around this so I don't need to create separate package repositories for 0.9.6.1 and 0.9.7 I don't see this as bad format as a newer version is (in general a better less buggy version) Except when the new versions are not backwards compatible and break existing applications. Most libraries don't preserve backwards compatability indefinitely. It's fine practice to follow the latest and greatest in development but release version specify explicit dependencies to be stable in the face of changes. Then you end up with the opposite problem: people can't install a newer version of a library that may have bugfixes or new features they want or need. It's easy to make your setup.py more restrictive than Pylons'. It's impossible to make yours less restrictive without modifying Pylons' setup.py, which means it can't be easy_installed without manual intervention. I didn't know that I could do this. I'll use this method instead. Thanks, - kochhar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Adding Pylons 0.9.7 breaks 0.9.6 projects
Jorge Vargas wrote: On Fri, Aug 14, 2009 at 7:50 PM, kochharkochhar...@gmail.com wrote: I have a package repository which contains packages for pylons 0.9.6.1 After adding pylons 0.9.7 and it's dependent packages, my 0.9.6.1 projects stopped working. It seems bad practice for pylons to specify it's dependencies in the FooPackage=x.y.z format; it's too easy to break something. Is there a way around this so I don't need to create separate package repositories for 0.9.6.1 and 0.9.7 I don't see this as bad format as a newer version is (in general a better less buggy version) Except when the new versions are not backwards compatible and break existing applications. Most libraries don't preserve backwards compatability indefinitely. It's fine practice to follow the latest and greatest in development but release version specify explicit dependencies to be stable in the face of changes. that said they are two ways of fixing this. 1- releasing 0.9.6.2 with a setup.py that excludes the new incompatible versions Of course #1 is best so I suggest you confirm which versions are broken and propose a patch. Yes, I'm working on a patch. Binary searching through package dependency versions isn't much fun. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Adding Pylons 0.9.7 breaks 0.9.6 projects
On Mon, Aug 17, 2009 at 4:56 PM, kochharkochhar...@gmail.com wrote: Jorge Vargas wrote: On Fri, Aug 14, 2009 at 7:50 PM, kochharkochhar...@gmail.com wrote: I have a package repository which contains packages for pylons 0.9.6.1 After adding pylons 0.9.7 and it's dependent packages, my 0.9.6.1 projects stopped working. It seems bad practice for pylons to specify it's dependencies in the FooPackage=x.y.z format; it's too easy to break something. Is there a way around this so I don't need to create separate package repositories for 0.9.6.1 and 0.9.7 I don't see this as bad format as a newer version is (in general a better less buggy version) Except when the new versions are not backwards compatible and break existing applications. Most libraries don't preserve backwards compatability indefinitely. It's fine practice to follow the latest and greatest in development but release version specify explicit dependencies to be stable in the face of changes. Then you end up with the opposite problem: people can't install a newer version of a library that may have bugfixes or new features they want or need. It's reasonable to restrict an old version of something (Pylon 0.9.6) when an incompatibility is known. But setting closed requirements for everything just makes it harder to use a later version if it is compatible. And compatibility may be different in different cases. Something may be compatible for new applications but not for existing applications. In that case it's not right to prevent everybody from using it just because it's incompatible for some people. People can adjust their application's setup.py if they want to stick to a particular version or avoid a known-bad series. It's easy to make your setup.py more restrictive than Pylons'. It's impossible to make yours less restrictive without modifying Pylons' setup.py, which means it can't be easy_installed without manual intervention. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Adding Pylons 0.9.7 breaks 0.9.6 projects
On Fri, Aug 14, 2009 at 9:59 PM, Jorge Vargasjorge.var...@gmail.com wrote: On Fri, Aug 14, 2009 at 7:50 PM, kochharkochhar...@gmail.com wrote: Hi all, Hi, I have a package repository which contains packages for pylons 0.9.6.1 After adding pylons 0.9.7 and it's dependent packages, my 0.9.6.1 projects stopped working. From looking at the requires.txt in pylons 0.9.6 egg it appears that pylons is specifying it's dependencies in the FooPackage = x.y.z format. Consequently, when I re-create my project environments, they get newer versions of their dependencies which are not compatible with 0.9.6.1 (Notably Routes and WebHelpers) It seems bad practice for pylons to specify it's dependencies in the FooPackage=x.y.z format; it's too easy to break something. Is there a way around this so I don't need to create separate package repositories for 0.9.6.1 and 0.9.7 I don't see this as bad format as a newer version is (in general a better less buggy version) that said they are two ways of fixing this. 1- releasing 0.9.6.2 with a setup.py that excludes the new incompatible versions In the past Pylons has required the latest versions of packages but I don't know if it will be able to do so much longer. When WebHelpers 1 comes out, the Pylons dependency will have to remain at 0.6 so that people can downgrade if they're using things from the older version. Likewise, the simplejson install problems would have been easier if Pylons didn't arbitrarily exclude old versions even though they were compatible. The purpose in requiring the new versions was to make it easy to upgrade, although that doesn't seem to be a problem now because if you do a fresh install, it automatically picks the newest version even if the requirement is = an older version. Not sure if -U also upgrades dependencies though. 2- using something like pip and it's requirements.txt file to fix such issue. Does pip's requirements file override the requirements in setup.py, or does it lead to an incompatibility error if pip wants a version that setup.py excludes? -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Adding Pylons 0.9.7 breaks 0.9.6 projects
Hi all, I have a package repository which contains packages for pylons 0.9.6.1 After adding pylons 0.9.7 and it's dependent packages, my 0.9.6.1 projects stopped working. From looking at the requires.txt in pylons 0.9.6 egg it appears that pylons is specifying it's dependencies in the FooPackage = x.y.z format. Consequently, when I re-create my project environments, they get newer versions of their dependencies which are not compatible with 0.9.6.1 (Notably Routes and WebHelpers) It seems bad practice for pylons to specify it's dependencies in the FooPackage=x.y.z format; it's too easy to break something. Is there a way around this so I don't need to create separate package repositories for 0.9.6.1 and 0.9.7 Thanks, - kochhar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Adding Pylons 0.9.7 breaks 0.9.6 projects
On Fri, Aug 14, 2009 at 7:50 PM, kochharkochhar...@gmail.com wrote: Hi all, Hi, I have a package repository which contains packages for pylons 0.9.6.1 After adding pylons 0.9.7 and it's dependent packages, my 0.9.6.1 projects stopped working. From looking at the requires.txt in pylons 0.9.6 egg it appears that pylons is specifying it's dependencies in the FooPackage = x.y.z format. Consequently, when I re-create my project environments, they get newer versions of their dependencies which are not compatible with 0.9.6.1 (Notably Routes and WebHelpers) It seems bad practice for pylons to specify it's dependencies in the FooPackage=x.y.z format; it's too easy to break something. Is there a way around this so I don't need to create separate package repositories for 0.9.6.1 and 0.9.7 I don't see this as bad format as a newer version is (in general a better less buggy version) that said they are two ways of fixing this. 1- releasing 0.9.6.2 with a setup.py that excludes the new incompatible versions 2- using something like pip and it's requirements.txt file to fix such issue. Of course #1 is best so I suggest you confirm which versions are broken and propose a patch. Thanks, - kochhar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
