SCP-1066 reorganizing plc-agda

[jmchapman]

• reduce number of times the list of modules appears in the cabal file

The list appears in a common stanza. It is listed twice as everthing in autogen-modules has to appear again in other-modules.

Created a library in the cabal file and a common stanza for the usual stuff you put in a common stanza.

• Split into a library and executable (not 100% sure this will work)

• Sort out naming of components

• Potentially refactor existing plc-agda tests to call plutus-core functions directly rather than calling out to plc.

Arguing with CI expected.

[michaelpj]

To be clear, I'm anticipating that you can put the big list of modules only in the library, and then have the executable just depend on the library.

[jmchapman]

I tried that but concluded that it doesn't help.
See here: https://cabal.readthedocs.io/en/3.4/cabal-package.html#example-a-package-containing-a-library-and-executable-programs

The executable has to repeat all the modules that it uses, which in this case is all of them.

[michaelpj]

I don't think so... Have a look at the stanza for the plc exectuable in plutus-core: it uses modules from the main library, but doesn't have to repeat them all. It just declares a dependency on the library and then uses it like a normal package.

[jmchapman]

I tried this out with a small 'hello world' example in Agda. Also, I think there may be another problem, I just tried adding a library to plc-agda.cabal and it doesn't appear to be allowed:

$ cabal v2-build metatheory
Warning: Requested index-state2020-08-05T00:00:00Z is newer than
'hackage.haskell.org'! Falling back to older state (2020-08-04T23:45:27Z).
Resolving dependencies...
Error:
    Internal libraries only supported with per-component builds.
    Per-component builds were disabled because build-type is Custom
    In the inplace package 'plc-agda-0.1.0.0'

[michaelpj]

So, there's a difference between having an "internal library" and a library component at all. In particular, the "main" library component is fine (just library with no name, implicitly the name of the package). "Internal libraries" are named libraries that aren't exported, and apparently they don't work with Custom builds, but we shouldn't need one here.

[jmchapman]

So, there's a difference between having an "internal library" and a library component at all. In particular, the "main" library component is fine (just library with no name, implicitly the name of the package). "Internal libraries" are named libraries that aren't exported, and apparently they don't work with Custom builds, but we shouldn't need one here.

Ah, thanks!

[jmchapman]

I don't think so... Have a look at the stanza for the plc exectuable in plutus-core: it uses modules from the main library, but doesn't have to repeat them all. It just declares a dependency on the library and then uses it like a normal package.

I think I have found where I was going wrong, the sources files for the lib and exe need to be in different folders otherwise cabal complains that the exe should repeat all the modules in other-modules. Perhaps it finds the files locally before looking for them in the library or something. This works for my test, I'll try moving stuff around in metatheory.

[michaelpj]

Ah yes, the weird implicit module discovery that GHC does. Better to just put things in separate source folders indeed.

[jmchapman]

I think I might need a bit of help/suggestions to update nix/haskell.nix. I have added a library and also renamed the three tests. I have tried to account for the latter but not the former.

[michaelpj]

Did you want to rename the package too? My suggestion would be plutus-metatheory, since we're using the plutus- prefix for most of our packages.

[jmchapman]

Not sure why that's not working...

[michaelpj]

Now it's just failing on the Haddock... tbh I'm not sure how that ever worked. I think I should maybe make the generation run as a postConfigure hook rather than preBuild 🤔

[michaelpj]

Ah, there was no library so there was no Haddock!

[jmchapman]

Now it's just failing on the Haddock... tbh I'm not sure how that ever worked. I think I should maybe make the generation run as a postConfigure hook rather than preBuild 🤔

I can do that. Do you still think it might work?

[michaelpj]

I'm just checking it out now.

[michaelpj]

Okay, it's a bit awkward to do this because you're moving things, but just steal this commit: 155bee8

[jmchapman]

Thanks @michaelpj that now passes CI. However, github seems to think that CI is still failing.

[michaelpj]

Yep, it's just confused. Let's go ahead and merge it!

[michaelpj]

Oh, it's caught up. Maybe turning it off from being a draft helped?

[jmchapman]

thanks!