feat: support realm subpackages

[anarcher]

Large program (included smart contracts?) has constructed with packages. Like normal packages (gno.land/p), This PR is for realm sub(nested) packages like below.

upgrade-a
├── integration_test.gno
├── package.go
├── v1
│   └── v1.gno
└── v2
    └── v2.gno

IMHO, Subpackages can be helpful in the versioned or upgradable realm.
For realm's ownership, A creator should be equal to root realm(gno.land/r/<root>) and sub realms (gno.land/r/<root>/<sub>). So I added PackageAccount.Owner to GnoAccount.

This is a realm package account

$ gnokey query auth/accounts/g1pzll2zyn0rrcshefa25k8v50annqr6lew80pq2
height: 0
data: {
  "BaseAccount": {
    "address": "g1pzll2zyn0rrcshefa25k8v50annqr6lew80pq2",
    "coins": "",
    "public_key": null,
    "account_number": "76",
    "sequence": "0"
  },
  "PackageAccount": {
    "owner": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5"
  }
}

This is an normal account.

height: 0
data: {
  "BaseAccount": {
    "address": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
    "coins": "9999980000000ugnot",
    "public_key": null,
    "account_number": "0",
    "sequence": "0"
  }
}

$  gnokey maketx addpkg anarcher --pkgpath "gno.land/r/hello10/v1" --pkgdir .  --gas-fee "1ugnot"  --gas-wanted
"5000000"  --broadcast true
Enter password.

OK!
GAS WANTED: 5000000
GAS USED:   356358

[moul]

Thank you very much;

I need to figure out the best way to combine your PR and #336.

But that’s clearly going in the good direction.
👍

[moul]

What do you think about removing this part and make the creator != rootAcc.Owner recompute the parent realm’s author dynamically?

[moul]

Hey @anarcher

Thank you very much for this PR. It goes precisely in the good direction.

To be more future-proof, where a contract developer will not have only one top-level realm but multiple ones, including shared ones for organizations. I’ll ask you to revert the extended account with the “owner” part and make runtime computing for permissions.

So basically, only keep (and adapt):

• pgks/std/memfile.go
• pkgs/sdk/vm/keeper.go

In an upcoming PR, I'll add support for realm reservation, linked with a new system-wide namespace realm + team support. And I will extend your work.

[anarcher]

Thanks for kind feedback @moul :-)

To be more future-proof, where a contract developer will not have only one top-level realm but multiple ones, including shared ones for organizations. I’ll ask you to revert the extended account with the “owner” part and make runtime computing for permissions.

I like your idea(runtime permission). :) IMHO, I think one of advantages of runtime permission is that many contract developers can add sub realms of one root realm (and adding/removing contract developer dynamically). Is it right?

I will revert the extended account with the “owner” part and then making runtime permission.

[anarcher]

Hi @moul,
For runtime permissions, My first thought was to maker/realm/acl using in vmkeeper.AddPackage. But this approach raise some kind of chicken-eggs problem or packages loading order. (Because we should add pkgs after r/realm/acl is loaded for checking permission and we should add r/realm/acl without r/realm/acl. :-)

What do you think about? Do you have better idea? :-)

[moul]

Hey @anarcher,

I appreciate that you want to help, but I prefer that we split the topic:

• clean up this PR, so it only addresses the sub-package/sub-dir need (as the PR title suggests), then merge it.
• I will update my ongoing PR feat: reorganize examples for upcoming namespace support #336 with instructions so you can also try to help on the ACL part.

My idea is similar to yours but without the chicken-eggs problem :)

[anarcher]

I revert PackageAccount. :-) The rest of the code is just the part of allowing subpackage paths.

My idea is similar to yours but without the chicken-eggs problem :)

👍 I'm curious about your idea :-)

[anarcher]

Another my idea about it is that each top-realm(namespace?) has own acl.gno. I think that it doesn't make the chicken-eggs problem. vmkeeper.AddPackage checks top path or sub path. If sub realm are added, vmkeeper.AddPackage just call HasPerm() in root realm of this sub realm. What do you think about it? :-)

[moul]

Thank you!

I’ll rebase and add new comments on my other PR so you can contribute too if you want :)

[moul]

Please, check out #375