-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: fix gno test
for _test.gno
and _filetest.gno
files
#945
Conversation
gno test
to test both pkgs and filesgno test
to test both pkgs and files
gno test
to test both pkgs and filesgno test
to test both pkgs and files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left a few comments that should be addressed before going forward, I think we can simplify the complex loops introduced
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very nice improvements
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logic is more convoluted than it should be. I recommend writing down what you want to accomplish with your logic, and after that start writing the code. That will help you to organize your ideas and therefore the final code.
Ping me if you need any help or any other explanation from my comments.
52ba43f
to
7cb7960
Compare
Thanks @ajnavarro for your review. I made my points in the reply. Happy to discuss more.
Feedback taken :)
Sure. Thanks again :) |
@@ -234,7 +234,7 @@ func makeGenesisDoc( | |||
|
|||
for _, pkg := range nonDraftPkgs { | |||
// open files in directory as MemPackage. | |||
memPkg := gno.ReadMemPackage(pkg.Path(), pkg.Name()) | |||
memPkg := gno.ReadMemPackage(pkg.Dir, pkg.Name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this usage of Dir is OK since you need to file location to load.
@@ -133,9 +134,13 @@ func execTest(cfg *testCfg, args []string, io *commands.IO) error { | |||
cfg.rootDir = guessRootDir() | |||
} | |||
|
|||
pkgPaths, err := gnoPackagesFromArgs(args) | |||
paths, err := gnoPackagesFromArgs(args) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
better to leave it as pkgPaths so as to differentiate from file paths.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but they can be file paths too.
e.g. paths
can contain /path/to/pkg
, /path/to/pkg/file_test.gno
, or /path/to/pkg/z[N]_filetest.gno
Later I'm also planning to support patterns in args. e.g. gno test ./...
, gno test /examples/.../pkg
etc (just like go test
)
paths
can have pkgpath. filepath or both depends on the args
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's do the renaming in a new PR so we can focus on names.
Suggestion:
paths, err := gnoPackagesFromArgs(args) | |
targets, err := targetsFromPatterns(args) |
// targetsFromPatterns returns a list of local dirs or single files
// intended to be used by gno commands such as `gno test`.
func targetsFromPatterns(args []string) []target {
// TODO: support './...'
}
@@ -145,75 +150,72 @@ func execTest(cfg *testCfg, args []string, io *commands.IO) error { | |||
}() | |||
} | |||
|
|||
subPkgs, err := gnomod.SubPkgsFromPaths(paths) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we CAN have a function called "SubPkgsFromDir" (singular), but not "SubPkgsFromDirs" or "SubPkgsFromPath" or "SubPkgsFromPaths".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on how go list ./crypto/... ./foo ./crypto/dsa
works (https://github.com/golang/go/blob/499a12009938fe2ffff90775832b9d67ca3e46b2/src/cmd/go/internal/list/list.go#L569C24-L569C35), they also use a single helper that takes a list of targets.
The main difference is that they are only supporting dirs and not single file, while we want our CLI to basically support this at the end: gno test ./crypto/... ./foo ./bar_test.gno
with files too.
I think we should consider that we have:
PkgPath
when onchain or when identified by gno.mod or other methodsDir
in the case aPkgPath
is located in the file system (but mabe we won't need it anymore), andTarget
, in my opinion target should be the only way we identify aos.Args
that can be a pattern, a dir or a file.
Edit: @harry-hov found this which is better: https://github.com/golang/go/blob/master/src/cmd/go/internal/load/pkg.go#L2816; it consists of looking for packages, but creating virtual packages of a single file when a file is passed instead of a directory or pattern.
if cfg.precompile { | ||
if verbose { | ||
io.ErrPrintfln("=== PREC %s", pkgPath) | ||
io.ErrPrintfln("=== PREC %s", pkg.Dir) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my main point is that here, we should use pkg.Path, which is not the same as any Dir. because "PkgPath/pkgPath/pkgpath/pkg.Path" are all the same "package path" identifier, whereas anything that ends with "Dir" is a filesystem location. They can diverge. Also a package path starts with a domain unless it is special, like a stdlibs package or something special like "main". Dir is a different beast based on the filesystem. Either absolute or relative, not something that starts with "gno.land" nor "main". It might be "." or "./something" though, or "/something". We should ideally make sure all Dirs start with a dot or slash.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree we should print pkg.Path instead of Dir. original var pkgPath
also contains Dir. So this didn't changed anything.
Will fix this. But in another PR. (Out of scope for this PR)
} | ||
precompileOpts := newPrecompileOptions(&precompileCfg{ | ||
output: tempdirRoot, | ||
}) | ||
err := precompilePkg(importPath(pkgPath), precompileOpts) | ||
err := precompilePkg(importPath(pkg.Dir), precompileOpts) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto. importPath should take pkg.Path.
we should use the type system to help here.
notice that in values.go, type PackageValue has Path as a Name type.
a package path is a Name (it is a name in its function).
a package path is a string (like all file paths and dir paths are strings).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok I see that importPath is declared as a type importPath string
.
this is confusing to me.
something is either a package path, in which case we can just use Name.
we could say type packagePath Name
but I don't think it's necessary.
there can be some function that converts a package path to a file path,
but that function would need more context, more than just 1 argument.
it could be a method attached to a structure that holds more context.
Other than such a function, we shouldn't be converting package path Names to file paths or dir paths with type conversions, because nobody should be doing such a thing without calling the official function for such conversions (above).
An "import path" I don't see why we need to create such a name, because it is nothing more than package paths. So ImportPkgPaths is less confusing. Or just Imports of Names.
Any path that is not a package path, should be clearly named as such, by calling it a "file path" or a "dir path" that is a string, never a Name type. Anything like package path, pkgPath, pkg.Path, are all package paths. If you want to associate a file path or a dir path it will have to be called pkg.FilePath or pkg.DirPath.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
original var pkgPath also contains Dir
Yeah, importPath
is confusing. need to modify precompile related code for that. Will fix in another PR (Out of scope for this PR)
continue | ||
} | ||
|
||
sort.Strings(unittestFiles) | ||
sort.Strings(filetestFiles) | ||
sort.Strings(pkg.TestGnoFiles) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GnoTests string
GnoFiletests string
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or TestFiles, FiletestFiles?
// cannot use path.Join or filepath.Join, because we need | ||
// to ensure that ./ is the prefix to pass to go build. | ||
pkg := "./" + parentDir | ||
pkg := parentDir |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would be better also to rename this pkgDir
since pkg is ambiguous, pkgpath or dirpath
@@ -5,40 +5,32 @@ import ( | |||
"io/fs" | |||
"os" | |||
"path/filepath" | |||
"strings" | |||
) | |||
|
|||
type Pkg struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think type Module would be better.
They are all modules, by virtue of having .mod files right?
This differentiates from PackageValue, and amino Package too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I initially had the same thought.
But we don't seem to use word module anywhere.
We only use the word pkg
(and pkg with state = realm)
path string | ||
draft bool | ||
requires []string | ||
Dir string // absolute path to package dir |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dir here is fine but there should also be a PkgPath.
Module.PkgPath Name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have Name string
field for pkg name/path.
Maybe rename it to Path? (s/Name/Path
)
Draft bool // whether the package is a draft | ||
} | ||
|
||
type SubPkg struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't have anything called Sub*.
From the perspective of Go/Gno, "sub" packages are just independent packages.
We can have maybe one utility function that returns all "sub" Modules inside a dir, but that should be about it. (And btw the filetests folder once we support that, is not itself a module. For safety we should also disallow a module in a folder with that name too).
Dir string // absolute path to package dir | ||
ImportPath string // import path of package | ||
Root string // Root dir containing this package, i.e dir containing gno.mod file | ||
Imports []string // imports used by this package |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ImportPaths []Name // I think ImportPkgPath is just too long.
or
ImportDirs []string // but I don't think this is what we want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have ImportPath string // import path of package
Don't you think ImportPaths []Name
will make things more confusing?
ImportDirs []string
? No. since they are not dirs
|
||
GnoFiles []string // .gno source files (excluding TestGnoFiles, FiletestGnoFiles) | ||
TestGnoFiles []string // _test.gno source files | ||
FiletestGnoFiles []string // _filetest.gno source files |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe
FilePaths []string
TestFilePaths []string
FiletestFilePaths []string
BTW we might support other langauges that compile to .gno, like .gnoffee
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original thought process behind this is to have pkg in a structured/sorted/filtered way.
If we want to support another language we can easily add another field here.
e.g. PyFiles []string
GnoffeeFiles []string
...
This way we can apply specific operations on them accordingly.
e.g.
GnoffeeFiles []string
- needs to be compiled to .gno
GnoFiles []string
- vm understands it natively
TestGnoFiles []string
- if you wants to run tests, these are your files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merging now, since the logic is good.
The wording concerns who were not introduced by this PR but already there, will be fixed in an upcoming PR, asap.
…ng#945) Fix bug where `gno test` command doesn't recognize `_test.gno`/`_filetest.gno` file if directly passed as arg. Fixes another bug where `gno test` avoids absolute path in arguments. Note: This PR may contain some code that will be used to support future PR like gnolang#682 and PR that I will open after this to support patterns in arg.
Fix bug where
gno test
command doesn't recognize_test.gno
/_filetest.gno
file if directly passed as arg.master:
harry-hov:hariom/gno-test-improv:
Fixes another bug where
gno test
avoids absolute path in arguments.master:
harry-hov:hariom/gno-test-improv:
Note: This PR may contain some code that will be used to support future PR like #682 and PR that I will open after this to support patterns in arg.
Checklists...
Contributors Checklist
BREAKING CHANGE: xxx
message was included in the descriptionMaintainers Checklist
CONTRIBUTING.md
BREAKING CHANGE:
in the body)