-
Notifications
You must be signed in to change notification settings - Fork 1.6k
RFC: Procedural macros in same package as app #3826
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
base: master
Are you sure you want to change the base?
Changes from 6 commits
093a48a
6400116
bd3762d
2abc88c
cf956c9
3ce11c2
269863b
001a769
a4cc177
dad0bef
f4ef425
6e1111a
3b34d68
2a98d11
9fd805f
4731ce1
1488bdb
904a687
2f47429
1dc76b1
cfb4c32
c7f34c5
3f94b5b
ff89040
ad1964f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,140 @@ | ||
- Feature Name: `proc-macro-in-same-package-as-app` | ||
- Start Date: 2025-05-30 | ||
- RFC PR: [rust-lang/rfcs#3826](https://github.com/rust-lang/rfcs/pull/3826) | ||
- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000) tbd | ||
|
||
# Summary | ||
[summary]: #summary | ||
|
||
Have a new target in a cargo project, called `proc-macro`. Its default location is in `src/macros.rs`. This would be like the `lib.rs` in that it is alongside the source code. It would eliminate the need to create an extra package for proc macros. | ||
|
||
# Motivation | ||
[motivation]: #motivation | ||
|
||
A common thing to ask about proc macros when first learning them is: "Why on earth does it have to be in a separate package?!" Of course, we eventually get to know that the reason is that proc macros are basically *compiler plugins*, meaning that they have to be compiled first, before the main code is compiled. So in summary, one needs to be compiled before the other. | ||
|
||
It doesn't have to be this way though, because we already have this mechanism of compiling one thing before another – for example, the `tests` directory. It relies on the `src` directory being built first, and likewise we could introduce a `proc-macro` target that would compile before `src`. | ||
|
||
**To be absolutely clear**, this is not a proposal for same-*crate* proc macros (unlike previous proposals), but same-*package* proc macros: a much simpler problem. | ||
|
||
The motivation of this new target comes down to just convenience. This may sound crude at first, but convenience is a key part of any feature in software. It is known in UX design that every feature has an *interaction cost*: how much effort do I need to put in to use the feature? For example, a feature with low interaction cost, with text editor support, is renaming a variable. Just press F2 and type in a new name. What this provides is incredibly useful – without it, having a subpar variable/function name needed a high interaction cost, especially if it is used across multiple files, and as a result, we are discouraged to change variable names to make it better, when we have retrospect. With a lower interaction cost, the renaming operation is greatly promoted, and leads to better code. | ||
|
||
This proposal aims smooth out the user experience when it comes to creating new proc macro, and achieve a similar effect to the F2 operation. It is important to emphasise that proc macros can dramatically simplify code, especially derive macros, but they a lot of the times aren't used because of all the extra hoops one has to get through. This would make proc macros (more of) "yet another feature", rather than a daunting one. | ||
|
||
An objection to this one might raise is "How much harder is typing in `cargo new` than `touch macros.rs`?" But we should consider if we would still use as much integration tests if the `tests` directory if it is required to be in a seperate package. The answer is most likely less. This is because (1) having a new package requires ceremony, like putting in a new dependency in cargo.toml, and (2) requires adding to the project structure. A *tiny* bit in lowering the interaction cost, even from 2 steps to 1, can greatly improve the user experience. | ||
|
||
Another benefit is that a library developer don't have to manage two packages if one requires proc macros, and make them be in sync with each other. | ||
|
||
In summary (TL;DR), the effort one needs to put in to use a feature is extremely important. Proc macros currently has a higher ceiling, needing one to create a whole new package in order to use it, and lowering the ceiling, even just a little bit, could massively improve user experience. This proposal can lower it. | ||
|
||
# Explanation | ||
[explanation]: #explanation | ||
epage marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would be good to step through a couple of well known or exotic proc-macros, showing what this would be like. For example, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When looking at those proc macros, another area to consider is how they do testing and how that maps into this new design |
||
|
||
Currently, we create a new proc macro as so: | ||
1. Create a new package | ||
2. In its cargo.toml, specify that it is a proc macro package | ||
3. In the main project, add the package as a dependency | ||
4. Implement the proc macro in the new package | ||
epage marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
After this change, we create a new proc macro like this: | ||
1. Implement the proc macro in a new `macros.rs` in `proc-macro`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't like that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think We could rename it to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure about the casing on that one though. Should it have no spaces, be kebab-case or snake_case? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
you can import files from // in macros/lib.rs
#[path = "../src/foo.rs"]
mod foo;
use foo::Foo;
// in src/foo.rs
pub(crate) struct Foo; in any case, I don't expect proc macros to need to share code with their corresponding libraries all that often. imo any method (using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess. I was mainly basing it off of one suggestion made in the pre-rfc. Still not too sure where to put it though. I think Either case the user could always modify it in the cargo.toml There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, I'll put it back as
Could you clarify please? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Usually if you have a package with both a Proc macros on the other hand tend to have pretty distinct code from non-proc-macro crates, and they're probably more likely to span a couple of files. I don't think we want to encourage directory structures like this:
Where some names clash, or you can't tell at a glance whether files belong to the library or to a proc macro. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. usually if there's a executable for using some library, you'd put the command-line parsing in e.g. if you have some rust project named // use a function from the library crate, no `mod` needed
use json_prettify::format_json;
fn main() -> std::io::Result<()> {
// TODO: parse command line
format_json(std::io::stdin(), std::io::stdout())
}
use serde_json::{from_reader, to_writer_pretty, Value};
pub fn format_json<R: std::io::Read, W: std::io::Write>(input: R, output: W) -> std::io::Result<()> {
let json: Value = from_reader(input)?;
to_writer_pretty(output, &json)
} There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with not sharing I feel like allowing There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. started a new topic in internals: Deprecating having both |
||
|
||
To use the proc macro, simply import it via `macros::*`. | ||
```rust | ||
use macros::my_macro; | ||
``` | ||
|
||
## An example | ||
Suppose you are developing a library that would have normal functions as well as proc macros. The file structure would look like this: | ||
``` | ||
My-Amazing-Library | ||
|---src | ||
| |---lib.rs | ||
| |---macros.rs | ||
| |---common.rs | ||
|---cargo.toml | ||
ora-0 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
``` | ||
`common.rs` is a normal file that declares common data structures and functions. `macros.rs` defines macros, which will be made available to `lib.rs`. `lib.rs` can use the macros defined, and/or reexport the macros. | ||
|
||
Using code in `common.rs` in `macros.rs` is like how you would normally: | ||
```rust | ||
mod common; | ||
use common::*; | ||
``` | ||
|
||
## Cargo.toml configs | ||
Libraries like `syn`, `quote`, and `proc-macro2`, would be included under `[build-dependecies]` in the cargo.toml. (Perhaps we should put it in a new dependency section for proc macros?) | ||
|
||
Like `tests` or `lib`, this would have its own `[proc-macro]` section in cargo.toml. | ||
|
||
Here are all the options available under it, the values set are its default. | ||
```toml | ||
[proc-macro] | ||
name = "macros" | ||
path = "src/macros.rs" | ||
test = true | ||
doctest = true | ||
bench = false | ||
doc = true | ||
proc-macro = true # (cannot be changed) | ||
``` | ||
|
||
To disable automatic finding, use: | ||
```toml | ||
[package] | ||
autoprocmacro = false | ||
``` | ||
|
||
## How it would work in the implementation | ||
Then pass it into rustc with `--extern=macros=target/_profile_/deps/lib_____`. The process would occur after the compilation of `build.rs` to make metadata and files generated in OUT_DIR available, but before `lib.rs` to make macros available. This means `macros.rs` cannot use code in `lib.rs`, so the code would have to be factored out into a seperate file. | ||
|
||
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
None at the moment | ||
epage marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
# Rationale and alternatives | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Like @ogoffart pointed out, this isn't new. It would be good to step through past discussions and compare to where those landed There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you go into the motivation for This is an ineresting one because build scripts do not have a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's because when one types There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That doesn't quite make sense to me. We could have a Whether to have the flag or not can also be affected by whether we support unit tests inside of it (we don't for build scripts) so you can run Note: even if nothing is changed from this, this fleshes out the rationale and should be included / summarized in the RFC. Side note: whats interesting is we're working on moving build scripts out into their own packages while this does the opposite for proc macros. I think the use cases are different enough that one does not affect the other but kind of interesting to observe. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should talk through naming
Why aren't we consistent? Why have the name in one direction or the other? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's true. Do we prefer There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would lean towards There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you add a discussion under the Rationale and Alternatives that speaks to what was considered for naming and why the current option was chosen? |
||
[rationale-and-alternatives]: #rationale-and-alternatives | ||
|
||
1. Use `crate::macros::*` as the import path | ||
|
||
This would require changes to rustc, when there is a simpler solution. | ||
|
||
2. Have it within a `proc_macros` directory | ||
|
||
This was the original idea; but upon further consideration it turns out to be worse than the current. The justification of it over a file was: | ||
> *Since it would compile first, proc macro files cannot import functions in the main code. The problem is having it side-by-side to the rest of your code makes it seem like you could just import it, when you cannot. Having it as a seperate directory makes clear of this.* | ||
|
||
While it was true that proc macro files cannot import functions in the main code, it can import other modules, making the statement's merits false. | ||
|
||
3. Eliminate the need for new proc macro files/folders entirely, have the compiler work out where the proc macros are and separate them. | ||
|
||
This would suffer from the same issue as the last alternative, plus being harder to implement. | ||
|
||
4. Introspection | ||
|
||
Harder to implement, with less payoff relative to the amount of work required. | ||
|
||
# Prior art | ||
[prior-art]: #prior-art | ||
|
||
1. Zig comptime: metaprogramming code can sit directly next to application code. | ||
2. Declarative macros: can sit side by side as well, but is less powerful. | ||
3. Lisp macros: same as last two, except more powerful. | ||
4. `tests` directory, and `build.rs`: compiled at a different time as the main code. | ||
5. `Makefiles`, or other build systems: they allow for customisability for when code is built. | ||
|
||
# Unresolved questions | ||
[unresolved-questions]: #unresolved-questions | ||
|
||
1. Should proc macro dependencies be listed under `[build-dependencies]`, or a new `[proc-macro-dependencies]` section? | ||
2. ~~Should we import like `crate::proc_macro::file::macro`, or via a new keyword, like `crate_macros::file::macro`? The latter would avoid name collisions, but might be more confusing.~~ | ||
|
||
# Future possibilities | ||
[future-possibilities]: #future-possibilities | ||
|
||
1. As described in the [motivation] section, this proposal is aimed to make the process of creating proc macros easier. So a natural extension of this is to remove the need of third-party libraries like syn and proc-macro2. There is already an effort to implement quote, so they might be a possibility. | ||
|
||
2. This might enable for some sort of `$crate` metavariable. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Been thinking about this more and I'm unsure. If we tell the proc macro at compilation time, Cargo would need to know a unique identifier for the re-exporting crate. However, I'm not sure how easily we can determine that unique identifier when building a dependent. If we could somehow bind If we can't do this, how much would this affect this proposal? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Not much, I would say. When I was first ideating the proposal There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It'd already be feasible, today, to make wrapper That's not ideal, and it'd be nice to make it more usable, but that seems like a baseline starting point. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see how this is related to this RFC at all. Every dependent is allowed to rename library names as necessary, so it is no easier to support There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is improved with this RFC is that cargo now knows what API a derive is generating code against. We could potentially find a way to communicate this to rustc so it could provide See also the end of #3826 (comment) |
||
|
||
3. Enabling multiple lib targets. | ||
epage marked this conversation as resolved.
Show resolved
Hide resolved
|
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm missing a clear statement which proc-macros is this feature for?
The motivation section focuses on the ease of introducing a proc macro in a library that currently doesn't have one. I have sympathy for that, the proc-macro <-> build script/decl-macro switcheroo isn't fun. If the feature was tightly scoped to experimentation and simple library-internal use, the build order questions discussed in #3826 (comment) have a clear, simple answer. Dependents also wouldn't need to know that the proc macro exists, let alone opt in/out with crate features (cc #3826 (comment)).
But it seems quite a few people commenting here see this feature as a general replacement for "library re-exports proc-macros" -- and it's not like we can stop people from re-exporting the proc macros like that, even if that wasn't the intended usage. If the feature isn't designed with that in mind then there's a risk it'll end up as a newbie trap: easier to get started, but once you get serious you have to dig yourself back out of the downsides of the easier way. But in that case, the feature will become much more complicated. Thus, my questions: Is it an explicit design goal that essentially any library providing proc macros could use this feature? If not, what's out of scope and how would people pick between using this feature and making a separate crate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you see as the downsides to designing a proc-macro in this way? I don't think I've seen those raised yet in this discussion.
I've seen this as a general way of doing proc-macros and would see this feature not to be worth it (or maybe actively opposed) if this is for smaller scope and then people grow out of it. In general, I'm not thrilled with cramming everything into a single package to avoid having a workspace and feel that to meet what people want in doing that would move cargo away from what its good for. That said, I feel like this doesn't run into those problems and can help avoid some proc-macro problems (e.g. the proc-macro logically depends on the library it re-exports but can't declare that relationship nor is it obvious of a problem for users to solve or how to solve it).
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I share your gut feeling that this feature probably isn't worth it if it's only useful for small, simple macros, but I didn't want to prejudice my comment with that. The downsides I see with trying to do "everything" are mostly the complexity that I expect will be required to address all of the concerns raised in other comment threads. To avoid introducing downsides compared to a separate package, this feature will need:
derive = ["dep:foo_derive"]
feature. In general this needs to be a proper feature because it may interact in complex ways with ordinary features of the package. (RFC: Procedural macros in same package as app #3826 (comment))serde
and write impls by hand; as long as other crates in the build depend directly onserde_derive
(not viaserde/derive
) the former crates can still be compiled independently of the proc-macro and its dependencies.All of these points (and others we may find) can be addressed in theory. But not all of them seem to have straightforward solutions that fit in the scope of what a package currently is. For example, something like
required-features
on a packages' proc-macros could serve the second bullet point, but the third one needs a way to say "I only depend on this part of that package" (here: the lib, not the proc-macro) which doesn't currently exist and seems like a step towards "N things in 1 package instead of N packages in a workspace".This is a problem worth solving, but I'd prefer a solution that existing libraries with separate
foo_derive
packages can adopt without breaking their users who depend directly onfoo_derive
(most notably, serde). For example, if the proc-macro package could directly express which library package+version it's coupled in its manifest, that only requires a sufficiently new MSRV but no package restructuring.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe there is something I'm missing but I feel like the answers to these questions are fairly simple; the author just needs to take the time to enumerate and write it up.
For example:
This is no different than the regular proc-macro situation. If you are like
serde
today, in both cases the core functionality will be blocked on the derive building. However, if you have a derive likeclap
or serde after serde-rs/serde#2608, the proc-macro and the core library will be built in parallel and the re-export library will be blocked on both. Again, no difference between a separate package and same package.This is why I brought up
[proc-macro]
table so you can doAnd with that, your proc-macro is now skipped if
derive
is not enabled using existing Cargo functionality.You mentioned a problem with this related to addressing one of N libraries in a package. That didn't quite make sense to me but if its related to the other points, then I addressed those.
While true that if everyone depended on
serde_derive
, rather thanserde/derive
, people could depend onserde
without a slow down. This is unlikely to ever happen though so this is a benefit in theory. Instead, we need serde-rs/serde#2608 wrapped up and then libraries likeserde_json
can depend onserde_core
without the need for cooperation from every dependency. As a bonus, this will mean that we can see aserde_derive
v2!That proposal has a lot of complexity to it that I do not see it being likely to happen.
This introduces cycles between packages, particularly for publishing. There are ways to solve problems with that but taking just one part as an example, this would require a new publish API which has been stalled out for years.
This also takes a concern I have with this proposal being able to solve
$crate
(#3826 (comment)) and greatly increase the complexity for solving it because it would extend from determining information from a strict child-parent relationship to an arbitrary relationship as we work through the build graph.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difference is that with separate packages, it's clear how any of the three options can expressed. The library either depends on the associated proc-macro package or doesn't; a facade crate like
clap
is just a separate package that depends on both the library and the proc-macro. If library and proc-macro are part of the same package, there needs to be some new way to express these dependencies (possibly optional/feature-gated) between the library and the proc macros within the same package. It's less clear to me what this would look like than with therequired-features
thing.As I've said, I'm sure there's many ways to design support for this. But without having seen a complete proposal for all aspects, I'm no sure whether the end result will truly be better than the status quo.
It's not a theoretical benefit. Inertia is strong, of course, but I've seen a few big dependency trees reach this goal. For example, most configurations of
wasmtime
before the switch from bincode to postcard achieved it, as long as you disabled theprofiling
feature (and the postcard thing is fixable). Also, new libraries with derives can do the "please depend on foo and foo-derive separately" thing from the start and avoid offering aderive
feature in the first place (I've done that for a new library I started recently). This should remain expressible with "proc-macro in same package" if we want all proc macros to adopt this style (modulo MSRV and backwards compatibility issues).Besides, I don't understand how a clap-style (or
serde
/serde_core
-style) split would interact with this RFC. Assuming the "at most one library per package" rule remains in place, that means there's still going to be at least two packages involved. If that's going to be the recommended approach, the simplicity the RFC cites as motivation is mostly lost. If you put the proc-macro into the package that re-exports the underlying library crate (e.g.,clap_derive
becomes a[proc-macro]
ofclap
whileclap_builder
remains separate) you still have the problem that the package with the derive and the package with the traits being derived are separate and their version needs to match exactly. If the$crate
-for-proc-macro angle works out (seems very speculative to me at this point) then you'd keep that benefit, but the other benefits seem much less applicable than in the "one package for everything" case.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wasn't an initial goal, but in the pre-RFC and RFC there has been a need to do it so a lot of the revisions do have that in mind. There is still a lot of room of iterations.
You can just use conditional compilation on your proc macros. It'll just be like how you gate all other features. Unless I'm overlooking something.
It feels that some of the criticisms, while valid, are a bit too fixated on the idea of the separation between proc-macro packages and library packages. There was really no reason for them to be separated in the first place, except for build system, which I think most of us can agree is an unfortunate blocker. In an ideal world, proc macros and code can coexist together, and this is a close equivalent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fundamentally disagree with the motivation of the RFC. If that motivation was the sole motivation, I would be a hard "no" on this. imo if people have a problem with managing a workspace, we should work to improve workspaces. I mentioned earlier in this thread (#3826 (comment)) that I generally disagree with cramming everything into a package. For more on this topic, see https://blog.rust-lang.org/inside-rust/2024/02/13/this-development-cycle-in-cargo-1-77/#when-to-use-packages-or-workspaces
As I mentioned before (#3826 (comment)), the main benefit this gives us is a happy path for declaring the relationship between the proc-macro and the library it generates code against. As a secondary motivation is I see this as a fundamental step towards unblocking
$crate
though there are likely other blockers.So for
clap
, I would mergeclap_derive
intoclap
and keepclap_builder
as a separate package.I think there is something missing in our communication because you seem to still feel there are significant open questions on this point while I feel that I explain how this naturally falls out of the design and there isn't anything special to this (though the RFC does need to explicitly call this all out).
If there are lingering concerns, feel free to reach out to me for a call for us to work this out.
Ok, so I take back my saying its theoretical. I still think it is not a workflow we should prioritize in our designs. Cargo is an opinionated tool focused on usability. Having to do that much precise coordination across a dependency tree seems like the wrong answer with Cargo's design.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for elaborating on your perspective on what the RFC should be, @epage, this helps me understand your previous comments better. Also thanks for offering a call, but I think at this point it's probably a better use of everyone's time to let the RFC catch up with the discussion and propose a more detailed design. Then I'll open more focused comment threads if I still have concerns, because then I'll be able to phrase them more precisely since I'll have less guessing to do about what precisely is proposed.
The one thing that I'd like to ask you which the updated RFC probably won't answer is about your plan to merge
clap_derive
intoclap
. I'm not sure whether you think the main benefit of the RFC (happy path for declaring relationship between proc-macro and the library is generated code for) applies to that case. I don't think it does, because the derive would still be in a separate package (clap
) from the traits that the derive implements (clap_builder
), i.e., you'd still needclap
to depend on a specific, pinned version ofclap_builder
. Am I missing something or are you not expecting this benefit to apply in this setup? (Of course, proc-macro$crate
, if it works out, would still be useful in this case.)@ora-0 I'd say I care more about the build system POV (which units of work exist in the build and how they depend on each other) than about packages per se. In essence, if the goal is that every proc macro should share a package with its associated library, then I'm asking what that means for the dependency graph at the build system level. If some useful dependency graphs would be inexpressible in that future style, then I'd consider that a downside of the RFC and would like to discuss the impact. Conversely, if the RFC doesn't restrict our ability to massage the work done by the build system in the most favorable shape (compared to the status quo), I'd like the RFC to spell out how this is possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two common dependency problems when you have a
lib
->lib_derive
relationshiplib
requires a minimum version oflib_derive
butlib_derive
needs to declare a minimum version onlib
.lib
usinglib_derive = "=1.0.100"
.lib_derive
into thelib
package, this problem goes away.lib_core
, that doesn't matter becauselib_derive
only needed a minimum version requirement andlib
already has that onlib_core
lib_derive
using internal APIs oflib
which requires a=
requirement.lib
re-exports alib_core
which actually has the internal API, then you will still need a=
requirement.lib
will only re-export public APIs fromlib_core
and the private API used by the formerlib_derive
could live inside oflib
.Since
clap_derive
does not generate code using a private API fromclap
, it could be merged intoclap
without a problem. In fact, I could remove the use of=
inclap
today by havingclap_derive
declare atarget.cfg(false).dependencies
onclap_builder
. I don't remember why I haven't done that.serde_derive
does use private APIs. I've not followed theserde_core
PR too closely on whether those are living inside ofserde
orserde_core
.