Skip to content

Proposal: Resolve In Glide Cache Instead of Vendor #492

@mattfarina

Description

@mattfarina

Currently, Glide fetches packages (as repos) into the vendor/ directory and then resolves the dependency tree. As new packages are needed they are fetched and set to the needed version.

This proposal is to break this process apart. Packages would be fetched and versions resolved in the Glide cache and then exported (just the versions source without vcs information) to the vendor/ directory.

Pros:

  • When packages are vendored, that is stored in your apps VCS, there will be a major performance improvement when a warm cache.
  • Sometimes resolution has errors which causes Glide to exit before completion. This can leave the vendor/ directory in a bad state that needs to be fixed. This would no longer happen as only when Glide finds a new good state would it put source in vendor/.
  • Some flags such as --cache, --strip-vcs, --update-vendored would all no longer be needed.
  • Confusion around subpackages in Git would go away.

Cons:

  • If you checkout a dependency into the vendor/ directory, make changes to it from there, and push those changes you wouldn't be able to do that while Glide was working on your tree.
  • If you are in development and using Docker and you want them to share a cache you may need to pass in the shared location to Glide for the cache.
  • Glide would leverage a global cache lock which would cause parallel glide operations (processes) to take longer on the same system.

There are likely more pros and cons. If you know of any please note them in the comments.

Thoughts?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions