Make macro implementation code spearately compilable with its own version solve

[lrhn]

Currently macros are Pub dependencies like any other. That, among other things, mean that their dependencies are the same as the dependencies of the user package. If both depend on package:collection, they have to agree on a version solve.

Consider instead making a macro implementation package a special kind of dependency, so that Pub knows that it's dealing with a macro. Or mark, in the pubspec.yaml, the entry points of macros.

Then Pub can solve that macro package's dependencies twice: Once for the user package, for the parts that are imported, and one for itself, where the latter solution is only used to compile and run the macro implementation. That happens in a separate isolate, and communicates only using SDK types, so there should be no interaction beween the two compilations.

The reason for doing that extra work, is that a separate solution for the macro will likely be stable for a given SDK, so that we can pre-compile the macro entry point. If the package resolution for the macro depends on the dependencies of the application it's used in, we're much less likely to be able to pre-compile, or re-use the same compilation between different applications.

Maybe we don't actually need to specify anything, because Pub behavior isn't governed by the language specification, and we can just do whatever we need to do. We must be careful to not accidentally disallow a separate compilation and version solve from being allowed. (Another good reason for keeping the macro implementation hermetically separated from the macro invocation code.)

[jakemac53]

I agree that macros could have their own version solve. I don't necessarily agree they should have their own version solve. That sounds expensive, and potentially confusing (you could now get N different version solve errors on a pub get, one for each macro you depend on as well as for your app?).

I agree it isn't an issue for the language specification, it is mostly just a tooling question, but if we do this it needs to be well motivated. What makes macro dependencies different from regular dependencies, such that it is worth introducing this complexity?

It also likely means we could not share any work between compilations of macros themselves, which the CFE at least does do today I believe.

[jakemac53]

I am going to go ahead and close this as not planned - macros also depend on annotations which are used in the user program, and need to be version solved with the macros in order to ensure compatibility.

[davidmorgan]

I'm not sure that's a super convincing argument: that's still a weaker constraint on the version solve than forcing all deps of some arbitrary user of the macros to the same version solve. You could perfectly validly have two deps that want different versions of annotation + macro.

But anyway I agree with closing for now, we can come back to it if there is a well motivated example :) I think there is nothing preventing us from compiling macros in another workspace with a separate version solve if we want to, once we move to the split annotation + implementation that we plan to move to.

Thanks.