[WIP] Ignore NoGoCode errors from required packages

[carolynvs]

• Ignore NoGoCode errors from required packages.
• Change hashing structure to consider required and imported packages separately.
• Any other changes needed due to bumping the solver version?
• New unit tests
  • nogocode only allowed for required's
• Changelog

What does this do / why do we need it?

This allows someone to vendor a project that doesn't have Go code by adding an entry to the required list in Gopkg.toml.

What should your reviewer look out for in this PR?

As I worked on this I realized that the change I made to support transitive constraints from #1489 also allowed me to keep track projects that were introduced from a required, vs. an import. This plumbing enables us to pass information through the solve process and use them during checks. That is the first commit in this PR. It's the same commit from that pull request.

It's either a really great idea or something that will throw @sdboyer into a violent rage. 😀

Do you need help or clarification on anything?

I put bmi on atomWithPackages because it already had a bmi method to recreate the original bmi. Not sure if it's safe to live there considering the comments on the original bmi function about avoiding copys of the package list. So it may need to shift elsewhere or these extra values should be attached directly to the atom struct.

Which issue(s) does this PR fix?

Fixes #1306

[carolynvs]

@sdboyer This has a WIP on it because it's not ready to merge but when you have time I'd appreciate a sanity check on my solver changes. I don't want to put more work on this until I know that my structural changes are acceptable.

[mcandre]

Could this PR be prioritized? Like, Go's xtools at golang.org/x/tools can't be resolved with dep until this work is completed.

[sdboyer]

Could this PR be prioritized?

This is open source - it's spelled "what can i do to help?" 😜

Like, Go's xtools at golang.org/x/tools can't be resolved with dep until this work is completed.

It can. Point required at the actual main binary you want, not the root of the project. As the docs note, required specifications are on packages, not projects.

[mcandre]

@sdboyer When I point required at the full path to a binary, then dep ensure complains that the path should be shortened to just the repository top level.

[szobov]

Hi there!
Thanks @carolynvs for this great job.
But, what can I do to help? I think it's very important feature in we need this to be in done.

Best regards.

[carolynvs]

Let me rebase and see if I can get a review of my changes. I wasn't confident that this is "the right way" to solve it, which is why it's been sitting for so long.

[sdboyer]

@carolynvs oooh, i actually had some more thoughts about this.

Instead of imbuing required with special properties, it might be better if we just introduce a new property into Gopkg.toml, something like allow-errs. This would allow the user to ignore type/missing/whatever errors from any path, not just required ones. The logic to manage this in the solver would be a bit less complicated, because we don't have to worry about keeping track of whether a given import path is required, imported, or both - we just have the map of the paths at which we allow errs, period.

This would have some ignored-like behaviors, so we'd want to make sure to carefully document it.

@carolynvs does that help with your (un)certainty at all?

[carolynvs]

OMG that is waaaaaay better! 💯 I'm going to close this PR and open a new one with that behavior instead.

[cove]

OMG that is waaaaaay better! 💯 I'm going to close this PR and open a new one with that behavior instead.

hey @carolynvs did you end up opening a PR?

[carolynvs]

@cove No, sorry to say that I don't have time to work on dep anymore all things considered. 😢

[szobov]

So, do we have someone who'll continue work on this feature?