Re: [Distutils] specifying dependencies to latest major/minor
At 03:14 PM 12/3/2010 +0100, Alan Franzoni wrote: Hello, I've got some issues with dependency specification; this seems to apply both to setuptools and distribute. Let's suppose I want to have a dependency on a certain library major.minor , because I want to depend on a certain API - which is supposed to be stable for that lib unless at least the minor changes - but I want to pick in any bugfix release they might end up with. I'd like to do something like pick up the latest 1.1 release of mylib The only way to do it seems to be this: install_requires = [ mylib=1.1, 1.1.999 ] if I use just == 1.1 , it picks 1.1.0 . If I use = 1.1 and 1.2.0, it will pick beta releases for 1.2 as well. Use =1.1,1.2dev. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] specifying dependencies
Ian Bicking wrote: Chris Withers wrote: Ian Bicking wrote: Say I have a package that represents an application. We'll call it FooBlog. I release version 1.0. It uses the Turplango web framework (1.5 at the time of release) and the Storchalmy ORM (0.4), and Turplango uses HardJSON (1.2.1). I want my version 1.0 to keep working. So, I figure I'll add the dependencies: Turplango==1.5 Storchalmy==0.4 Why? I would have suggested: Turplango=1.5,2.0 Storchalmy===0.4,0.5 Then when Turplango 1.6 comes out it'll break my code. I'm assuming that you, as a consumer of Turplango, understand the versioning structure of Turplango. Based on the above, my model assumed that 2.0 would be api-compatible with 1.x. If that's not the case, adjust the dependencies as necessary. Not could, should, in fact must. Relying on a dependency provided by library you're using is suicide. Again, I'd suggest: HardJSON =1.2.1,1.3 What does 1.3 mean? You imply there is a disciplined use of a versioning pattern, I think for each usable library, there *is* a versioning pattern. If it's extremely unstable, that *should* push users away from the library. and that every release is a guarantee that the versioning has been properly declared. This comes under stability. Shit software is shit software whether its because it contains tonnes of bugs or because it doesn't specify its dependencies properly. There isn't a common understanding of versions, ...within a project, there generally is, which is all that's required here. and it's common that conflicts are released unintentionally. Well, if people have drummed into them how important accurate version dependencies are, then this won't happen... But then a small bug fix, HardJSON 1.2.2 comes out, that fixes a security bug. Turplango releases version 1.5.1 that requires HardJSON=1.2.2. I now have have to update FooBlog to require both Turplango==1.5.1 and HardJSON==1.2.2. Not if you'd followed my advice above. OK, change that to a small bug fix comes out as HardJSON 1.3, and the same problems follow. I don't know what the nature of future releases will be. See previous comments on the versioning structure used by a library. Later on, I decide that Turplango 1.6 fixes some important bugs, and I want to try it with my app. I can install Turplango 1.6, but I can't start my app because I'll get a version conflict. Not if you'd followed my advice above. Now you've introduced an entirely different requirement -- for some reason I am supposed to have known that HardJSON 1.3 would break my code, but only Turplango 2.0 would cause a conflict. And Turplango 1.6 wouldn't You're trying to make something out of nothing here. If the version dependencies are specified in setup.py or some kind of KGS they still have to be specified correctly. If they are not, you're screwed... But if I've made other hard requirements of packages like HardJSON, I'll have to update all those too. Yes, that's true, and why I recommeded what I did. That said, if you're paranoid enough to specify the exact versions (there's nothing wrong with this ;-) ) then it should be no surprise that you need to edit them... It's not surprising, it's just very annoying. Well then, only use libraries which properly specify their version dependencies and fix those that don't and you have no problem or annoyance. Or likely sources of known conflicts, such as major version increases, which is why I suggested what I did above... You presume you can predict likely sources of known conflicts in software that doesn't exist yet. This is simply not true. Indeed, but I'm damned sure I can tell you what version ranges of *existing* software should be api compatible. Right, which is why consistency is version numbering for backwards incompatible changes is important. There is no single concept of what backward compatibility even is. There doesn't have to be one single concept, just that each library has to have its own understanding of this so that consumers of that library can express their requirements properly. You can off something that fixes my specific example, using knowledge that would not be available to you at the time when you were using the code. That doesn't really prove anything -- I could also come up with conflicts that would break any example you could provide. There's no version change so minor that it can't break anything, and there's no version change so major that you should end up with a cascading set of updates that only change dependency information just to accommodate it. Well, if you want to be this negative about it, then you can lock down versions. No-ones stopping you and current tools such as buildout support this. Personally, I just don't thinl it should be necessary... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk
[Distutils] specifying dependencies
Ian Bicking wrote: Say I have a package that represents an application. We'll call it FooBlog. I release version 1.0. It uses the Turplango web framework (1.5 at the time of release) and the Storchalmy ORM (0.4), and Turplango uses HardJSON (1.2.1). I want my version 1.0 to keep working. So, I figure I'll add the dependencies: Turplango==1.5 Storchalmy==0.4 Why? I would have suggested: Turplango=1.5,2.0 Storchalmy===0.4,0.5 Then HardJSON 2.0 is released, and Turplango only required HardJSON=1.2, so new installations start installing HardJSON 2.0. But my app happens not to be compatible with that library, and so it's broken. OK... so, I could add HardJSON==1.2.1 in my requirements. Not could, should, in fact must. Relying on a dependency provided by library you're using is suicide. Again, I'd suggest: HardJSON =1.2.1,1.3 But then a small bug fix, HardJSON 1.2.2 comes out, that fixes a security bug. Turplango releases version 1.5.1 that requires HardJSON=1.2.2. I now have have to update FooBlog to require both Turplango==1.5.1 and HardJSON==1.2.2. Not if you'd followed my advice above. Later on, I decide that Turplango 1.6 fixes some important bugs, and I want to try it with my app. I can install Turplango 1.6, but I can't start my app because I'll get a version conflict. Not if you'd followed my advice above. So to even experiment with a new version of the app, I have to check out FooBlog, update setup.py, reinstall (setup.py develop) the package, and then I can start using it. Right, you're developing FooBlog by changing the software it uses, so it seems natural enough to have to edit FooBlog code. You don't have to check those edits into your SCM ;-) But if I've made other hard requirements of packages like HardJSON, I'll have to update all those too. Yes, that's true, and why I recommeded what I did. That said, if you're paranoid enough to specify the exact versions (there's nothing wrong with this ;-) ) then it should be no surprise that you need to edit them... more than 3 libraries involved. I now think it is best to only use version requirements to express known conflicts. Or likely sources of known conflicts, such as major version increases, which is why I suggested what I did above... For future versions of packages you can't really know if they will cause conflicts until they are released. Right, which is why consistency is version numbering for backwards incompatible changes is important. Myself, I stick pretty rigidly to: x.y.z: z = no api change y = new apis added x = old apis changed or removed cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] specifying dependencies
Chris Withers wrote: Ian Bicking wrote: Say I have a package that represents an application. We'll call it FooBlog. I release version 1.0. It uses the Turplango web framework (1.5 at the time of release) and the Storchalmy ORM (0.4), and Turplango uses HardJSON (1.2.1). I want my version 1.0 to keep working. So, I figure I'll add the dependencies: Turplango==1.5 Storchalmy==0.4 Why? I would have suggested: Turplango=1.5,2.0 Storchalmy===0.4,0.5 Then when Turplango 1.6 comes out it'll break my code. Then HardJSON 2.0 is released, and Turplango only required HardJSON=1.2, so new installations start installing HardJSON 2.0. But my app happens not to be compatible with that library, and so it's broken. OK... so, I could add HardJSON==1.2.1 in my requirements. Not could, should, in fact must. Relying on a dependency provided by library you're using is suicide. Again, I'd suggest: HardJSON =1.2.1,1.3 What does 1.3 mean? You imply there is a disciplined use of a versioning pattern, and that every release is a guarantee that the versioning has been properly declared. There isn't a common understanding of versions, and it's common that conflicts are released unintentionally. But then a small bug fix, HardJSON 1.2.2 comes out, that fixes a security bug. Turplango releases version 1.5.1 that requires HardJSON=1.2.2. I now have have to update FooBlog to require both Turplango==1.5.1 and HardJSON==1.2.2. Not if you'd followed my advice above. OK, change that to a small bug fix comes out as HardJSON 1.3, and the same problems follow. I don't know what the nature of future releases will be. Later on, I decide that Turplango 1.6 fixes some important bugs, and I want to try it with my app. I can install Turplango 1.6, but I can't start my app because I'll get a version conflict. Not if you'd followed my advice above. Now you've introduced an entirely different requirement -- for some reason I am supposed to have known that HardJSON 1.3 would break my code, but only Turplango 2.0 would cause a conflict. And Turplango 1.6 wouldn't So to even experiment with a new version of the app, I have to check out FooBlog, update setup.py, reinstall (setup.py develop) the package, and then I can start using it. Right, you're developing FooBlog by changing the software it uses, so it seems natural enough to have to edit FooBlog code. You don't have to check those edits into your SCM ;-) But if I've made other hard requirements of packages like HardJSON, I'll have to update all those too. Yes, that's true, and why I recommeded what I did. That said, if you're paranoid enough to specify the exact versions (there's nothing wrong with this ;-) ) then it should be no surprise that you need to edit them... It's not surprising, it's just very annoying. more than 3 libraries involved. I now think it is best to only use version requirements to express known conflicts. Or likely sources of known conflicts, such as major version increases, which is why I suggested what I did above... You presume you can predict likely sources of known conflicts in software that doesn't exist yet. This is simply not true. For future versions of packages you can't really know if they will cause conflicts until they are released. Right, which is why consistency is version numbering for backwards incompatible changes is important. There is no single concept of what backward compatibility even is. You can off something that fixes my specific example, using knowledge that would not be available to you at the time when you were using the code. That doesn't really prove anything -- I could also come up with conflicts that would break any example you could provide. There's no version change so minor that it can't break anything, and there's no version change so major that you should end up with a cascading set of updates that only change dependency information just to accommodate it. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
