`compile` compiles for the wrong Plutus Core version

Quantumplation commented 1 year ago

Summary

We're working on porting PlutusV1 contracts to PlutusV2; but when compiling these new contracts using the latest main branch, it produces scripts with the version prefix 010100, which I assume is the new version with sum-of-products terms; it also means it produces UPLC with these unrecognized terms ("Unknown term constructor tag: 8.")

As far as we can tell, there's no way to opt-out of this new compiler to produce contracts that work on main net.

Is the recommendation still to use 1.3.0, or is there some other best practice that I'm missing?

Steps to reproduce the behavior

Compile a simple minting script with the latest main

Actual Result

Observe a script, such as: 584e0101000033222222800245209b4e9e9af27b5dfa4d383be20535b94b16f4c0aa00ddc4b1ea4391396518bb500048811c000000000000000000000000000000000000000000000000000000000001
Observe that the version is 010100
Observe that at byte 10, there is an "80"
When evaluating the script on mainnet (or with Lucid, for example), you'll receive this error:

error: Uncaught (in promise) "Redeemer (Mint, 0): Parse error: So far we parsed\n\n[ [ (lam i(lam i(lam i(lam i(lam i(lam iparse error)))))) not parsed] not parsed]\n\nand we ran into error: Unknown term constructor tag: 8.\n\nHere are the buffer bytes (5 preceding) [00, 33, 22, 22, 22, 80, 02, 45, 20, 9B]\n\nBuffer position is 7 and buffer length is 77"

Expected Result

Plutus v1 and v2 scripts should compile succesfully for mainnet use; or there should be some way to specify the version of the VM / Compiler to use.

Describe the approach you would take to fix this

No response

System info

N/A

effectfully commented 1 year ago

As far as we can tell, there's no way to opt-out of this new compiler to produce contracts that work on main net.

Is the recommendation still to use 1.3.0, or is there some other best practice that I'm missing?

Try

{-# OPTIONS_GHC -fplugin-opt PlutusTx.Plugin:target-version=1.0.0 #-}

in the file that you want to compile or update ghc-options in the .cabal file of your project to include

-fplugin-opt PlutusTx.Plugin:target-version=1.0.0

Quantumplation commented 1 year ago

Ooo, that looks like exactly what I'm looking for @effectfully, I'll give it a try. Sorry I missed it; Is that documented somewhere?

effectfully commented 1 year ago

Is that documented somewhere?

It's mentioned on https://plutus.readthedocs.io in Plutus Tx Compiler Options.

Sorry I missed it;

No problem at all, we do welcome and appreciate questions, requests, reports etc.

BTW, if you think we could improve discoverability of the plugin options, we'd be interested in any ideas.

effectfully commented 1 year ago

Please let us know if using target-version=1.0.0 helped.

Quantumplation commented 1 year ago

@effectfully tentatively, it seems like that worked!

As for discoverability, I have a few suggestions:

Make sure any documentation links are prominent / badged at the top of the repo; see kupo as a perfect example
With any release that introduces breaking changes, a migration guide would be a godsend, focusing on
- any new settings / flags like this one that are required to maintain backwards compatibility
- any dependency management that needs to change; it took us several weeks to figure out how to update our dependencies x.x
- any like-for-like changes (ex. changed method signatures that can be changed super mechanically)
- any like-for-not-like changes, where there's not a 1-to-1 replacement, plus some suggested alternatives
If you have/write these, they should be prominent in the release notes, and ideally right on the homepage of your documentation page

Also, ideally these flags would be the default, with new versions of the compiler opt-in until they produce scripts that would be valid on mainnet.

Thanks again for the help!

effectfully commented 1 year ago

@Quantumplation this is fantastic feedback, thank you very much. I'll pass it to the team and make sure we address it (probably not very soon, unfortunately).

@effectfully tentatively, it seems like that worked!

Great, glad it seemed to help. Please do report if something doesn't work as expected.

With any release that introduces breaking changes, a migration guide

We have a changelog but it's indeed quite far from providing any sort of migration guide.

Also, ideally these flags would be the default, with new versions of the compiler opt-in until they produce scripts that would be valid on mainnet.

Well, that's a really good point indeed!

Generally speaking, our users do ask questions like "how can I be sure that what works now will keep working in future?" and we don't have any answer to that, so I believe we definitely need to prioritize making transitioning from one Plutus/ledger version to another easier, otherwise we're going to keep breaking things and annoying everybody with that.

Thanks again for the help!

Thanks for all the extremely helpful feedback!

I'm going to keep the ticket open at the very least until we have a strategy of addressing the points that you've raised.

IntersectMBO / plutus