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

Add default prune options for init cmd #1460

Merged
merged 2 commits into from
Dec 24, 2017
Merged

Add default prune options for init cmd #1460

merged 2 commits into from
Dec 24, 2017

Conversation

arbourd
Copy link
Contributor

@arbourd arbourd commented Dec 17, 2017

What does this do / why do we need it?

  • Adds default prune options on init
  • Updates example comment in manifest to include default prune settings

What should your reviewer look out for in this PR?

  • How defaults are set in init.go
  • The examples comment in txn_writer.go

Do you need help or clarification on anything?

Do we need tests for toRawPruneOptions?

Which issue(s) does this PR fix?

fixes #1404

@arbourd arbourd changed the title Add default prune settings for init cmd Add default prune options for init cmd Dec 17, 2017
@carolynvs carolynvs changed the base branch from master to prune-release-prep December 18, 2017 15:34
@carolynvs
Copy link
Collaborator

I've changed the destination branch to prune-release-prep.

Copy link
Collaborator

@carolynvs carolynvs left a comment

Choose a reason for hiding this comment

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

Everything looks great. I've changed the target branch to a release branch for the prune feature.

manifest.go Outdated
@@ -416,6 +416,23 @@ func fromRawPruneOptions(raw rawPruneOptions) (gps.PruneOptions, gps.PruneProjec
return rootOptions, pruneProjects
}

func toRawPruneOptions(options gps.PruneOptions) rawPruneOptions {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Let's add a unit test. I realize we have integration tests that are tangentially testing this, but they don't exercise all of the flags.

Copy link
Collaborator

Choose a reason for hiding this comment

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

After this is updated to reflect the changes in #1219 , how can we clarify that this only works during the initial init? Unmarshalling project prune options is not possible without too much hacking...

Copy link
Collaborator

Choose a reason for hiding this comment

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

@ibrasho I am not sure I understand the question/problem?

Copy link
Collaborator

@ibrasho ibrasho Dec 18, 2017

Choose a reason for hiding this comment

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

Apologies for not explaining thoroughly. 😅

Do you remember the issue with unmarshalling prune project options [1] [2] (since we have a mixed string/bools TOML table)?

In short, this function (while it's only used in init) can be used later and assumed to write the parsed manifest as-read. While in reality, it would at best ignore prune project options.

This might not be an issue now, but I want us to make sure that we don't forget this later and assume that this function can un-marshall the full prune options.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just an observation: this function is also called during ensure -add.

Copy link
Member

Choose a reason for hiding this comment

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

if we have a way of encoding that failure mode as a panic, that would be great. I'm not sure offhand if it's possible, but something like "check if the map of project-specific options is non-empty,and if so, panic"

Copy link
Member

Choose a reason for hiding this comment

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

yeah...the call during the new mode is troubling. really, that should only be operating on discrete, additional items, not a whole Manifest.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@ibrasho Let me repeat back what I am hearing to make sure I've got it.

The concern is that this function only writes global prune options. If later someone tried to read in the Gopkg.toml, modify the in-memory manifest, and then write back the entire manifest to disk that the project level prune options would be lost?

I read through the code for dep ensure --add and have seen the manifest output from this PR. It doesn't appear to be behaving incorrectly. So I'd like to set that aside for now.

If you agree that I've finally understood your concern(?), then my initial preference would have been to fully implement the conversion from a manifest to toml. Unfortunately, it appears from your comment that the conversion of project-level prune options to a raw representation is not easy and would require hacks. I'll take your word on that! 😀

Since the full implementation is not actually needed, Sam's suggestion is to raise a panic when project-level prune options are present, forcing the developer to deal with this in the future if they try to use the unimplemented functionality.

Let me know if I've summarized correctly. If I have, then yes, I would also prefer a panic (and perhaps a copy/paste of my summary or a link back to it), over just a comment.

Copy link
Collaborator

@ibrasho ibrasho Dec 22, 2017

Choose a reason for hiding this comment

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

A panic is a better and clearer approach.

@carolynvs
Copy link
Collaborator

As soon as we have a test, I'll merge into our release branch and then integrate it with #1219 when that's ready so that we are executing prune at the end of init.

@arbourd
Copy link
Contributor Author

arbourd commented Dec 18, 2017

I rebased this PR on new branch and I actually have build errors based on what @ibrasho was mentioning. Will need to make another quick change.

@arbourd
Copy link
Contributor Author

arbourd commented Dec 18, 2017

Updated with a test with a couple of cases, and fixed build errors.

manifest.go Outdated
@@ -479,7 +495,7 @@ func (m *Manifest) toRaw() rawManifest {
}
sort.Sort(sortedRawProjects(raw.Overrides))

// TODO(ibrasho): write out prune options.
raw.PruneOptions = toRawPruneOptions(m.PruneOptions.PruneOptions)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I would recommend passing m.PruneOptions instead. So we can check if the projects are empty or not in toRawPruneOptions.

manifest.go Outdated
@@ -417,6 +417,23 @@ func fromRawPruneOptions(raw rawPruneOptions) gps.RootPruneOptions {
return opts
}

func toRawPruneOptions(options gps.PruneOptions) rawPruneOptions {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you change it to accept a gps.RootPruneOptions, so we can check if options.ProjectOptions is not empty?

@@ -15,7 +15,7 @@ import (

"github.com/golang/dep/gps"
"github.com/golang/dep/gps/pkgtree"
"github.com/pelletier/go-toml"
toml "github.com/pelletier/go-toml"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was VS Code.

Copy link
Collaborator

@carolynvs carolynvs left a comment

Choose a reason for hiding this comment

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

🎄 🎁 💖

@carolynvs carolynvs merged commit cf67c0a into golang:prune-release-prep Dec 24, 2017
@arbourd arbourd deleted the prune-init branch December 24, 2017 04:22
@sdboyer sdboyer added this to the v0.4.0 milestone Jan 24, 2018
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.

5 participants