FAQ
You're designing a tool. Stop. The point of the discussion is to agree on a
standard format that explains what has been vendored, so that no matter how
it got copied, some other tool can come along and do intelligent resolution
of conflicts etc. We need to agree on a format, and then people can build
all sorts of nice things on top of it. All this stuff about intents starts
to get too tailored to one specific use case. It's fine to build that kind
of thing on top, but it's not the level we're working at right now.

Russ
On Thu, Mar 5, 2015 at 11:10 AM, Daniel Theophanes wrote:

Given the direction we will take on vendor packages, I would like to make
some observations and receive feedback on them.

Vendor's packages will be moved into a internal folder. Without the
configuration file in the internal folder root it will be impossible for a
machine to know which packages are local internal and which are external
internal. The content of the configuration file is thus important to always
be accurate.

Adding folder trees and re-writing files cannot be done in an atomic
fashion. Should an error occur, or conflict arise, a tool should be able to
resume gracefully.

I propose that the configuration file include intents and the vendoring
process be multi-step.
Let's take a single dependency node in the configuration file:
{
"ImportPath": "golang.org/x/net/context",
"Hash": "ab2340",
"RevNumber: "1234",

"Intent": "+", // can be "+", "-", or "=".
"InternalPath": "raft/internal/golang.org/x.net/context"
"NewInternalPath": "context"
}
The above node is created in the first pass of the vendoring process,
updating the configuration file. For this node it gives the intent to copy
the package "context" from the "raft" internal package to the top level
internal package. (A similar intent should be recorded in the internal
configuration file for the raft package, removing the context package.)

If there is a conflict (two Import paths that are the same are both
added), the new configuration file is added with the conflicting intents,
but kicks out to the user with a message. The user chooses the nodes to
keep and nodes to remove and runs the process again.

The second pass of the process copies and removes the files according to
the configuration intents and re-writes files as needed.

The third pass inspects the folders and the intents. If the intent is a
"-" indicating a removal, and the folder is not present, the intent can be
removed. Similarly if the intent is a "+" indicating a addition and the
folder is present, the intent is written as a "=" indicating no action is
needed.

Configuration files should not be written in place, but written to a temp
file in the same directory and renamed over the original.

I would personally be fine with the configuration file being either a JSON
or CSV file. I am partial to a CSV file myself as it removes the need for
quoting fields (no commas in most or all paths) and the header row can be
localized.

I would love to hear your response to this.
-Daniel

--
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 3 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedMar 5, '15 at 4:10p
activeMar 6, '15 at 5:01p
posts3
users2
websitegolang.org

2 users in discussion

Daniel Theophanes: 2 posts Russ Cox: 1 post

People

Translate

site design / logo © 2021 Grokbase