You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In rust, proc macro crates are limited in that they are only allowed to export proc macros. Within substrate, frame-support-procedural has traditionally been a dumping ground for all FRAME-related macro stuff, including the macro definitions themselves (which are all just docs + a thin veneer calling internal parsing/expansion logic), macro support functions, and all of the parsing and expansion logic for things like #[pallet], construct_runtime!, etc.
In the case of substrate, this has historically been considered fine, as the only public interface Parity wants to maintain is the macro definitions themselves. That said, there are plenty of legitimate circumstances where an outside crate might want to access the parsing logic for things like pallets and construct_runtime! as a way of validating or enforcing additional restrictions, for example in a linting environment. In fact there is at least one instance in the wild already (https://github.com/opentensor/subtensor/blob/devnet-ready/support/linting/src/pallet_index.rs) where an outside project has had to fork frame-support-procedural (https://github.com/opentensor/subtensor/tree/devnet-ready/support/procedural-fork) simply for the purpose of accessing this parsing logic, in this case to enforce that all construct_runtime!s in the workspace must use explicit pallet indexing.
So my proposal is this:
Whether or not Parity wants to maintain the stuff in frame-support-procedural as a public interface, it would still be more useful to the community if it were physically possible to access these items without having to modify the crate itself.
I think it would be perfectly reasonable to:
pull out all of the parsing and expansion logic in frame-support-procedural
put it in another crate within the support directory (maybe frame-macros-core?)
frame-support-procedural adds that crate as a dep and pulls all its parsing and expansion logic from there
add a disclaimer to frame-macros-core saying everything in this crate is semver exempt and subject to change, use at your own risk.
Crucially, this approach would create zero breaking changes (the original public interface for frame-support-procedural would remain exactly the same), would put no additional burden on Parity as long as the disclaimer is in place, and quietly give the community what it wants in this regard.
Also worth mentioning, I think in reality the core parsing/expansion logic is probably the most stable code in substrate. Changes to it are usually small and merely additive, so I for one would feel perfectly safe using things like pallet::Def in other projects even if there is no official guarantee from Parity that they won't change ;)
I'd be happy to submit a PR doing this if there is general support for it :)
In rust, proc macro crates are limited in that they are only allowed to export proc macros. Within substrate,
frame-support-procedural
has traditionally been a dumping ground for all FRAME-related macro stuff, including the macro definitions themselves (which are all just docs + a thin veneer calling internal parsing/expansion logic), macro support functions, and all of the parsing and expansion logic for things like#[pallet]
,construct_runtime!
, etc.In the case of substrate, this has historically been considered fine, as the only public interface Parity wants to maintain is the macro definitions themselves. That said, there are plenty of legitimate circumstances where an outside crate might want to access the parsing logic for things like pallets and
construct_runtime!
as a way of validating or enforcing additional restrictions, for example in a linting environment. In fact there is at least one instance in the wild already (https://github.com/opentensor/subtensor/blob/devnet-ready/support/linting/src/pallet_index.rs) where an outside project has had to forkframe-support-procedural
(https://github.com/opentensor/subtensor/tree/devnet-ready/support/procedural-fork) simply for the purpose of accessing this parsing logic, in this case to enforce that allconstruct_runtime!
s in the workspace must use explicit pallet indexing.So my proposal is this:
Whether or not Parity wants to maintain the stuff in
frame-support-procedural
as a public interface, it would still be more useful to the community if it were physically possible to access these items without having to modify the crate itself.I think it would be perfectly reasonable to:
frame-support-procedural
support
directory (maybeframe-macros-core
?)frame-support-procedural
adds that crate as a dep and pulls all its parsing and expansion logic from thereframe-macros-core
saying everything in this crate is semver exempt and subject to change, use at your own risk.Crucially, this approach would create zero breaking changes (the original public interface for
frame-support-procedural
would remain exactly the same), would put no additional burden on Parity as long as the disclaimer is in place, and quietly give the community what it wants in this regard.Also worth mentioning, I think in reality the core parsing/expansion logic is probably the most stable code in substrate. Changes to it are usually small and merely additive, so I for one would feel perfectly safe using things like
pallet::Def
in other projects even if there is no official guarantee from Parity that they won't change ;)I'd be happy to submit a PR doing this if there is general support for it :)
cc @gupnik / @ggwpez / @kianenigma
The text was updated successfully, but these errors were encountered: