* Removing warning when the constraint hint is empty. It's a common case
and the lock may still be imported.
* Fix warning to say lock instead of constraint when the lock hint
cannot be resolved.
The tests don't fail because it's a trailing whitespace difference
but I'm fixing so that it doesn't show up as modified for the next
person to update all the golden files
This allows people to run go test ./... -update, without this
in order to do a mass update of golden files you need to run the
update against individual packages which is a huge pain.
A convenience, as callers often need both the RootPackageTree and the
direct dependencies map. Though this does further suggest that we ought
to be able to stitch this up neatly in gps, at some point.
Also, handle an error that was previously dropped.
Specifically, we need to switch map[string]bool for
map[gps.ProjectRoot]bool. Trivial refactor, but it's preferable to do
this anyway as this is a situation where gps.ProjectRoot should be used
to denote that strings in this map are assumed to be project roots. Case
in point, one of the importers was making the assumption that it had
packages, not root paths, but it wasn't obvious without the type
hinting.
This method is a a complete and correct implementation for retrieving
the list of direct dependency names. It should be able to be used by all
dep commands, if needed.
The precise underlying causes of the problem with bzr on Windows is
unclear - it could be just about bzr with Windows, or the version of
bzr, or some underlying system interaction. But it's causing appveyor
tests to erroneously fail, and bzr is so little-used that it's
acceptable to just skip the tests, for now.
This change modifies the LATEST field in status from always being a
revision to the same type as of the VERSION field.
If VERSION is a semver version, the LATEST would have the latest semver
version of the project constrained by the effective constraint.
If VERSION is a branch version, the LATEST would have the latest
revision of that branch.
* make importers error tolerant
- root_analyzer.go: Log a warning on encountering an unrecoverable error during
import of external config and proceed with the import for other packages.
Do not return error from private func `importManifestAndLock`.
internal/importers:
- base/importer.go:
- `loadPackages`: Do not return error. If `SourceManager.DeduceProjectRoot`
fails to determine the project root, log a warning and continue with the
rest of the imported packages.
- `ImportPackages`: Do not return error. When constraint resolution from the
lock hint fails, only log a warning.
- Importer implementations:
- Return an error from `Import` only for catastrophic failures(ex: yaml
parsing failed).
- `load`: Make it more error tolerant. Log warnings only for any of the
following scenarios:
- When and if a lock file, separate from the dependency file is present,
like, in the case of glide, and parsing fails. Continue with the import
as if the lock file was not present.
- If import packages are parsed line by line like in the case of glock,
and one of the line could not be parsed.
- `convert`: Do not return an error. Log warnings only for any of the
following scenarios:
- Expected field, such as `package` for an entry in `glide.yaml>imports`
is not present.
- Package was specified but the contraint could not be found.
* update importer tests
* improve importer warning msgs
Address feedback from @carolynvs
* add tests for importer failure scenarios
- internal/importers/base/importer_test.go:
- Check for warning when an invalid project is present whose project root
cannot be parsed.
- Check for warning when lock hint cannot be resolved correctly and the
constraint cannot be applied.
- Integration test for malformed external config(glide.yaml)
* tweak importer warnings
- {package => project}
- Improve warning message when no constraint is found for the package being
imported.
* update changelog