bors [Fri, 24 Aug 2018 19:37:00 +0000 (19:37 +0000)]
Auto merge of #5935 - alexcrichton:vendor-paths, r=ehuss
Only use non-absolute paths for `path` dependencies
Previously Cargo would use a non-absolute path for any dependency contained
within the workspace root but this switches Cargo to only using relative paths
for `path` dependencies. In practice this shouldn't make much difference, but
for vendored crates and moving around `CARGO_HOME` it can produce more
consistent results when target directories are shared.
Alex Crichton [Thu, 23 Aug 2018 18:51:05 +0000 (11:51 -0700)]
Only use non-absolute paths for `path` dependencies
Previously Cargo would use a non-absolute path for any dependency contained
within the workspace root but this switches Cargo to only using relative paths
for `path` dependencies. In practice this shouldn't make much difference, but
for vendored crates and moving around `CARGO_HOME` it can produce more
consistent results when target directories are shared.
Eric Huss [Fri, 24 Aug 2018 04:49:43 +0000 (21:49 -0700)]
New metabuild strategy using custom src_path enum.
- Use new enum `TargertSourcePath` for Target::src_path to make it explicit that metabuild has a special path.
- `cargo metadata` now skips the metabuild Target.
- JSON artifacts include the true path to the metabuild source file. This may not be the best solution, but it's unclear what it should be, and I would prefer to avoid breaking the output. Alternatively it could just not emit anything? I'm not completely familiar with the use case of these artifact messages.
- Place the file in `target/.metabuild/metabuild-pkgname-HASH.rs` instead of in the debug/release directory. Its contents do not depend on the profile.
- Fix bug in write_if_changed.
- More tests.
bors [Tue, 21 Aug 2018 19:55:15 +0000 (19:55 +0000)]
Auto merge of #5914 - alexcrichton:system-git, r=dwijnand
Add a configuration option to fetch with git-the-CLI
Currently Cargo always uses `libgit2` to perform all fetches of git
repositories, but sometimes this is not sufficient. The `libgit2` library
doesn't support all authentication schemes that `git` does and it isn't always
quite at feature parity with `git` itself, especially in terms of network
configuration.
This commit adds a configuration option to Cargo for fetching git repositories
with the `git` CLI tool rather than the internal `libgit2`. While this exposes
us to changes over time in the `git` CLI it's hopefully a very targeted use case
that doesn't change much. The internal `libgit2` library should be sufficient
for all other forms of git repository management. (and using `git` for only
fetches shouldn't slow us down much)
The new configuration option in `.cargo/config` is:
[net]
git-fetch-with-cli = true
which can also be specified with `CARGO_NET_GIT_FETCH_WITH_CLI=true` via an
environment variable.
Alex Crichton [Mon, 20 Aug 2018 17:01:16 +0000 (10:01 -0700)]
Add a configuration option to fetch with git-the-CLI
Currently Cargo always uses `libgit2` to perform all fetches of git
repositories, but sometimes this is not sufficient. The `libgit2` library
doesn't support all authentication schemes that `git` does and it isn't always
quite at feature parity with `git` itself, especially in terms of network
configuration.
This commit adds a configuration option to Cargo for fetching git repositories
with the `git` CLI tool rather than the internal `libgit2`. While this exposes
us to changes over time in the `git` CLI it's hopefully a very targeted use case
that doesn't change much. The internal `libgit2` library should be sufficient
for all other forms of git repository management. (and using `git` for only
fetches shouldn't slow us down much)
The new configuration option in `.cargo/config` is:
[net]
git-fetch-with-cli = true
which can also be specified with `CARGO_NET_GIT_FETCH_WITH_CLI=true` via an
environment variable.
bors [Mon, 20 Aug 2018 21:18:45 +0000 (21:18 +0000)]
Auto merge of #5886 - dekellum:record-package-git-head-3, r=alexcrichton
Generate .cargo_vcs_info.json and include in `cargo package` (take 2)
Implements #5629 and supersedes #5786, with the following improvements:
* With an upstream git2-rs fix (tracked #5823, validated and min version update in: #5858), no longer requires windows/unix split tests.
* Per review in #5786, drops file system output and locks for .cargo_vcs_info.json.
* Now uses serde `json!` macro for json production with appropriate escaping.
* Now includes a test of the output json format.
Possible followup:
* Per discussion in #5786, we could improve reliability of both the VCS dirty check and the git head sha1 recording by preferring (and/or warning otherwise) the local repository bytes of each source file, at the same head commit. This makes the process more appropriately like an atomic snapshot, with no sentry file or other locking required. However given my lack of a window's license and dev setup, as exhibited by troubles of #5823, this feel intuitively like too much to attempt to change in one iteration here. I accept the "best effort" concept of this feature as suggested in #5786, and think it acceptable progress if merged in this form.
bors [Mon, 20 Aug 2018 17:34:45 +0000 (17:34 +0000)]
Auto merge of #5912 - rust-lang:dependabot/cargo/opener-0.3.0, r=alexcrichton
Update opener requirement from 0.2.0 to 0.3.0
Updates the requirements on [opener](https://github.com/Seeker14491/opener) to permit the latest version.
<details>
<summary>Changelog</summary>
*Sourced from [opener's changelog](https://github.com/Seeker14491/opener/blob/master/CHANGELOG.md).*
> ## [0.3.0] - 2018-08-18
> ### Added
> - `stderr` field to `OpenError::ExitStatus` variant, which captures anything the failed process wrote to stderr.
>
> ## [0.2.0] - 2018-08-08
> ### Removed
> - The `open_sys` function, which was erroneously pub on non-Windows builds.
>
> ## [0.1.0] - 2018-08-08
> - Initial release.
</details>
<details>
<summary>Commits</summary>
- See full diff in [compare view](https://github.com/Seeker14491/opener/commits/v0.3.0)
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme
Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
Finally, you can contact us by mentioning @dependabot.
dependabot[bot] [Mon, 20 Aug 2018 05:27:11 +0000 (05:27 +0000)]
Update opener requirement from 0.2.0 to 0.3.0
Updates the requirements on [opener](https://github.com/Seeker14491/opener) to permit the latest version.
- [Release notes](https://github.com/Seeker14491/opener/releases)
- [Changelog](https://github.com/Seeker14491/opener/blob/master/CHANGELOG.md)
- [Commits](https://github.com/Seeker14491/opener/commits/v0.3.0)
bors [Wed, 15 Aug 2018 17:00:22 +0000 (17:00 +0000)]
Auto merge of #5856 - Eh2406:min-test, r=alexcrichton
run some tests with minimal-versions on CI
In #5757 we discovered that sum test don't pass with minimal-versions, and so only added CI for `cargo check`. This PR is to see if that is still needed, and if it is then which test rely on upstream bugfix.
bors [Wed, 15 Aug 2018 16:09:58 +0000 (16:09 +0000)]
Auto merge of #5888 - Seeker14491:opener, r=alexcrichton
Handle opening browser with `opener` crate
Fixes #5701
A note about behavior on Linux:
When looking for a browser to open the docs with, Cargo currently tries the `$BROWSER` environment variable, `xdg-open`, `gnome-open`, and finally `kde-open`, in that order. With this commit, this behavior changes; the `opener` crate always uses the `xdg-open` script, which is included in the `opener` crate. The `xdg-open` script takes care of finding a suitable browser.