Realm with "import encoding/json" can't be addpkg via gnokey, but manually

[r3v4s]

Realm with "import encoding/json" can't be addpkg via gnokey, but manually

Description

certain package with import encoding/json can not be add to chain via gnokey maketx addpkg (it fails with panic unknown import path encoding/json).

but manually adding file to ~/gno/examples/gno.land/r/ works

Your environment

• OS and version: macOS Ventura
• version of gno: latest master branch
• branch that causes this issue (with the commit hash): master

Steps to reproduce

// qjson.gno
package qjson

import (
	"encoding/json"
)

-home ~/.gno \
-remote 127.0.0.1:26657 \
-broadcast=true \
-chainid dev \
-gas-fee 1ugnot \
-gas-wanted 5000000 \
-memo "" \
-pkgdir ./ \
-pkgpath gno.land/r/demo/qjson \
test1

Expected behaviour

• adding packing with gnokey maketx addpkg should work

OR

• calling package(already added by manually) should not work

Actual behaviour

• adding packing with gnokey maketx addpkg failed

AND

• calling package(already added by manually) succeed

Additional

Looks like encoding/json is imported from here

[thehowl]

I think duplicate/related with #668?

I think the way native go stdlib bindings are implemented has issues. I'll create a new issue to work on a proposal for a refactor.

[r3v4s]

I think duplicate/related with #668?

I think the way native go stdlib bindings are implemented has issues. I'll create a new issue to work on a proposal for a refactor.

oh yes, I forgot to tag related issue & pr. Thank you in advance

[piux2]

@r3v4s, what do you get when you precompile and build qjson.gno file using gno?

[r3v4s]

@r3v4s, what do you get when you precompile and build qjson.gno file using gno?

// Code generated by github.com/gnolang/gno. DO NOT EDIT.

//go:build gno

package qjson

import (
	"encoding/json"
)

[zivkovicmilos]

Hey @thehowl, @r3v4s,

Do we have any updates on this?
Asking because we've had questions about JSON encoding from other implementation partners.

Just want to make sure if someone has taken up digging into this issue, and if not I'll look into it

[thehowl]

@zivkovicmilos Essentially, good encoding packages need reflection. Reflection is a complex issue. #814 is a step in the right direction as it allows us to work on multiple "original" gno stdlibs without breaking precompilation and needing to have everything in package std.

Related issues where we've talked about reflection: #750, #802, #788. If you, or anyone else, wants to do a master-issue on the topic it would be appreciated :)

We could do a "dumb" implementation now, but it could only work for primitive types and maybe slices of them, through a big type switch, and support more complex types (including structs, which is often what you'll want to encode) through JSONMarshaler. OR, adapt easyjson to not use unsafe and to generate gno code.

[moul]

Note from meeting:

• maybe we can support reflect, without unsafe as an internal package and whitelist specific packages such as encoding/json.
• maybe we have a unsafe_reflect package for unsafe parts and reflect without unsafe.
• start with minimal reflect package: TypeOf, ValueOf, or at least make sure to remove capabilities to "New*" or to read private fields.

[r3v4s]

Closing issue for below reason.
@harry-hov asked me about re-producing this issue, and it seems like doesn't occur any more(with current master branch).

Doesn't seems to issue or bug anymore, just json is missing