Re: module dependencies issues
On 10/07/2015 01:04, Marko Rauhamaa wrote: Chris Angelico : Your descriptions conflict. A safe binary replacement usually cannot even add new features, in case this breaks something. New functions in C libraries do not cause runtime breakage. It's good to know that there's never been a crash in the entire history of the C programming language due to a bug in a new function causing runtime breakage. It just proves the point that I've made in the past, that programmers using statically typed languages are far smarter than those using dynamically typed languages. The former just compile their code by lunchtime and then head to the pub, while the latter have to stay in the office all afternoon testing. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: module dependencies issues
Chris Angelico : > Your descriptions conflict. A safe binary replacement usually cannot > even add new features, in case this breaks something. Linus Torvalds is adamant about maintaining ABI compatibility across Linux versions. That hasn't prevented him from accepting numerous new system calls. New functions in C libraries do not cause runtime breakage. > Consider what happens when Python creates a new keyword; it's a new > feature, old functionality hasn't been broken, but if that word had > been used anywhere as an identifier, it's now broken. You are right about adding keywords; they break backward-compatibility (except in Perl, where keywords and names are in different namespaces, or Scheme, which doesn't have keywords). > There is NO CHANGE which is perfectly backward-compatible. That statement is untrue in theory, and even more untrue in practice. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: module dependencies issues
On Fri, Jul 10, 2015 at 7:33 AM, Marko Rauhamaa wrote: >> And just how compatible does it have to be to get a tick? > > It must be a safe binary replacement of the earlier version. Bug fixes > and new features are ok, but none of the old functionality can be > obsoleted. Your descriptions conflict. A safe binary replacement usually cannot even add new features, in case this breaks something. Consider what happens when Python creates a new keyword; it's a new feature, old functionality hasn't been broken, but if that word had been used anywhere as an identifier, it's now broken. Even something as simple as updating to the latest Unicode release can change what means what, and won't necessarily be backward-compatible (eg when a character's classes are changed, the places where that character is legal may also change). There is NO CHANGE which is perfectly backward-compatible. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: module dependencies issues
Chris Angelico : > On Fri, Jul 10, 2015 at 7:11 AM, Marko Rauhamaa wrote: >> Whoever creates B-1.1 ought to make it backward-compatible, but he >> should also say so. The majority of developers are careless about >> backward-compatibility; having the component system make wishful >> assumptions will lead to catastrophic consequences. > > I strongly disagree. All your idea would do is create a massive > compatibility matrix, which would itself become utterly > unmaintainable. Well, it's working and very much maintainable. > It's all very well to ask for a declaration that 1.1 is compatible > with 1.0, but what happens when you add in 1.2 and 1.3, and then add > some point releases on all of them? The compatibility statement accepts ranges and can be open-ended. > And just how compatible does it have to be to get a tick? It must be a safe binary replacement of the earlier version. Bug fixes and new features are ok, but none of the old functionality can be obsoleted. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: module dependencies issues
On Fri, Jul 10, 2015 at 7:11 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> In general, I would expect that B 1.1 is backward-compatible with B >> 1.0, unless otherwise stated. Why must it be declared in any way other >> than the version number? > > To make it explicit. The generic component system shouldn't impose > (m)any assumptions on version numbering. Version numbers can contain > digits, punctuation, letters. Comparisons should be done the way "ls > -v" and "sort -V" do it. > > Whoever creates B-1.1 ought to make it backward-compatible, but he > should also say so. The majority of developers are careless about > backward-compatibility; having the component system make wishful > assumptions will lead to catastrophic consequences. I strongly disagree. All your idea would do is create a massive compatibility matrix, which would itself become utterly unmaintainable. It's all very well to ask for a declaration that 1.1 is compatible with 1.0, but what happens when you add in 1.2 and 1.3, and then add some point releases on all of them? Python 2.7 is up to 2.7.10; does every one of them need to declare backward compatibility with every other, and with every point release of 2.6, and 2.5, and how far back do we go? And just how compatible does it have to be to get a tick? EVERY change can break someone's workflow - XKCD 1172 comes to mind - so does that mean that a single bugfix prevents the compatibility mark? No. Version numbers exist to provide a granularity to the compatibility concerns. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: module dependencies issues
Chris Angelico : > In general, I would expect that B 1.1 is backward-compatible with B > 1.0, unless otherwise stated. Why must it be declared in any way other > than the version number? To make it explicit. The generic component system shouldn't impose (m)any assumptions on version numbering. Version numbers can contain digits, punctuation, letters. Comparisons should be done the way "ls -v" and "sort -V" do it. Whoever creates B-1.1 ought to make it backward-compatible, but he should also say so. The majority of developers are careless about backward-compatibility; having the component system make wishful assumptions will lead to catastrophic consequences. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: module dependencies issues
On Fri, Jul 10, 2015 at 6:36 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> How do you expect the end result to work? Will it be that your code >> imports one version of a module, but other code imports another? You >> would have to rename one of them or something. > > At work, we have created an analogous component system that has solved > this issue the way I think it should be solved. > > Component B ver 1.1 must declare (ABI) backward-compatibility with B ver > 1.0. That allows the component system to resolve such natural dependency > discrepancies in a safe manner. > > The application (or component) C, which was created at B ver 1.0 time, > can't depend on >= B-1.0 because C has no way of knowing if, say, B-2.0 > will be backward-compatible with B-1.0. The compatibility declaration > belongs to B. Or, B could simply declare that it follows the common versioning pattern of Major.Minor.Revision, where Revision changes don't add features or in any way break compatibility (or if they do, it's a bug), Minor changes add features without normally breaking backward compatibility in any serious way, and Major chances might break all sorts of things (but usually won't). Then, depending on B >= 1.3 < 2.0 is sufficient if you require a feature that came in with 1.3. If it turns out that 1.7 breaks your code, you either change your code to be compatible with 1.7 (and either drop support for 1.3 or figure out some way of supporting both), or declare B >= 1.3 < 1.7. It's really not difficult. This is what version numbers are for. In general, I would expect that B 1.1 is backward-compatible with B 1.0, unless otherwise stated. Why must it be declared in any way other than the version number? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: module dependencies issues
Chris Angelico : > How do you expect the end result to work? Will it be that your code > imports one version of a module, but other code imports another? You > would have to rename one of them or something. At work, we have created an analogous component system that has solved this issue the way I think it should be solved. Component B ver 1.1 must declare (ABI) backward-compatibility with B ver 1.0. That allows the component system to resolve such natural dependency discrepancies in a safe manner. The application (or component) C, which was created at B ver 1.0 time, can't depend on >= B-1.0 because C has no way of knowing if, say, B-2.0 will be backward-compatible with B-1.0. The compatibility declaration belongs to B. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: module dependencies issues
On Fri, Jul 10, 2015 at 5:55 AM, Cyril Scetbon wrote: > It's just a sample. I'd like to get a general answer. So think about the > worst case. (Please don't top-post on this list.) The worst case is virtually impossible to handle. Somewhere along the way, you need to say "import B" and Python has to go and fetch up some module. There has to be exactly one module under that name. This isn't a packaging issue, it's an issue with how Python references modules: there can be only one! Highlander: The System Modules Dictionary! How do you expect the end result to work? Will it be that your code imports one version of a module, but other code imports another? You would have to rename one of them or something. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: module dependencies issues
It's just a sample. I'd like to get a general answer. So think about the worst case. > On Jul 9, 2015, at 21:50, Chris Angelico wrote: > > On Fri, Jul 10, 2015 at 5:08 AM, Cyril Scetbon wrote: >> Forcing my-module to use B=1.1 fixes the issue. However it's just a sample >> and my code is using a lot of modules that use other shared modules too. Is >> there a way to let dependencies use their own version of the modules they >> need while the current use another version ? >> Currently every time we need to upgrade one module, we need to make sure >> dependencies use this new version too :( >> > > First off, does your module *really* need B==1.0, or can it handle > B>=1.0? If it can, the solution is easy. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: module dependencies issues
On Fri, Jul 10, 2015 at 5:08 AM, Cyril Scetbon wrote: > Forcing my-module to use B=1.1 fixes the issue. However it's just a sample > and my code is using a lot of modules that use other shared modules too. Is > there a way to let dependencies use their own version of the modules they > need while the current use another version ? > Currently every time we need to upgrade one module, we need to make sure > dependencies use this new version too :( > First off, does your module *really* need B==1.0, or can it handle B>=1.0? If it can, the solution is easy. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
module dependencies issues
Hi, I use pip to install modules and setuptools to install dependencies, and generate a console_script using the entry_point parameter of setup. Here is the issue : my current sources depend on modules, let's say A=1.0, B=1.0, C=2.0. And C depends on B=1.1 I have no problem with using pip to install dependencies. However setuptools complain that 2 versions are conflicting : Installed /private/tmp/test/my-module Processing dependencies for my-module==0.0.1 error: B 1.0 is installed but B==1.1 is required by set(['C']) Forcing my-module to use B=1.1 fixes the issue. However it's just a sample and my code is using a lot of modules that use other shared modules too. Is there a way to let dependencies use their own version of the modules they need while the current use another version ? Currently every time we need to upgrade one module, we need to make sure dependencies use this new version too :( Thanks -- Cyril SCETBON -- https://mail.python.org/mailman/listinfo/python-list
