-
Notifications
You must be signed in to change notification settings - Fork 455
list packages rather than repos #35
Conversation
Hey @davecheney and @mreiferson, could I ask for a Basically this gives a more tightly focused set of dependency Do you like this change? Or prefer the current way? |
As an example, before this change, importing package
And that entire repo would be copied, including all its packages: With this patch, you get two entries:
and only those two directories, aws and sqs, are copied. |
I like the higher granularity and more explicit references to what you're actually importing and depending on. I don't mind the "overhead" in the manifest at all. Do you think theres a possibility that the duplication could be construed as implying that those two dependent packages could be pinned to different hashes? Should this be an explicit error condition if they diverge? Even more radical, should the manifest (for each dependent repo) record the root, pinned hash, and an array of dependent import paths instead? Your example above becomes: {
"RepoRoot": "github.com/crowdmob/goamz",
"Rev": "9bee4d46f8a986ae73c9c05e7359e940f9ffa80c",
"ImportPaths": [
"github.com/crowdmob/goamz/aws",
"github.com/crowdmob/goamz/sqs"
]
} Does this make it more obvious that there is a single repo that we depend on but we only import the specified subset of packages? I'm not sure I like it but it's food for thought. Relatedly, I'm curious to hear your thoughts on "versioning" of I don't want to derail this issue with the versioning conversation though, so perhaps we should open a separate issue for that discussion, I'm sure there are lots of opinions :) |
Interesting point about the commit ids getting out of sync. The possible implication that they might correctly diverge I did think about putting a list of import paths inside the I want it to be at least within the realm of possibility to |
Agreed, 👍 |
This small edit is a significant conceptual change. Instead of listing one entry per dependency repo, we list one entry per disjoint import path tree. This means we can list the same repo more than once in the manifest, but copy less code into the local workspace. This happens when a repo has several packages, not all of which are dependencies. For example, if the project depends on packages A and B in repo R, we now list both R/A and R/B, even though they're in the same repo. However, if the project depends on two packages P and P/Q, we still list only P.
This small edit is a significant conceptual change.
Instead of listing one entry per dependency repo,
we list one entry per disjoint import path tree.
This means we can list the same repo more than once
in the manifest, but copy less code into the local
workspace. This happens when a repo has several
packages, not all of which are dependencies.
For example, if the project depends on packages A
and B in repo R, we now list both R/A and R/B, even
though they're in the same repo. However, if the
project depends on two packages P and P/Q, we still
list only P.