#492.1 attempt

[ariady-putra]

An attempt to do #492 point 1:

• The --version option on aiken add could be made optional; when not provided, the dependency will be added considering only the default branch

aiken add <PACKAGES>:

Initial Condition	Add Packages	Result
aiken.toml:	aiken add:	aiken.toml:

When no --version provided, it will try to get the package version with the following order:
↳ LatestRelease - if no non pre-release version, then ↴
↳ Releases[0] - if no release available, then ↴
↳ MainBranch - if for some reason no branch named master or main, then ↴
↳ Branches[0] - should be available, but for the sake of completeness ↴
↳ Tags[0] - if everything fails, then version will be main

Since packages upgrade command calls the add command with overwrite: true, so
aiken packages upgrade <PACKAGE>:

Initial Versions	Upgrade Packages	Result
aiken.toml:	aiken packages upgrade:	aiken.toml:

Note: Free Github API has rate limit, so it's still preferable to provide --version for now

[KtorZ]

Hey! Thanks for looking into this and for the nice PR :o !

I haven't looked at the code yet, but from a high-level "requirements" perspective:

• When no version is provided, use the default branch set by the repository. That's all. No need for a more elaborate strategy. If there's no version given then there's no point sticking to a particular version. So I think you can greatly simplify the heuristic you've outlined in the PR.

[rvcas]

@KtorZ I kinda like what's going on here with automatically getting the latest tag, I think that's a good work flow.

[KtorZ]

I am not sure. That's an implicit behavior which may lead to confusion. If you've never asked to install version 1.8.0 then why would you tie your app to that version. Then people might get confused because they can't use something they see in the doc but that's not yet released.

Plus, many library maintainers are often very lenient on the tagging and only really tag new versions when asked. Hence the latest tag may be months behind the main branch.

So, I believe the only raisonnable behavior to adopt when no version is specified is to stick with the latest. The true latest. Any other implicit choice made on behalf of the user may lead to confusion.

[rvcas]

Hm I see and I guess these assumptions start to change slightly when we finally introduce a proper package registry. There's definitely a lot that can be done with git based package management considering Go has a good setup now but I think it's also awkward for the reasons you mentioned.

[ariady-putra]

Hey I didn't mean to re-push this (forgot to create a sub-branch -_-), I wanted to discuss first.

@KtorZ

• When no version is provided, use the default branch set by the repository. That's all. No need for a more elaborate strategy. If there's no version given then there's no point sticking to a particular version. So I think you can greatly simplify the heuristic you've outlined in the PR.

The reason was, by setting the version to main, overtime it might break. For example: from stdlib v1.4.0 to v1.5.0, with the introduction of and,or blocks.

Most repo would have main as the default branch. After trying f2a5b5a for a while, I don't find the experience is good. There's a noticable waiting time even after setting the timeout to 5 seconds (my internet connection is slow during certain hours), and most of the time in the end it only set version to main 😅 it's not worth the wait to query IMO.

I tried to set the default version to the last commit of the default branch, but it's weird looking,

$ ../aiken add aiken-lang/stdlib
      Package aiken-lang/stdlib
        Added version → d551c2581fb0a46b6d7b7145365e5ab8fafb0b40

might be better to tell the user to manually select the commit hash themselves.