Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

Standardize the importers #1100

Merged
merged 9 commits into from
Sep 9, 2017

Conversation

carolynvs
Copy link
Collaborator

@carolynvs carolynvs commented Aug 30, 2017

What does this do / why do we need it?

Each importer has slightly different behavior, and currently anyone who wants to contribute an importer needs to have some pretty significant dep knowledge (or I need to really be on my game during the code review!).

This makes it so that importers are only responsible for discovering and parsing config files. They then provide 3 pieces of information to a common function which handles the rest of the import logic: import path, text which possibly contains lock info, text which possibly contains constraint info. (Some tools know about ignores and are still responsible for adding those too).

The new base importer handles

  • Consolidating multiple imports for the same project, or sub-projects.
  • Figuring out what is in the lock and constraint hints, for example a branch, semver, tag, range constraint, revision or unusable text.
  • Adding constraints and locked projects to the manifest and lock.
  • Conditionally defaulting a constraint based on the lock information. This is something that some importers need (because they only track revisions). Also supporting external config during dep ensure, will require turning off the "constraint guessing".

I have also completely redone the tests against a single repository that contains all the testdata necessary for the import scenarios (github.com/carolynvs/deptest-importers). The tests now run in parallel too! 🎉

Apologies for the big PR! Unfortunately, we've gotten to where we are now thanks to piecemeal, incremental implementations and I want to make sure this works as a whole before anything lands in master.

What should your reviewer look out for in this PR?

I'd like extra eyes on the import rules (see the inline doc on baseImporter.importProjects for the rules).

Do you need help or clarification on anything?

Nope

Which issue(s) does this PR fix?

Fixes #939

Notes:

  • When this is complete, I will follow up with the pending importer PRs: add Gomfile importer #746, Add importer for govendor #815, and gb project importer #818.
  • I think baseImporter.importProjects is ripe for concurrency. I didn't want to tackle that on top of everything else though, as there were enough big changes in that same area in this PR. But it's on my radar after this PR merges and looks stable.
  • After this, I'm going to tackle the importer harness tests.

@carolynvs carolynvs requested a review from sdboyer as a code owner August 30, 2017 22:51
@carolynvs carolynvs requested a review from darkowlzz August 30, 2017 22:52
@carolynvs carolynvs force-pushed the standarized-importer-pattern branch 2 times, most recently from 834e8e6 to 331c6fb Compare August 30, 2017 23:39
}
}

// isVersion determines if the specified value is a tag (plain or semver).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isTag

return orderedProjects, nil
}

// importProject loads imported projects into the manifest and lock.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

importPackages loads imported packages ?

The importers are now only responsible for reading config files and
feeding unvalidated lock and constraint hints into importPackages.
* Don’t throw away a locked version match due to a conflicting
  constraint unless there is another match that _does_ match
* Ignore pinned constraints
* Ignore conflicting constraints
github.com/carolynvs/deptest-importers contains the entire matrix of
testdata needed by the importers
* The setup and validation for all the importer testcases are the same,
  they just need to handle calling the importer properly.
* Flag importer tests to run in parallel now that they've been cleaned up.
@carolynvs carolynvs force-pushed the standarized-importer-pattern branch from fc84b3e to 1407196 Compare September 5, 2017 14:28
@carolynvs carolynvs changed the title [WIP]Standardize the importers Standardize the importers Sep 5, 2017
@carolynvs
Copy link
Collaborator Author

This is finally ready for review! 🎉

I would really love to get this in by the end of the week. So if I don't hear anyone screaming at me to not merge by then.... 😇

case gps.IsRevision:
return true
case gps.IsVersion:
return true
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit:

case gps.IsRevision, gps.IsVersion:
 return true

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I knew there was a better way of doing that! ❤️

return false
}

func (i *baseImporter) testConstraint(c gps.Constraint, v gps.Version) bool {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment?

@carolynvs
Copy link
Collaborator Author

I can't tell if the new bolt tests are flaky or if I managed to break them somehow?
https://travis-ci.org/golang/dep/jobs/272136148#L476-L480

Signal received: waiting for 1 ops to complete...

--- FAIL: TestBoltCacheTimeout (0.82s)
	source_cache_bolt_test.go:170: expected no cached versions, but got:
			[]gps.PairedVersion{gps.versionPair{v:gps.branchVersion{name:"originalbranch", isDefault:false}, r:"rev1"}, gps.versionPair{v:"originalver", r:"rev2"}}
FAIL

@jmank88
Copy link
Collaborator

jmank88 commented Sep 5, 2017

I can't tell if the new bolt tests are flaky or if I managed to break them somehow?

Seems flaky, I'm working on reproducing it. I'm hoping it's just some clock funkiness. I restarted the failed job.

The closure created by t.Run wasn't copying the testcase value, so the
test was being run on the wrong values.
When a lock hint is empty, nothing should be added to the lock
@carolynvs
Copy link
Collaborator Author

Turns out that #1130 was already fixed by this PR. Go me. 😉 So I just added a test to verify the correct behavior.

I also realized that my parallel tests weren't working as I had thought. I'm now making local copies of the testcase variables so that they are properly included in the subtest closure.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Why did dep not used my imported version?
4 participants