@curved-television-6568 Your comment on my PR, can you confirm your meaning: Rather than extend PublishPackages from the Publish goals, you'd rather return a new

PublishAndWritePackages

which contains the current PublishPackages plus a set of packages to write to the workspace? If so, is that a sensible name for the type?

That is what I mean, yes. I would avoid putting the intended action into the name keeping it to more stating what it is only. There is the “internal” request type already

PublishProcessesRequest

so to me it would make sense to call it

PublishProcessesResponse

. Only down side is it’s rather close to the

PublishProcesses

type returned by the backends but I’d be OK with it any way as the request/response type is not meant to leave this single module at all. Could even consider having a

_

prefix on the internal types to make that explicitly clear. That is (typing out to get a better sense of how it looks, members in square brackets):

PublishProcessesRequest [FieldSets..] -> PublishProcessesResponse [PublishProcesses, Packages]

Perfect. Sorry to ping you direct, just didn't want to go make a load of changes and then you be like "wtf, dude, that's not what I meant _at all_"

That’s perfect 👍

I agree it's better. The current design was making me a little queasy cos there can be N names and processes for each package, so it makes sense to separate them

yea, I’d really like to avoid taking the detour to the backend merely to pass the information through. 😉

I’d really like to avoid taking the detour to the backend merely to pass the information through.

The import of this statement has dawned on me. Should I just say

packages = await MultiGet(
        Get(BuiltPackage, EnvironmentAwarePackageRequest(pkg))
        for tgt in targets
        for pkg in target_roots_to_package_field_sets.mapping[tgt]
    )

in the top-level publish goal, rather than having each backend feed the packages back up the chain?

OR, turn

package_for_publish

into an “effecting” rule and pass it the workspace and dist dir to do the materializing step in there, calling invoking it with

await Effect(…)

I think that ought to work. What you suggest works of course, but it feels slightly weird to me to request the same things twice so close together..

I wonder whether you'd be willing to do a slack huddle at some point at the time of your choosing? I don't have enough of a grasp on the underlying mechanics to know what you mean. I can probably grok it with 10 minutes of high-bandwidth communication, though. If not, I understand completely.

I think the idea of just returning the packages in the result from

package_for_publish

is ok, keeping the side effecting in the goal rule is probably better any way. I tend to “think out loud” before analysing if it’s the best idea or not.. 😜