Add show latest command that prints latest version that conform to contraints

[MatthewJohn]

Issue #301

[yermulnik]

• Should we deem feat: allow to show required by module version explicitly #301 obsolete and close in favour of this PR? (I'm closing that PR for now)
• Do we need any tests for this new arg?
  • On a side note, we probably may need to look into restraining simultaneous use of cmdline args that are not compatible with each other (I mean this is a thought aloud)
• I added commit suggestions to try and align this new arg with what it actually does (e.g. when version is provided via command line, this new arg does not show latest required, but outputs version requested on command line. same for version parameter in TOML. so on by means of all of the ifs from lib/param_parsing/parameters.go). WDYT?
• Let me know if you'd like me to postpone new version release for --arch arg to get this PR added to the same release (or to cut next release for it later)

[yermulnik]

Suggested change

	params.ShowLatestRequiredFlag = false
	params.ShowRequired = false

[yermulnik]

Suggested change

	case parameters.ShowLatestRequiredFlag:
	/* show latest stable version within constraints */
	lib.ShowLatestRequiredVersion(parameters.MirrorURL, parameters.Version)
	case parameters.ShowRequired:
	/* show version requested by configuration */
	lib.ShowRequiredVersion(parameters.MirrorURL, parameters.Version)

[warrensbox]

openAI

• Should we deem feat: allow to show required by module version explicitly #301 obsolete and close in favour of this PR? (I'm closing that PR for now)

• Do we need any tests for this new arg?

  • On a side note, we probably may need to look into restraining simultaneous use of cmdline args that are not compatible with each other (I mean this is a thought aloud)

• I added commit suggestions to try and align this new arg with what it actually does (e.g. when version is provided via command line, this new arg does not show latest required, but outputs version requested on command line. same for version parameter in TOML. so on by means of all of the ifs from lib/param_parsing/parameters.go). WDYT?

• Let me know if you'd like me to postpone new version release for --arch arg to get this PR added to the same release (or to cut next release for it later)

Do we need any tests for this new arg?

• This would be ideal

On a side note, we probably may need to look into restraining simultaneous use of cmdline args that are not compatible with each other

• I think we have had checks in the past to check this. It's worth checking this again

• fair commit suggestions

Let me know if you'd like me to postpone new version release for --arch arg to get this PR added to the same release

• I suggest 2 different releases, incase we need to roll back any of this new features

@yermulnik feel free to do the deployments for the release

[MatthewJohn]

Do we need any tests for this new arg?

Given the argument just prints to stdout and we don't have any mocking, I wonder if updating the function to return the string that is displayed to the user back to main.go might make this a lot easier? Without it, I'm not sure the easiest way to do it in golang.

On a side note, we probably may need to look into restraining simultaneous use of cmdline args that are not compatible with each other

The other argparsers I've seen have got this kind of functionality, but can't see viper does - assume it's something you had to do manually in the past?

I suggest 2 different releases, incase we need to roll back any of this new features

👍

I added commit suggestions to try and align this new arg...

Yes, I agree none of it makes much sense given it's high dependency on the argument parsing - it's somewhat of a shame that this is all done magically behind before the main case statement. Happy with any name, since it's just printing a pre-defined version argument.
Given all this, I can't see that the function is of much use at all as a third-party library (I guess, ideally it could be private).
If we do think it's completely unusued publicly, then maybe merging the function with ShowLatestVersion would make sense?

[yermulnik]

If we do think it's completely unusued publicly, then maybe merging the function with ShowLatestVersion would make sense?

I like the ShowRequired/ShowRequiredVersion naming as it reflects what this feature outputs. WDYT?

[yermulnik]

• I suggest 2 different releases, incase we need to roll back any of this new features

@yermulnik feel free to do the deployments for the release

@warrensbox @MatthewJohn
I went with minor version bump: v1.3.0
Please review #539 and I'll cut v1.3.0 release once approved.

[yermulnik]

@MatthewJohn Will you be giving this PR some love? =)

[MatthewJohn]

Hey sorry, Had a little birth in the family - will take a look in tje next 24h when I’m next awake :)

…

Sent from my iPhone

On 5 Feb 2025, at 12:50, George L. Yermulnik ***@***.***> wrote:  @MatthewJohn Will you be giving this PR some love? =) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[yermulnik]

Hey sorry, Had a little birth in the family - will take a look in tje next 24h when I’m next awake :)

Ah, congrats 🥳 Take your time and take some sleep =)))