Allow use of CGP proc macros without explicit import of prelude #40

Activity

1. gkgoat1 commented on Dec 6, 2025

   

   gkgoat1

   on Dec 6, 2025

   More actions

   You can probably use ::cgp as a default with an attribute/attribute parameter to change the crate path in nested macro invocations
2. gkgoat1 commented on Apr 13, 2026

   

   gkgoat1

   on Apr 13, 2026

   More actions

   @soareschen are you still considering this?
3. soareschen commented on May 4, 2026

   

   soareschen

   on May 4, 2026

   CollaboratorAuthor

   More actions

   @gkgoat1 Thanks for asking. Yes it is in the plan but I haven't got the time to prioritize on this.

   The tentative plan is to add something like a cgp_macro_prelude module that will be imported together with cgp::prelude::*. With that, the CGP macros will refer to CGP constructs in the form like cgp_macro_prelude::DelegateComponent instead of the current bare DelegateComponent.

   This way, if you don't want to import everything in prelude, you only need to import cgp::cgp_macro_prelude to make it work with the macros.

   Using something like ::cgp::DelegateComponent might be a bit challenging at the moment, because it would make the macros not easily usable by internal CGP crates that don't yet have the cgp crate available. I might be able to define an internal crate with local renaming to make this work, but it is not clear if it could work at the moment.

   The biggest blocker was that the macro library has become pretty bloated, with a lot of pending refactoring to be done. I was hoping to fix the prelude together with the macro refactoring. But given the limited time, I will probably try to fix the prelude first, and then refactor the macro code later on.
4. gkgoat1 commented on May 9, 2026

   

   gkgoat1

   on May 9, 2026

   More actions

   @gkgoat1 Thanks for asking. Yes it is in the plan but I haven't got the time to prioritize on this.

   The tentative plan is to add something like a cgp_macro_prelude module that will be imported together with cgp::prelude::*. With that, the CGP macros will refer to CGP constructs in the form like cgp_macro_prelude::DelegateComponent instead of the current bare DelegateComponent.

   This way, if you don't want to import everything in prelude, you only need to import cgp::cgp_macro_prelude to make it work with the macros.

   That doesn't fully resolve the issue though, you'd still need to import cgp_macro_prelude (which wrapper crates hiding their usage of CGP shouldn't need to specify)

   Using something like ::cgp::DelegateComponent might be a bit challenging at the moment, because it would make the macros not easily usable by internal CGP crates that don't yet have the cgp crate available. I might be able to define an internal crate with local renaming to make this work, but it is not clear if it could work at the moment.

   The idea for that could be that, like potential wrapper crates, internal crates specify themselves as the CGP path like ```rust
   #[cgp_path(crate)]

   so the macro would look there and not at `::cgp`
   
   > 
   > The biggest blocker was that the macro library has become pretty bloated, with a lot of pending refactoring to be done. I was hoping to fix the prelude together with the macro refactoring. But given the limited time, I will probably try to fix the prelude first, and then refactor the macro code later on.