Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #93600 > unrolled thread

Re: module dependencies issues

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: module dependencies issues Chris Angelico <rosuav@gmail.com> - 2015-07-10 05:59 +1000
    Re: module dependencies issues Marko Rauhamaa <marko@pacujo.net> - 2015-07-09 23:36 +0300
      Re: module dependencies issues Chris Angelico <rosuav@gmail.com> - 2015-07-10 06:47 +1000
        Re: module dependencies issues Marko Rauhamaa <marko@pacujo.net> - 2015-07-10 00:11 +0300
          Re: module dependencies issues Chris Angelico <rosuav@gmail.com> - 2015-07-10 07:20 +1000
            Re: module dependencies issues Marko Rauhamaa <marko@pacujo.net> - 2015-07-10 00:33 +0300
              Re: module dependencies issues Chris Angelico <rosuav@gmail.com> - 2015-07-10 07:45 +1000
                Re: module dependencies issues Marko Rauhamaa <marko@pacujo.net> - 2015-07-10 03:04 +0300
                  Re: module dependencies issues Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-10 01:24 +0100

#93600 — Re: module dependencies issues

On Fri, Jul 10, 2015 at 5:55 AM, Cyril Scetbon <cyril.scetbon@free.fr> 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

[toc] | [next] | [standalone]

#93606

Chris Angelico <rosuav@gmail.com>:

> 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

[toc] | [prev] | [next] | [standalone]

#93609

On Fri, Jul 10, 2015 at 6:36 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> 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

[toc] | [prev] | [next] | [standalone]

#93610

Chris Angelico <rosuav@gmail.com>:

> 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

[toc] | [prev] | [next] | [standalone]

#93611

On Fri, Jul 10, 2015 at 7:11 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> 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

[toc] | [prev] | [next] | [standalone]

#93612

Chris Angelico <rosuav@gmail.com>:
> On Fri, Jul 10, 2015 at 7:11 AM, Marko Rauhamaa <marko@pacujo.net> 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

[toc] | [prev] | [next] | [standalone]

#93613

On Fri, Jul 10, 2015 at 7:33 AM, Marko Rauhamaa <marko@pacujo.net> 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

[toc] | [prev] | [next] | [standalone]

#93616

Chris Angelico <rosuav@gmail.com>:

> 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

[toc] | [prev] | [next] | [standalone]

#93619

On 10/07/2015 01:04, Marko Rauhamaa wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web