-
Notifications
You must be signed in to change notification settings - Fork 7
feat: allow custom name #60
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
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #60 +/- ##
==========================================
+ Coverage 39.68% 41.95% +2.27%
==========================================
Files 32 35 +3
Lines 1968 2052 +84
==========================================
+ Hits 781 861 +80
+ Misses 1089 1083 -6
- Partials 98 108 +10 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Co-authored-by: 张之阳 <51194195+luoliwoshang@users.noreply.github.com>
|
[Git-flow] Hi @MeteorsLiu, There are some suggestions for your information: Rebase suggestions
Which seems insignificant, recommend to use For other DetailsIf you have any questions about this comment, feel free to raise an issue here: |
| t.Run("one-go-file", func(t *testing.T) { | ||
| tempGoFileName := filepath.Join(demoDir, "x.go") | ||
| err := os.WriteFile(tempGoFileName, []byte(`package libcjson`), 0644) | ||
| if err != nil { | ||
| t.Error(err) | ||
| return | ||
| } | ||
| defer file.RemovePattern(filepath.Join(demoDir, "*.go")) | ||
|
|
||
| checkName(t, demoDir, false) | ||
| }) | ||
|
|
||
| t.Run("multi-go-files", func(t *testing.T) { | ||
| tempGoFileName1 := filepath.Join(demoDir, "a.go") | ||
| err := os.WriteFile(tempGoFileName1, []byte(`package libcjson`), 0644) | ||
| if err != nil { | ||
| t.Error(err) | ||
| return | ||
| } | ||
| tempGoFileName2 := filepath.Join(demoDir, "x.go") | ||
| err = os.WriteFile(tempGoFileName2, []byte(`package cjson`), 0644) | ||
| if err != nil { | ||
| t.Error(err) | ||
| return | ||
| } | ||
| defer file.RemovePattern(filepath.Join(demoDir, "*.go")) | ||
|
|
||
| checkName(t, demoDir, false) | ||
| }) |
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.
table-driven test maybe is also better
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.
Some tests require multiple files, these logics cannot be reused.
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.
Perhaps could use a slice like []struct{name, content string} to hold each file’s name and content, and then simply loop over that slice to write out the files—it should work just fine.
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 in that case, simply use t.Run may be better, should we change to table-driven style?
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.
What needs to be clarified is that t.Run is merely the mechanism for running subtests, whereas table-driven is a testing style—they are not mutually exclusive. In this case, we can embed t.Run within a table-driven setup to avoid repeatedly writing and cleaning up files.
and in this case,we actual have four similar test case,like,multi-go-files-fallback,no-go-files,multi-go-files,one-go-file,it have redunant logic here.
| // cfg: Package configuration | ||
| func (d *DefaultClient) checkVersion(ver *versions.Versions, cfg config.LLPkgConfig) error { | ||
| func (d *DefaultClient) checkVersion(ver *mappingtable.Versions, pkg *llpkg.LLPkg) error { | ||
| // 4. Check MappedVersion |
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.
some comment like this is deprecated
| type LLPkg struct { | ||
| cfg config.LLPkgConfig | ||
|
|
||
| packageName 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.
NIT:indicate where to fetch the packageName to reduce misunderstandings—after all, this update introduces two package names
| packageName string | |
| packageName string // package name from go file. |
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.
And this field's type consist with PackageName as other struct is better ? the PackageName describe the custom name of llpkg.
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.
Exporting PackageName will make it mutable, which it's not expected. packageName should be only readable after initialization
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 mean packageName 's type change string to type PackageName
Changes for custom name:
llpkgstore generateretrieve the package name from user-provided directory name for generatingllcppg.cfgllpkgstore verficationretrieve the custom name from parsing the last element of module path ingo.mod.For example,
go.mod:
Its custom name is
libcjsonCheckPRfinds out the realllpkgroot directory containingllpkg.cfg/llcppg.cfg/go.modfrom all changed files.The name in
llpkg.cfgwill be only used inllpkgstore.json.To clarify their difference,ClibNamerepresents the name inllpkg.cfgwhileNamerepresent the actual name(custom name).Release-as:directive must match the custom name, not the clib name, likedirectory structure:
Its
Release-as:directive is likeRelease-as: libcjson/v1.0.0Test: MeteorsLiu/llpkg#78
https://github.com/MeteorsLiu/llpkg/actions/runs/14690247173