Fix update for pre-release version

[teluq-pbrideau]

Pull Request (PR) description

Fix the resolution of the latest version from the pip repository, by removing the pre-release version from the list of the latest package available. See #690 for details.

NOTE

With this fix, if the pip package is not a stable release, it will need an explicit --pre:

python::pip { 'foo' :
  install_args => '--pre',
}

Another option could be to add a new parameter pre => true, but I chose to use the install_args in the end for this PR, which is more flexible.

This Pull Request (PR) fixes the following issues

Fixes #690

[teluq-pbrideau]

Well, thinking more about it, it is probably better for me to parse install_args for the --pre flag, because it does not create a breaking change… I’ll modify the PR.

[bastelfreak]

Hi @teluq-pbrideau , we recently merged #696 . can you please rebase?

[teluq-pbrideau]

I’ve discovered a potential difference when a package have only pre-release version. I’ve tried with the first package i’ve found with this criteria: glint4py: https://pypi.org/project/glint4py/#history

When package installed with pip install, the package is installed, but with the python::pip class with my change, it is required to add the install_args => '--pre' parameter. Not sure it is desired…

Also, I cannot find a package with pre-release and a previous stable release to test as I did with pip==24.1.b2

[teluq-pbrideau]

@kenyon just to make sure you understood my previous comment:
Every current user of this module will have a breaking change and will have to add install_args => '--pre' if there is no stable release on pypi

[kenyon]

@teluq-pbrideau thanks for the clarification. I'm not using this functionality of this module, so this doesn't really affect me, but it seems like it's OK if you have to explicitly do something to enable installation of prereleases, even if pip itself doesn't behave this way. But maybe we wait for more input from users to see whether the breaking change is acceptable.

I know some tools like pipenv have extra difficulty dealing with prereleases, so this problem has some precedent in the Python world. The popular formatter black caused a lot of consternation for years because it was only a prerelease: psf/black#517

[teluq-pbrideau]

@kenyon I rebase with master, I believe the failure are not related to my changes...

Couldn't find id: {"stream":"STEP 1/10: FROM amd64/debian:11\n"}
Couldn't find id: {"stream":"STEP 1/9: FROM amd64/almalinux:9\n"}