Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!bcyclone05.am1.xlned.com!bcyclone05.am1.xlned.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'revision': 0.05; 'sufficient': 0.05; 'dependency': 0.07; 'rename': 0.07; 'cc:addr :python-list': 0.09; 'imports': 0.09; 'subject:dependencies': 0.09; 'subject:module': 0.09; 'do,': 0.15; '(but': 0.15; '1.3.': 0.16; '1.7': 0.16; 'another?': 0.16; 'declaration': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'number?': 0.16; 'something.': 0.16; 'sorts': 0.16; 'subject:issues': 0.16; 'wrote:': 0.16; 'module,': 0.18; 'say,': 0.18; 'changes': 0.20; '2015': 0.20; 'cc:2**0': 0.20; 'cc:addr:python.org': 0.20; 'work,': 0.21; 'minor': 0.22; 'am,': 0.23; 'code,': 0.23; '(or': 0.23; 'component': 0.23; 'header:In- Reply-To:1': 0.24; 'feature': 0.24; 'chris': 0.26; 'compatible': 0.27; 'figure': 0.27; 'fri,': 0.27; 'message-id:@mail.gmail.com': 0.27; '2.0': 0.27; 'turns': 0.27; '1.3': 0.29; 'declared': 0.29; 'follows': 0.29; 'if,': 0.29; 'stated.': 0.29; 'allows': 0.30; 'code': 0.30; 'normally': 0.30; "can't": 0.32; 'common': 0.33; 'usually': 0.33; 'add': 0.34; 'received:google.com': 0.35; 'could': 0.35; 'but': 0.36; 'should': 0.36; 'created': 0.36; '(and': 0.36; 'subject:: ': 0.37; 'really': 0.37; 'expect': 0.37; 'things': 0.38; 'version': 0.38; 'drop': 0.38; 'or,': 0.38; 'end': 0.39; 'why': 0.39; 'application': 0.39; 'where': 0.40; 'some': 0.40; 'your': 0.60; 'safe': 0.63; 'natural': 0.67; 'jul': 0.72; 'chrisa': 0.84; 'solved.': 0.84; 'to:none': 0.91; 'serious': 0.97 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=hYP5rEjR70mmAPxdp4QPhz0Ma6+H1D/EzDvl+f4Qx+s=; b=qOCxdiisuN+3Sy/mRkPM6bKwGkKEP+RQ7SGPidC/g9E9O6tg8Y7pKhMVoXuFzhp40+ zg9HR/HaZmXLJGD9rn4KLn6NHrM85wPx1luj9RF6r5IcCSH0vnGcQGVpfIFD0+RMI/OI CBipby5v4AxTyZeYZO2byJX/h6QsQukGPO8S2D3w1HcLET9R1oRzbpseoDZb+4pynkAO OYkOn6y1/uK5uNo1LxGzDg67grFF9aeq33xXKEzswk2PG677vc2WXbkDAMrY3kGaXYEn 9azDJkGnVhZCTu9K3hw852x8NY21rRNoU1IrZv+T/NYo0hxM49F547HG29POyEOM+r8t Gq4Q== MIME-Version: 1.0 X-Received: by 10.50.87.74 with SMTP id v10mr71807444igz.37.1436474853729; Thu, 09 Jul 2015 13:47:33 -0700 (PDT) In-Reply-To: <87wpy96pbd.fsf@elektro.pacujo.net> References: <10ADE079-3F0F-4EA8-9312-06F7FCDB6130@free.fr> <85B68343-326C-4768-A236-3459299AD129@free.fr> <87wpy96pbd.fsf@elektro.pacujo.net> Date: Fri, 10 Jul 2015 06:47:33 +1000 Subject: Re: module dependencies issues From: Chris Angelico Cc: "python-list@python.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.20+ Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 36 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1436474856 news.xs4all.nl 2888 [2001:888:2000:d::a6]:58156 X-Complaints-To: abuse@xs4all.nl X-Received-Bytes: 5682 X-Received-Body-CRC: 2390210029 Xref: csiph.com comp.lang.python:93609 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