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

Commit 235ce96

Browse files
authored
Merge pull request #1601 from marun/fix-gopkg-toml-doc-links
Fix case of Gopkg.toml.md links in the docs
2 parents 9b3721f + 407c8db commit 235ce96

File tree

4 files changed

+5
-5
lines changed

4 files changed

+5
-5
lines changed

docs/daily-dep.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -101,7 +101,7 @@ Only if it is the first/last import of a project being added/removed - cases 3 a
101101

102102
### Rule changes in `Gopkg.toml`
103103

104-
`Gopkg.toml` files contain five basic types of rules. The [`Gopkg.toml` docs](gopkg.toml.md) explain them in detail, but here's an overview:
104+
`Gopkg.toml` files contain five basic types of rules. The [`Gopkg.toml` docs](Gopkg.toml.md) explain them in detail, but here's an overview:
105105

106106
* `required`, which are mostly equivalent to `import` statements in `.go` files, except that it's OK to list a `main` package here
107107
* `ignored`, which causes dep to black hole an import path (and any imports it uniquely introduces)

docs/deduction.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,6 @@ If the static logic cannot identify the root for a given import path, the algori
2121
Import path deduction is applied to all of the following:
2222

2323
* `import` statements found in all `.go` files
24-
* Import paths in the [`required`](gopkg.toml.md#required) list in `Gopkg.toml`
24+
* Import paths in the [`required`](Gopkg.toml.md#required) list in `Gopkg.toml`
2525
* `name` properties in both [`[[constraint]]`](Gopkg.toml.md#constraint) and [`[[override]]`](Gopkg.toml.md#override) stanzas in `Gopkg.toml`. This is solely for validation purposes, enforcing that these names correspond only to project/source roots.
2626

docs/failure-modes.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -183,7 +183,7 @@ It means that the solver was unable to find a combination of versions for all de
183183

184184
These rules, and specific remediations for failing to meet them, are described in detail in the section on [solver invariants](the-solver.md#solving-invariants). This section is about the steps to take when solving failures occur in general. But, to set context, here's a summary:
185185

186-
* **`[[constraint]]` conflicts:** when projects in the dependency graph disagree on what [versions](gopkg.toml.md#version-rules) are acceptable for a project, or where to [source](gopkg.toml.md#source) it from.
186+
* **`[[constraint]]` conflicts:** when projects in the dependency graph disagree on what [versions](Gopkg.toml.md#version-rules) are acceptable for a project, or where to [source](Gopkg.toml.md#source) it from.
187187
* Remediation will usually be either changing a `[[constraint]]` or adding an `[[override]]`, but genuine conflicts may require forking and hacking code.
188188
* **Package validity failure:** when an imported package is quite obviously not capable of being built.
189189
* There usually isn't much remediation here beyond "stop importing that," as it indicates something broken at a particular version.

docs/the-solver.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -19,15 +19,15 @@ The solver is an iterative algorithm, working its way project-by-project through
1919

2020
### `[[constraint]]` rules
2121

22-
As described in the `Gopkg.toml` docs, each [`[[constraint]]`](gopkg.toml.md#constraint) stanza is associated with a single project, and each stanza can contain both [a version rule](Gopkg.toml.md#version-rules) and a [source rule](Gopkg.toml.md#source). For any given project `P`, all dependers on `P` whose constraint rules are "activated" must express mutually compatible rules. That means:
22+
As described in the `Gopkg.toml` docs, each [`[[constraint]]`](Gopkg.toml.md#constraint) stanza is associated with a single project, and each stanza can contain both [a version rule](Gopkg.toml.md#version-rules) and a [source rule](Gopkg.toml.md#source). For any given project `P`, all dependers on `P` whose constraint rules are "activated" must express mutually compatible rules. That means:
2323

2424
* For version rules, all activated constraints on `P` must [intersect](https://en.wikipedia.org/wiki/Intersection_(set_theory)), and and there must be at least one published version must exist in the intersecting space. Intersection varies depending on version rule type:
2525
* For `revision` and `branch`, it must be a string-literal match.
2626
* For `version`, if the string is not a valid semantic version, then it must be a string-literal match.
2727
* For `version` that are valid semantic version ranges, intersection is standard set-theoretic intersection of the possible values in each range range. Semantic versions without ranges are treated as a single element set (e.g., `version = "=v1.0.0"`) for intersection purposes.
2828
* For `source` rules, all projects with a particular dependency must either express a string-equal `source` value, or have no `source` value at all. This allows one dependency to specify an alternate `source`, and other dependencies to play along if they have no opinion. (NB: this play-along behavior may be removed in a future version.)
2929

30-
If the current project's `Gopkg.toml` has an [`[[override]]`](gopkg.toml.md#override) on `P`, then all `[[constraint]]` declarations (including any in the current project) are ignored, obviating the possibility of conflict.
30+
If the current project's `Gopkg.toml` has an [`[[override]]`](Gopkg.toml.md#override) on `P`, then all `[[constraint]]` declarations (including any in the current project) are ignored, obviating the possibility of conflict.
3131

3232
#### Activated constraints
3333

0 commit comments

Comments
 (0)