Upgrade and unpin python dependencies

[bartsanchez]

No description provided.

[boriel]

I'm unsure about this strategy.
I.e. mypy ^1.0.0 is equivalent to 1.*. Leaving the door open that way can break many things.
And even doing that, you will have to poetry update from time to time.

In other words: I would pin the major versions (as with mypy) and do a poetry update periodically to upgrade the .lock file.

[bartsanchez]

Since you have a lockfile you can't break anything until you execute the poetry update command. The version is already pinned in the lock file. See this as an example.

I would say the purpose of the lockfile is to pin the versions, so I don't see the point of also pin them in the pyproject (unless there is version that really breaks your code and then you can pin in the pyproject until you fix the issue).

Right now, by unpinning them there are no tests failing. This does not mean that there are no bugs but, unless you pin the versions forever you will end up discovering them at some point.

However, feel free to close this PR if you think it's not helping.

[boriel]

I'm now having inconsistent buids with ruff.
See https://github.com/boriel-basic/zxbasic/actions/runs/13872541425/job/38820924869

For example, some build fail now in my laptop, others in the pipeline, and for different reasons. Forcing poetry update does not seem to fix the issue.

[bartsanchez]

@boriel This is the Ruff version that was used by the CI job: 0.9.4.

Which one do you have in your laptop?

Forcing poetry update does not seem to fix the issue.

Maybe this is the root cause of the problem. Probably you don't want to run poetry udpate but poetry install to just use the software versions that are living in the lockfile.

[boriel]

Never mind. I recreated my virtualenv and it passed. Weird.

[bartsanchez]

Closing this PR.