-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for RFC 2282 - Cargo profile dependencies #48683
Comments
Any update on this? :) |
Someone needs to implement it. |
If you're looking for someone to work on this I'd be happy to help! |
Sure! I don't have the bandwidth to mentor this but feel free to try it out. Might want to file an issue on the cargo side to coordinate the implementation work. |
Some issues came up during implementation.
|
Full spec sounds great. The problem with having a dedicated profile for scripts is that you may wish them to be compiled differently in debug vs release. build-override lets you do both. The original proposal (not the one we RFCd) allowed nesting of profiles which would have made this work well (you declare a new profile, and link it in as the build profile for an existing one) |
(Also to me it seems like having a build profile just makes the whole profile vs workflow deal even messier -- we already are in a situation where the test/bench profiles are a bit weird) |
Yep! I was just meaning that it can probably be improved on without too much effort. I think there was some concern during the RFC process that shared dependencies would be a problem, but they shouldn't be. I think @matklad had more thoughts on the profile/workflow stuff, so I'll let him say more. |
@Manishearth could you give an example for this? An important practical reason for compiling build scripts exactly the same in More broadly, I think the following properties make a dedicated
The interaction with workflows is also interesting here: in a nutshell, a workflow would allow one to compile and run some custom rust code on the host to do execute custom tasks, like cargo subcommands, but locally to the project. And this code needs to be compiled with some optimization settings and such :) I envision the It is true that |
My dev workflow may be one where I'm recompiling often (but I don't edit the build scripts) so I need the build scripts to be fast, but my release workflow may be one where I only run it occasionally (incremental builds are less common), so build scripts should be compiled in dev. This isn't everyone, but this could be someone.
This is an argument for why the defaults should be such that build profiles are the same , not an argument for why we shouldn't expose this functionality. Firefox, for example, would probably want an optimized build script with an unoptimized libsyntax/syn/whatever.
IMO it's not relevant to bring cross compilation into the picture here because cross compilation works differently -- dependencies are not shared. If cargo was rearchitected so that shared deps between build scripts and the main build may be compiled into separate artifacts, this makes more sense, but as it stands, these are shared, and IMO it's easier to reason about these shared dependencies when you have a single profile instead of two. |
Not anymore. Shared deps are now compiled separately. (The graph for features/versions is still unified, though.) |
I had some questions on how to feature-gate profiles in config files. I can imagine a variety of ways to implement it:
I can imagine if you put a profile in a global config it could be really fussy. Let me know if you have any ideas. |
I'd have some kind of flag in the config itself. |
But that's not a strong opinion |
I have some more questions (cc @alexcrichton @matklad).
|
Aha some excellent questions @ehuss! Lemme see if I can dig in...
|
My concern with rejecting with an error is that if in the future cargo supports additional profile names, it would make it impossible to use the new names or keys in a global config and continue using older versions of cargo. I would feel more comfortable with just warnings (
Do you mean string can override an int? If so, that sounds fine to me.
That seems fine with me, too. Would this be a command-line flag that is only necessary during the unstable period? My concern with unconditionally warning if you have a profile in a global config and you don't specify the command-line option is that you will end up with seeing that warning everywhere you don't specify the flag, which would be rather noisy. I kinda like the idea of only warning with I had another question: What should the precedence be? This comment suggests it should be manifest over config. However, |
An excellent point and sounds good to me!
Oops yes, indeed!
Correct! I'd also be ok not warning for now. It may lead to some confusion but you're right in that it's likely less than otherwise
I definitely agree it's config over manifest because you modify your local config as opposed to the manifest which is shared amongst all users. |
Part 2 that includes config profiles has landed on nightly. The (minimal) documentation is at: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#config-profiles |
cc #63484, a surprising result of using profile overrides. |
Update: #64316 has been merged. I wonder whether this feature can be stabilized. Is it ready for an FCP yet? |
To be clear, there are two or three features here which may be possible to stabilize independently. Some blockers: profile-overrides:
config-profile:
build-profile |
Rename `overrides` to `package` in profiles. Renaming per the discussion at rust-lang/rust#48683 (comment). I left backwards-compatibility in case anyone is using it, since it required very little effort. cc @da-x, FYI.
@ehuss now that rust-lang/cargo#6989 and rust-lang/cargo#7504 have been merged, can we maybe think about stabilizing the core |
Almost opened a new issue and then saw this. |
The cargo team discussed stabilizing the When defining an override for a package, it can be awkward when the thing you want to override is split across multiple crates. For example, if I wanted to change a couple settings for What do people think about that? Should there be some kind of capability to apply an override to dependencies of a crate? Or maybe a way to specify multiple crates for a single override? Or is this a niche concern, and almost everyone will just use I think it might be good to avoid situations like this: [profile.dev.package.rand]
opt-level = 2
debug-assertions = false
overflow-checks = false
[profile.dev.package.rand_core]
opt-level = 2
debug-assertions = false
overflow-checks = false
[profile.dev.package.rand_chacha]
opt-level = 2
debug-assertions = false
overflow-checks = false |
Could a crate like Otherwise Cargo and crates-io may need to develop some concept of a published group of crates, and that's probably whole another can of worms. |
Thanks for pushing this forward, @ehuss ! @kornelski right now, non-root crates can't even override their own settings. The current profile overrides feature only applies to the top level crate's Cargo.toml, to be specific to the root Cargo.toml of the top level crate's workspace. Cargo displays a warning if it finds non-root profile overrides in the same workspace, but it silently ignores profile overrides of dependencies. I think it's a good idea to provide such a feature (I personally would enable it in lewton to always optimize it, because lewton is very slow in debug mode) and @matklad has also expressed interest in it. Should the current behavior be changed? What if a crate only wants to override something for local development?
You have a point that you quickly get into the situation of repetitive sections. In the only place where I use profile-overrides, I have copy-pasted the same section for The same time though, the more features one adds, the harder a Cargo.toml becomes to parse for humans. A Cargo.toml with tons of repetition isn't easy to parse either though. IDK. These features seem they can be added in a backwards compatible fashion as well. |
@est31 I'm not sure if dependencies should be able to set any specific settings for themselves. I was thinking about a flag like: [package]
name = "rand"
if-my-settings-are-overriden-then-also-override-my-deps = true or maybe: [package]
name = "rand"
[dependencies.rand_chacha]
version = "0"
profile = "inherit" # inherit being the only value accepted on crates-io but this raises a question — what happens if two different crates do this to the same dependency. Whose settings "win"? |
Only talking about the defaults here. Of course, the leaf crate should always have final say here. @matklad spoke in even weaker terms of suggestions.
Oh I see what you want. It isn't even strictly a feature to group crates together like you would group all of the rand crates together. You could also say that e.g. an inflate implementation maintained by a different organization should get the same options as you because your speed depends on inflate.
I'd propose that if crate A (transitively) depends on crate B and both depend on C, then A's settings override those of B. If there is no hierarchy between A and B, cargo could create an error message or at least a warning. Anyways, I believe that these discussions shouldn't be blocking stabilization. |
A proposal to stabilize the |
Stabilize profile-overrides. This stabilizes the profile-overrides feature. This was proposed in [RFC 2282](rust-lang/rfcs#2282) and implemented in #5384. Tracking issue is rust-lang/rust#48683. This is intended to land in 1.41 which will reach the stable channel on Jan 30th. This includes a new documentation chapter on profiles. See the ["Overrides" section](https://github.com/rust-lang/cargo/blob/9c993a92ce33f219aaaed963bef51fc0f6a7677a/src/doc/src/reference/profiles.md#overrides) in `profiles.md` file for details on what is being stabilized. Note: The `config-profile` and `named-profiles` features are still unstable. Closes #6214 **Concerns** - There is some risk that `build-override` may be confusing with the [proposed future dedicated `build` profile](#6577). There is some more discussion about the differences at rust-lang/rust#48683 (comment). I don't expect it to be a significant drawback. If we proceed later with a dedicated `build` profile, I think we can handle explaining the differences in the documentation. (The linked PR is designed to work with profile-overrides.) - I don't anticipate any unexpected interactions with `config-profiles` or `named-profiles`. - Some of the syntax like `"*"` or `build-override` may not be immediately obvious what it means without reading the documentation. Nobody suggested any alternatives, though. - Configuring overrides for multiple packages is currently a pain, as you have to repeat the settings separately for each package. I propose that we can extend the syntax in the future to allow a comma-separated list of package names to alleviate this concern if it is deemed worthwhile. - The user may not know which packages to override, particularly for some dependencies that are split across multiple crates. I think, since this is an advanced feature, the user will likely be comfortable with using things like `cargo tree` to understand what needs to be overridden. There is [some discussion](rust-lang/rust#48683 (comment)) in the tracking issue about automatically including a package's dependencies, but this is somewhat complex. - There is some possibly confusing interaction with the test/bench profile. Because dependencies are always built with the dev/release profiles, overridding test/bench usually does not have an effect (unless specifying a workspace member that is being tested/benched). Overriding test/bench was previously prohibited, but was relaxed when named profiles were added. - We may want to allow overriding the `panic`, `lto`, and `rpath` settings in the future. I can imagine a case where someone has a large workspace, and wants to override those settings for just one package in the workspace. They are currently not allowed because it doesn't make sense to change those settings for rlibs, and `panic` usually needs to be in sync for the whole profile. - There are some strange interactions with `dylib` crates detailed in rust-lang/rust#64319. A fix was attempted, but later reverted. Since `dylib` crates are rare (this mostly applied to `libstd`), and a workaround was implemented for `build-std` (it no longer builds a dylib), I'm not too worried about this. - The interaction with `share-generics` can be quite confusing (see rust-lang/rust#63484). I added a section in the docs that tries to address this concern. It's also possible future versions of `rustc` may handle this better. - The new documentation duplicates some of the information in the rustc book. I think it's fine, as there are subtle differences, and it avoids needing to flip back and forth between the two books to learn what the settings do.
The proposal to stabilize the |
Stabilize config-profile. This is a proposal to stabilize config-profiles. This feature was proposed in [RFC 2282](rust-lang/rfcs#2282) and implemented in #5506. Tracking issue is rust-lang/rust#48683. This is intended to land in 1.43 which will reach the stable channel on April 23rd. This is a fairly straightforward extension of profiles where the exact same syntax from `Cargo.toml` can be specified in a config file. Environment variables are supported for everything except the `package` override table, where we do not support the ability to read arbitrary keys in the environment name.
Is there anything left to do here or can this be closed? |
I want to mention an issue I've just ran into: I tried to use |
Yes, this can be closed now. @lnicola That is the intended behavior. |
Hi, |
This is a tracking issue for RFC 2282 (rust-lang/rfcs#2282).
Cargo issue: rust-lang/cargo#5298
Steps:
(cc @rust-lang/cargo for mentorship instructions)
.cargo/config
(Profile Overrides (RFC #2282 Part 1) cargo#5384)Unresolved questions:
The text was updated successfully, but these errors were encountered: