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

always prune unused packages #65

Closed
peterbourgon opened this issue Dec 27, 2016 · 5 comments
Closed

always prune unused packages #65

peterbourgon opened this issue Dec 27, 2016 · 5 comments

Comments

@peterbourgon
Copy link
Contributor

This is a question from my first run with the tool. I imported package A, which lives in repo R. Repo R also contains package B, which I don't use. Should/could dep prune B?

@jessfraz
Copy link
Contributor

jessfraz commented Jan 4, 2017

yes my opinion is it should

@jessfraz
Copy link
Contributor

jessfraz commented Jan 4, 2017

this is how gvt currently works

@sdboyer
Copy link
Member

sdboyer commented Jan 5, 2017

definitely, yes.

pruning gets all mixed up with checksumming in my mind, but i think pruning we can tackle first, which can then guide our approach to checksumming.

the big questions with pruning are, basically, "what's safe to prune." i'd really, really rather not provide any configuration controls around pruning - at most, there'd be an option to -skip-prune. but that means our pruning approach has to be pretty safe. it's easy to know which Go packages we don't need, but it's much harder to know whether pruning non-Go files, or directories without any Go files at all, is safe. maybe, in order to be safe, we just skip those entirely.

@jessfraz jessfraz changed the title Question: should unused packages be pruned? always prune unused packages Jan 23, 2017
@sdboyer
Copy link
Member

sdboyer commented Jan 24, 2017

this expanded on in #120

@sdboyer
Copy link
Member

sdboyer commented Mar 5, 2017

Closing this in favor of #120

@sdboyer sdboyer closed this as completed Mar 5, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants