Donald Stufft <donald <at> stufft.io> writes: > > While the two forms are functionally equivalent, I still prefer > > multiple top level fields, as I consider it both easier to document > > and more consistent with the approach used by other packaging systems. > > > Using a kind subfield actually is harder and requires more work.
I take Nick's points regarding his preference and the reasons for it, but I'm not convinced by "harder". Having actually implemented the processing logic in distlib, it didn't seem especially hard to me. We already have more "kinds" than the other dependency systems Nick mentioned: one advantage of a single list of the kind I described is that you could in theory add additional "kinds", for example ":doc:", without much impact. Not that I'm arguing for any such addition - I'm quite aware of YAGNI. However, the fact that the single-list offers such possibilities is satisfying (as in, it feels right), and having implemented the multiple-list solution in distlib already, it just struck me that a single list would be more elegant. Leaving ORMs aside, I'm pretty sure if I was just working at the RDBMS layer, this is how I would structure the dependencies - using a single "dependency" table. It's a matter of detail as to exactly how a tool would process the single list - I'm reasonably confident that a readable/understandable and sufficiently performant implementation is achievable using a single pass over the JSON, and furthermore, worrying about multiple passes at this stage feels like premature optimisation. Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig