No easy way to build instantiated backpack signature units for tooling

[DanielG]

Describe the bug

There is no (non-hacky) way to refer to the instantiated units of a backpack signature (indef) component.

When refering to an indefinite backpack component as a target on the commandline only the un-instantiated unit will be built, not all of it's instantiations.

(Please note I'm not 100% sure about the backpack nomenclature so I hope I'm making sense)

To Reproduce
Steps to reproduce the behavior:

I have a small backpack example (stolen from ezyang's blog post series) over in the cabal-helper repo so I'm going to use that since it's also part of my test-suite:

# Ok, setup the testcase
$ cd /tmp
$ git clone https://github.com/DanielG/cabal-helper.git
$ cd cabal-helper/tests/bkpregex/
$ echo "packages: ." > cabal.project

# Now do a build with the indef target, which also has two instantiations
$ cabal v2-build lib:regex-indef

# Now see if the dist-dirs for lib:regex-indef's units exist or not, indicating if they've been built
$ distdirs="$(jq -r '."install-plan" | .[] | select(."component-name" == "lib:regex-indef") | ."dist-dir" ' < dist-newstyle/cache/plan.json)"
$ for distdir in $distdirs; do if [ -e $distdir ]; then echo exists $distdir; else echo NOPE $distdir; fi;  done
exists /tmp/cabal-helper/tests/bkpregex/dist-newstyle/build/x86_64-linux/ghc-8.4.4/bkpregex-0.1.0.0/l/regex-indef
NOPE /tmp/cabal-helper/tests/bkpregex/dist-newstyle/build/x86_64-linux/ghc-8.4.4/bkpregex-0.1.0.0/l/regex-indef/bkpregex-0.1.0.0-inplace-regex-indef+AYP8n8MTOrTJ1O1qStoQzp
NOPE /tmp/cabal-helper/tests/bkpregex/dist-newstyle/build/x86_64-linux/ghc-8.4.4/bkpregex-0.1.0.0/l/regex-indef/bkpregex-0.1.0.0-inplace-regex-indef+FWgKbpc2n5z9FKNeEqm0Ar

If instantiated units are being built is a bit hard to see, so here I'm demonstrating they don't get built by finding their corresponding distdirs in plan.json. As you can see non of the regex-indef+... units' distdirs exist after building the lib:regex-indef target.

Expected behavior
Either the target lib:regex-indef should build the instantiations or plan.json should have a field telling tooling which target to use.

My current workaround is to identify backpack units in plan.json by looking for "+" in the ID then finding which units depend on this unit and building those, well really "that", component with --only-dependencies instead. That works but is quite horrifying.

Currently we have the "component-name" field, for example one of the units from above looks like this:

{
  "type": "configured",
  "id": "bkpregex-0.1.0.0-inplace-regex-indef+FWgKbpc2n5z9FKNeEqm0Ar",
  "pkg-name": "bkpregex",
  "pkg-version": "0.1.0.0",
  "flags": {},
  "style": "local",
  "pkg-src": {
    "type": "local",
    "path": "/tmp/cabal-helper/tests/bkpregex/."
  },
  "dist-dir": "/tmp/cabal-helper/tests/bkpregex/dist-newstyle/build/x86_64-linux/ghc-8.4.4/bkpregex-0.1.0.0/l/regex-indef/bkpregex-0.1.0.0-inplace-regex-indef+FWgKbpc2n5z9FKNeEqm0Ar",
  "depends": [
    "base-4.11.1.0",
    "bkpregex-0.1.0.0-inplace-regex-types"
  ],
  "exe-depends": [],
  "component-name": "lib:regex-indef"
}

but this tells us that this instantiated unit is supposedly part of "lib:regex-indef" which is kind of true but really it's a lie. This unit is not in the plan because of lib:regex-indef, it's in the plan because lib:regex-example has mixins which instantiate lib:regex-indef:

mixins:  regex-indef (Regex as Regex.String)
            requires (Str as Str.String),
         regex-indef (Regex as Regex.ByteString)
            requires (Str as Str.ByteString)

if this field referred to lib:regex-example my code would be happy but it would be somewhat less efficient than just letting me build the lib:regex-indef target together with instantiations.

Maybe just adding support to use unit-ids as commandline targets would be even better though. That problem is also going to come up as part of show-build-info so just adding generic support for all commands might be nice.

Additional context

As far as I can tell 4378f5c is to blame here, commit message:

Tweak target selection semantics for indefinite packages.

Suppose you have a Backpack package foo-indef, which has
some signatures; furthermore, elsewhere in your install plan
ths packages gets instantiated. When you type
'cabal new-build foo-indef', what should get built?

Previously: foo-indef, as well as all of its instantiations,
get built.

Now: only the indefinite foo-indef is typechecked.

This is what you want!

Err actually I want the instantiations to get built when building the foo-indef target! Well really I'd be happy if I could refer to the instantiations any other way but I think the most reasonable thing to do would be to just revert this commit.

[23Skidoo]

/cc @ezyang

[ezyang]

I guess we could add a selector that lets you filter for "all instantiations of a package in the current plan." But if you happen to know that you only want a specific instantiation, that's wasteful too. Can you tell me more about what the tooling wants to do?

[DanielG]

Such a selector would fix the problem but honestly I think it's overkill too.

I'm not really that interested in instatiations as such, the problem is that they break the assumption we have to make, namely that building the "component-name" target will make the corresponding "dist-dir" exist. If we fix that by having it point to the component that instantiated these units I'd pretty much be happy for now. I just don't want my tooling to crash when it comes along backpack units even if we don't really use them for anything yet.

I can't really tell you what exactly we want to do with backpack units since I haven't really gotten around to investigating it in detail yet what I need them for or if they break anything else further down the line. For now I just want to be able to extract build info (ghc options etc.) for them so I can get to that point :)

From your perspective, does it even make sense to want to build individual instantiations, say by using the unit-id as a target? I.e. can anything break in one specific instantiation but not the others? Or is "typechecking" the indef unit always good enough? By "break" I mean throw ghc errors, I suppose stuff could probably go wrong at link time(?) but that's not really what tooling cares about.

If I don't ever really need to interact with the instantiations I'd be just as happy to just ignore those units for the purposes of tooling by filtering them out. Would be nice to have a json field that tells me it's such a unit rather than having to check for + in the unitid though :)

[ezyang]

building the "component-name" target will make the corresponding "dist-dir" exist

Err, doesn't building an indef package make the dist-dir exist? (Because we just typecheck it.) In other words, what do you use the dist dir for? ;)

From your perspective, does it even make sense to want to build individual instantiations, say by using the unit-id as a target? I.e. can anything break in one specific instantiation but not the others? Or is "typechecking" the indef unit always good enough? By "break" I mean throw ghc errors, I suppose stuff could probably go wrong at link time(?) but that's not really what tooling cares about.

In principle, you can do mix-in linking yourself, and compute the unit ID that would correspond to a particular instantiation of a package. Unit IDs are just hashed versions of something that looks like regex-indef(String=str-string:Str) and the format is well specified and implementable by your tool. But I still don't understand what your tool is trying to do, so I'm having trouble understanding why you want to build individual instantiations.

[DanielG]

building the "component-name" target will make the corresponding "dist-dir" exist

Err, doesn't building an indef package make the dist-dir exist? (Because we just typecheck it.)

As I explain in the issue description it makes the dist-dir for the indef unit exist but not the instantiations.

In other words, what do you use the dist dir for? ;)

For the sake of argument let's say I want to call Setup.hs build in the dist-dir. I just need a way to get from the "does-not-exist" state to the "configured" state for a given unit from plan.json. Currently I'm using cabal v2-build --only-configure <unit's "component-name" field> because this works very well for everything except backpack units and seems to be about the only thing I can do with the interfaces we have currently.

From your perspective, does it even make sense to want to build individual instantiations, say by using the unit-id as a target? I.e. can anything break in one specific instantiation but not the others? Or is "typechecking" the indef unit always good enough? By "break" I mean throw ghc errors, I suppose stuff could probably go wrong at link time(?) but that's not really what tooling cares about.

In principle, you can do mix-in linking yourself, and compute the unit ID that would correspond to a particular instantiation of a package. Unit IDs are just hashed versions of something that looks like regex-indef(String=str-string:Str) and the format is well specified and implementable by your tool.

I think I'm not explaining my use-case right. I always already have a unit-id in hand which I got from plan.json so I don't really see why calculating these would be relevant to the issue at hand.

But I still don't understand what your tool is trying to do, so I'm having trouble understanding why you want to build individual instantiations.

Well tooling kind of does a lot of things so it's pretty hard to pin down exactly what you want to know... I would argue this issue is mainly about an internal consistency problem with plan.json and all you need to know is already in the issue description but I'm happy to provide details.

Let's start at the beginning maybe. I maintain a library, cabal-helper, which is intended to give tool authors an API to go from a cabal project directory to a GHC API session. I essentially ask Cabal for the GHC flags and other build info for a component and ship that to the user in a digestable format. The main high-level use-case here is building stuff like ghc-mod or Haskell-IDE-Engine etc which gives you various features in your development environment of choice all based on the GHC API.

At the layer in the stack where cabal-helper is I just want to tickle enough info out of cabal to let tools bring up a GHC session for a given unit, i.e. I read plan.json to figure out what units there are and then allow my API clients to ask things like "give me a list of all units" and then maybe "give me the GHC flags for some of those units".

In order to answer the last query I have to first run Setup.hs configure for the relevant units and that's where this issue comes in. Naturally since we're talking about infrastructure for IDE type tools I want to spend as little time answering questions as possible because this directly reflects on responsiveness. So I can't just go off and do a full build of the entire project just because I want to get info for one single unit.

Now if this unit of interest happens to be one of these instantiated units I'm in trouble because building the target that's in the "component-name" field will not in fact generate the dist-dir I'm looking for and just building "everything" is also not really an option I'm particularily fond of.

Does that adequately explain what i want to do?

[ezyang]

I reread your previous message and I think I know what I missed.

From your perspective, does it even make sense to want to build individual instantiations, say by using the unit-id as a target? I.e. can anything break in one specific instantiation but not the others? Or is "typechecking" the indef unit always good enough? By "break" I mean throw ghc errors, I suppose stuff could probably go wrong at link time(?) but that's not really what tooling cares about.

So, to give a concrete example of why this matters, the use case in question is that someone is editing a source file in Regex-indef, and we are building tooling to report if there are errors in your code. Ordinarily, every source file corresponds to a single compilation (so you just report errors on that); however, with Backpack indefinite packages, a source file may correspond to multiple compilations (one per instantiation of that package). Could those further compilations result in errors, where the original indefinite typechecking did not?

While technically instantiation could result in further errors (Backpack is not sound in this sense: just because you successfully typechecked a module against a signature, and showed an implementation implements the signature, doesn't mean linking them together will typecheck), but the practical answer is "no": your IDE should only report errors from the indefinite typechecking phase, and not from the instantiation phase. Backpack strives for soundness: besides bugs, really the only way to get an error at instantiation time is type class shenanigans. In most use-cases the indefinite typechecking will give you enough information to tell if instantiation works--you should ask your users to look at the underlying error messages from instantiation if there is trouble there.

So, to reiterate:

Or is "typechecking" the indef unit always good enough?

Yes, it is always good enough (caveat: unless you're trying to do Template Haskell or something that actually requires compiled code, or you're dealing with one of the cases where Backpack is unsound.)

Would be nice to have a json field that tells me it's such a unit rather than having to check for + in the unitid though :)

The plus is part of the spec, so it's probalby easiest to do that.