Client's "venv" is never updated

[snazy]

Describe the bug

The ./polaris script sets up the Python venv if the ./polaris-venv directory does not exist, but never updates the dependencies.

This leaves client with outdated libraries and can lead to incompatibilities, but more importantly never pulls security fixes in the dependencies.

This may also break dev-workflows, assuming that the declared dependencies are being used.

There should be a mechanism to at least regularly update the venv dependencies.

To Reproduce

No response

Actual Behavior

No response

Expected Behavior

No response

Additional context

No response

System information

No response

[MonkeyCanCode]

@snazy update every execution may not be ideal as it can be somewhat annoy or introduced unexpected changes. I like the idea about updating the deps regularly. Please take a look at #1222 to see if this address your concern.

[snazy]

update every execution may not be ideal as it can be somewhat annoy or introduced unexpected changes. I like the idea about updating the deps regularly.

Yea - there are different needs. Developers may (or may not) want to update every time, users at some regular pace. I don't have a good idea yet how to achieve that without adding a ton of "bash script magic".

[eric-maynard]

This doesn't sound like a bug

[JacquesT2]

Hello
Just to add to this —
I was setting up Polaris on a fresh VM and realized that python3.12-venv wasn’t installed. Because of that, the script wasn’t able to install any dependencies.

After installing the missing package, I ran the script again, but it still didn’t install any dependencies.
Instead, it threw an error: "No module named 'pydantic'"

[snazy]

I was setting up Polaris on a fresh VM and realized that python3.12-venv wasn’t installed. Because of that, the script wasn’t able to install any dependencies.

That's a legit concern, although not "strictly related" to this PR. But I agree that it's a concern. We should also have a "ready to use" container image for the client.

[JacquesT2]

Yes, I agree —
I’d really love to contribute to the project. I could take this on as a first issue, if you're open to it — perhaps by adding a system that scans for dependencies and checks whether the virtual environment is properly set up and aligned with them, whilst of course benchmarking any differences in run speeds.

[eric-maynard]

@JacquesT2 This does sound problematic though. Was this before or after #1161?

[JacquesT2]

@JacquesT2 This does sound problematic though. Was this before or after #1161?

@eric-maynard I did this today, so after #1161 for sure

[MonkeyCanCode]

@JacquesT2 This does sound problematic though. Was this before or after #1161?

@eric-maynard I did this today, so after #1161 for sure

This is due to running an older venv with the lock file issue mentioned by @eric-maynard . To fix this, run the CLI with --repair. This will update the dependencies in your venv to the latest dependencies defined by poetry. You can find how I was able to reproduce this issue and how this CLI argument fixed the problem in #1222