[WIP] kpm fixes the order of dependencies and format in kcl.mod and kcl.mod.lock

[officialasishkumar]

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

• N
• Y Enhancement: kpm fixes the order of dependencies and format in kcl.mod and kcl.mod.lock #333

2. What is the scope of this PR (e.g. component or file name):

3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Other

4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):

• N
• Y

5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:

• Unit test
• Integration test
• Benchmark (add benchmark stats below)
• Manual test (add detailed scripts or steps below)
• Other

[coveralls]

Pull Request Test Coverage Report for Build 9228658894

Details

• 0 of 13 (0.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.1%) to 43.043%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/package/package.go	0	1	0.0%
pkg/package/modfile.go	0	12	0.0%

Totals
Change from base Build 9221341511:	-0.1%
Covered Lines:	2447
Relevant Lines:	5685

---

💛 - Coveralls

[Peefy]

I think we should use an ordered dictionary for serialization/deserialization instead of simply sorting, as KCL users often do not want unexpected changes to occur.

Besides, [dependencies] section and [profile] section lost the expect newline.

[d4v1d03]

Hey @Peefy , i've done some changes at #334, please have a look over them if they are in the right direction.

[Peefy]

Hey @Peefy , i've done some changes at #334, please have a look over them if they are in the right direction.

@d4v1d03 OK. But we should avoid commenting on irrelevant PRs.

[Peefy]

Add some comments. cc @zong-zhe Could you help review it?

[officialasishkumar]

I will do the required changes.

[zong-zhe]

Hi @officialasishkumar 😃

Good job ! But I have a few different ideas about this feature.

The go community maybe have libraries to help us solve this problem. Try to research some of the libraries and see the possible problems with using them. You can update the results of the research in the issue.

I found a third-party library, https://github.com/elliotchance/orderedmap, but when the library is serialized into a kcl.mod file, there may be some problems, this need you to continue to research.

It's not that your method is wrong, it's just that we need some evidence to show that this method is more appropriate than other methods.

[Peefy]

PR conflict cc @officialasishkumar

[Peefy]

I noticed the function still use the unordered map.

func (local *Local) UnmarshalModTOML(data interface{}) error {
	meta, ok := data.(map[string]interface{})
	if !ok {
		return fmt.Errorf("expected map[string]interface{}, got %T", data)
	}
	if v, ok := meta[LOCAL_PATH_FLAG].(string); ok {
		local.Path = v
	}
	return nil
}

[officialasishkumar]

@Peefy The migration is not yet completed.

[zong-zhe]

Hi @officialasishkumar 😄

This PR conflicts with the main branch, you may need to squash some commits and rebase the main branch.

[zong-zhe]

Hi @officialasishkumar 😄

This PR conflicts with the main branch. Are you still working on it？

[officialasishkumar]

Hi @officialasishkumar 😄

This PR conflicts with the main branch. Are you still working on it？

Yeah, I will complete it. Sorry my exams were running for a few weeks. Now it's over.

[zong-zhe]

Hi @officialasishkumar 😄

I finished this issue for the 0.9.0 release, #373
You'll be able to focus on the LFX now.