Re: [netmod] derived-from-or-self leads to circular import

Mahesh Jethanandani <mjethanandani@gmail.com> Fri, 26 August 2016 21:24 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A61812D133 for <netmod@ietfa.amsl.com>; Fri, 26 Aug 2016 14:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQHMSsTpe11U for <netmod@ietfa.amsl.com>; Fri, 26 Aug 2016 14:24:47 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE03D12D568 for <netmod@ietf.org>; Fri, 26 Aug 2016 14:24:46 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id p64so32126413pfb.1 for <netmod@ietf.org>; Fri, 26 Aug 2016 14:24:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=NPYDT+chKoO3dzSH4A9QdLWKs2qgIPE6dLuTU/haiXo=; b=WBryhdRbkH5XEpD03XhrAU+lhxK1XwMgv53g6S3536/lQC/VNe8Swz/UJ6p/4nwTMf 96eZT7IjtdLKzz2hQYzq19E41tMiq/lmTViY+Efeh176RSz3Ai329cDpxlWMc9tIILfk XnBGYtZxqUbyATgc2Q8SnDq0OD0u4Ff7lUprSDS8SjjN00AOSLx7NOWbCdLeZxUqh/nc Kc1lRnYZr1++f2nSbMMjryP6d6EpEL4U0vB+ZtOhx7HzJgwhKG9y0ZZzvexirrfmHRii dhmFT3SLxQ6r6iUpjtZ7Cwn0zIkEwioNtBYSDBbHNKjDhhWwTM16DUZr4rbUVUrZG9pW PIag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=NPYDT+chKoO3dzSH4A9QdLWKs2qgIPE6dLuTU/haiXo=; b=LzeTEwX/hgKmQ4tnkTrLm4cRF/OeHWlcKLpLYCAR7YrtK+qbJqacsKyvDMFf1jIsCg sTV9pseqJRWSqe0XRxnEgS+BKQv1MGR9af2XzE0RIbbT8VK4V1rrR8MOLeIoLULZW5YK HXBbv6FyW+HP99ySiy8tjayRReQ92M/ueJ9yfwNTJXriFhmRDC3GSd65kaBfB+3Hhyrp vMDbxczyc1Cz9008tIF9/NAa397K5DXBo0oBM8hGDaC87RCELXQJkauTf2QG1nGUd2eN jpFUCoIJ0hp5JsVrrd6UMY10dacIDzfiV1Khro0+jCUnoCMNdR9CY/IwUBsRAXTyAlva gUBQ==
X-Gm-Message-State: AE9vXwMvOiUCZ1qr80eNtPcPhM7zuVin/InQqGPGptCkNdTzforR9bkEWSRpWsGkRc9h5w==
X-Received: by 10.98.63.1 with SMTP id m1mr9729372pfa.14.1472246686538; Fri, 26 Aug 2016 14:24:46 -0700 (PDT)
Received: from ?IPv6:2001:420:30d:1254:8162:bd8c:b348:86d7? ([2001:420:30d:1254:8162:bd8c:b348:86d7]) by smtp.gmail.com with ESMTPSA id n69sm30930059pfa.77.2016.08.26.14.24.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Aug 2016 14:24:45 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CDE81190-D077-4016-8301-8080FB8A827B"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <20160826.143230.1673334253843878893.mbj@tail-f.com>
Date: Fri, 26 Aug 2016 14:24:45 -0700
Message-Id: <17D2FB35-C991-46FE-9C18-7F3EABCC282B@gmail.com>
References: <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com> <20160826122229.GA32769@elstar.local> <20160826.143230.1673334253843878893.mbj@tail-f.com>
To: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/cDzWbqGlcHy8FPErMTppWZVlxj0>
Cc: netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Aug 2016 21:24:49 -0000

Don’t we have something similar with iana-if-types importing ietf-interfaces? Not circular, but definitely odd.

The base identity of interface-type is defined in ietf-interfaces, but the interface-types are defined in iana-if-type.yang. For anyone, including openconfig-interfaces, wanting to use any of the interface-types has to not only import iana-if-types but ietf-interfaces also.

As a general rule, would it not be better to have the base identity and the different types of that identity in the same file?

> On Aug 26, 2016, at 5:32 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.de>> wrote:
>> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>> On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - BE) wrote:
>>>> 
>>>> [...]
>>>> 
>>>>> In order to correctly compile (using confdc) we also need to import
>>>>> iana-entity for the identities defined in there.  However this is leading a
>>>>> circular dependency:
>>>>> 
>>>>> 1.       Iana-entity imports ietf-entity (to 'resolve'
>>>>> entity-physical-class)
>>>>> 
>>>>> 2.       Ietf-entity imports iana-entity (to obtain the indentities defined
>>>>> in there)
>>>>> 
>>>>> One way to solve this is to move the definition of entity-physical-class
>>>>> from ietf-entity to iana-entity which would resolve the fact that
>>>>> iana-entity requires an import of ietf-entity (ietf-entity needs to import
>>>>> iana-entity anyhow, so it can also pick the typedef from the same module
>>>>> too).
>>>> 
>>>> I think moving the definition of entity-physical-class into
>>>> iana-entity makes sense.
>>> 
>>> Ok.  It feels a bit backwards to me though, but I can see the value of
>>> having the iana module self-contained.
>>> 
>> 
>> Well, it may look backwards if people want to reuse the base identity
>> but none of the IANA assigned identities - but then it might be good
>> if people at least look at IANA assigned identities. Or are there other
>> reasons why you think this may be looking 'backwards'?
> 
> I makes ietf-entity dependent on iana-entity, since the base identity
> is defined in iana-entity.
> 
> But OTOH, even if we solved that, ietf-entity is dependent on
> iana-entity b/c of the value 'sensor'.
> 
> So in this case it is probably fine, but I'm not sure about the
> general idea.
> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanandani@gmail.com