
| > Meta-data that describes the package | ... | > - Dependencies, expressed as a set of triples | > (package identifier, version range, grafting location) | | This raises an issue. | | Someone releases package foo. I release a package bar that uses foo, | where foo is grafted at A.B.Foo. Someone else wants to use bar, but they | have foo grafted at C.D.Foo, because they also have a completely | unrelated otherfoo grafted at A.B.Foo. Does their use of bar force foo | to be grafted at the same place I grafted it at? No, it doesn't, and that should be made clearer in the proposal. Suppose package P imports packages Q, R. Then the grafting locations for Q,R specified in P's meta-data are only needed to make sense of the *source code* of P. to compile P from source you must graft Q, R at the specified places. But, having compiled it (or having downloaded a compiled version) it's not necessary to even know of where P expects Q and R to show up. For an interpreter like Hugs, matters are a bit more complicated, I guess. When loading a module M from P, Hugs would have to remember where Q and R show up in the module hierarchy. Yet that seems an inevitable consequence of not fixing a single global location for every module at the moment of its birth. Simon
participants (1)
-
Simon Peyton-Jones