feat(stdlib): add net/url

[gfanton]

Added the net/url package. This package will be beneficial for manipulating URLs, for instance, parsing query parameters or for URL muxing in realms.

depends:

• fix(mempkg): don't attempt to validate name of an empty package #1076
• feat(stdlib): add path package #1065

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[thehowl]

Like #1065, just needs an update to gnovm/docs/go-gno-compatibility.md. Aside from that, once #1065 is merged, I think we can merge this as well.

[thehowl]

It looks like CI is failing too.

First issue is because we now have the "net" directory it is considered "existing" as a package. Possible solution: change tm2/pkg/sdk/vm/builtins.go PackageGetter from using osm.DirExists to also determining whether there are any .gno files in the dir?

Hopefully with this also the second issue should be solved (seems roughly of same nature).

[ilgooz]

Should we have a net dir at all? Is it possible for a package or contract to interact with the network, or be aware of it? If not, it might make sense to just drop net/ part from the package path.

[thehowl]

Good point @ilgooz. I reviewed the net/ directory, and no subpackages look like good candidates to be included in Gno.

I think net/url has the key advantage of being go-"compatible". Ie., importing a go file which uses net/url doesn't mean changing import path. It's quality-of-life, but I think it's helpful.

I propose changing the import path to url but having net/url as an alias

[gfanton]

First issue is because we now have the "net" directory it is considered "existing" as a package. Possible solution: change tm2/pkg/sdk/vm/builtins.go PackageGetter from using osm.DirExists to also determining whether there are any .gno files in the dir?

thanks for the tip, I will try to do that.

Should we have a net dir at all? Is it possible for a package or contract to interact with the network, or be aware of it? If not, it might make sense to just drop net/ part from the package path.

Wouldn't it be better to keep it in sync with the original stdlib structure to avoid confusion? Can't we explicitly mark those kinds of packages as unusable and warn the user upon import?

[gfanton]

change tm2/pkg/sdk/vm/builtins.go PackageGetter from using osm.DirExists

I had to change imports.go PackageGetter to have an impact on those failing tests, I've managed to make it works (d5c2563) by updating the behavior of ReadMemPackage: skipping validatePkgName if no gno files are present, and then do the same things in TestStore so package net can fallback on native method if needed.

[zivkovicmilos]

Looks good 💯

I've left just a small comment, other than that it seems good to go

[zivkovicmilos]

Was this intentionally left commented out?

[gfanton]

yes ! since it's copy/past from the orignal golang files, I prefere to simply comment instead of removing the line to easily find & fix if we add this package one day !

[codecov]

Codecov Report

Patch coverage has no change and project coverage change: +0.05% 🎉

Comparison is base (cfefb3b) 46.97% compared to head (7bcac2d) 47.03%.
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1066      +/-   ##
==========================================
+ Coverage   46.97%   47.03%   +0.05%     
==========================================
  Files         365      365              
  Lines       61156    61156              
==========================================
+ Hits        28729    28763      +34     
+ Misses      30066    30037      -29     
+ Partials     2361     2356       -5     

Flag	Coverage Δ
gno.land-_test.gnokey	0.00% <ø> (ø)
gno.land-_test.gnoland	88.14% <ø> (ø)
gno.land-_test.pkgs	27.88% <ø> (ø)
gnovm-_test.cmd	45.89% <ø> (ø)
gnovm-_test.gnolang.native	63.09% <ø> (ø)
gnovm-_test.gnolang.other	16.63% <ø> (ø)
gnovm-_test.gnolang.pkg0	17.98% <ø> (ø)
gnovm-_test.gnolang.pkg1	8.21% <ø> (ø)
gnovm-_test.gnolang.pkg2	9.87% <ø> (ø)
gnovm-_test.gnolang.realm	41.68% <ø> (ø)
gnovm-_test.gnolang.stdlibs	53.53% <ø> (ø)
gnovm-_test.pkg	25.96% <ø> (ø)
tm2-_test.flappy	∅ <ø> (∅)
tm2-_test.pkg.amino	58.32% <ø> (ø)
tm2-_test.pkg.bft	63.81% <ø> (+0.37%)	⬆️
tm2-_test.pkg.others	59.15% <ø> (-0.06%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 7 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.