Add the path to the manifest in json output #9022
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
nagisa
force-pushed
the
nagisa/manifest_path
branch
from
6c2fbfa to
4b9799e
Compare
|
Thanks for this! Could you describe your use case a bit more as well? There's presumably a lot of possible information we could put into each blob, e.g. everything |
That is already present as part of
Sure, so I'm implementing/hacking on a cargo subcommand – cargo-phabricator – and there is at least one instance where being able to access find out the project root/manifest is useful. In particular I had to resort to implementing a custom test runner, because cargo does not present messages about tests in a machine readable format (cf. #8903). Tests may depend on the very precise environment that cargo sets up for them (cwd = package root; environment variables, like Now, I'm sure that ideally we'd improve cargo's test runner so that implementing custom test runners is not necessary – and I intend to hack on that as well – but I can also imagine other people finding other use-cases where being able to access the manifest helps to tremendously simplify their cargo wrappers. |
|
Ok thanks for the info and seems reasonable to me! @rfcbot fcp merge |
|
Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
|
☔ The latest upstream changes (presumably #9122) made this pull request unmergeable. Please resolve the merge conflicts. |
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
rfcbot
added
to-announce
and removed
final-comment-period
|
@nagisa want to rebase this and I'll r+? |
This allows consumers of the json messages to avoid guessing where exactly the package root is. Having access to the package root is difficult by virtue of requiring logic to guess its location by e.g. walking filesystem from the source file. This guessing logic becomes further complicated in presence of workspaces and nigh impossible to implement correctly in instances where artifacts end up produced from paths above the package root (e.g. `../foo.rs`). Since Cargo has access to this data in the first place, there doesn't seem to be much reason to force consumers to invent their own, possibly flawed, logic.
nagisa
force-pushed
the
nagisa/manifest_path
branch
from
4b9799e to
548300b
Compare
|
Rebased. |
|
@bors: r+ |
|
📌 Commit 548300b has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Add documentation for JSON message_path. Documentation for the feature added in #9022.
This allows consumers of the json messages to avoid guessing where
exactly the package root is. Having access to the package root is
difficult by virtue of requiring logic to guess its location by e.g.
walking filesystem from the source file.
This guessing logic becomes further complicated in presence of
workspaces and nigh impossible to implement correctly in instances where
artifacts end up produced from paths above the package root (e.g.
../foo.rs).Since Cargo has access to this data in the first place, there doesn't
seem to be much reason to force consumers to invent their own, possibly
flawed, logic.