On Wed, Aug 19, 2009 at 11:54 PM, Jorge Vargas<[email protected]> wrote: > > On Mon, Aug 17, 2009 at 11:21 PM, Mike Orr<[email protected]> wrote: >> >> On Mon, Aug 17, 2009 at 4:56 PM, kochhar<[email protected]> wrote: >>> >>> Jorge Vargas wrote: >>>> On Fri, Aug 14, 2009 at 7:50 PM, kochhar<[email protected]> 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 <[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 -~----------~----~----~----~------~----~------~--~---
