allow unfinished version when pinning custom toolchain

[T-256]

>rye pin x86@3.7
Error: unsupported/unknown version for this platform

>rye pin x86@3.7.9
pinned x86@3.7.9 in .python-version

>rye pin 3.7
pinned 3.7.9 in .python-version

>rye pin cpython@3.7
pinned 3.7.9 in .python-version

>rye pin cpython@3
pinned 3.11.3 in .python-version

>

IMO it could allow even rye pin x86 (without any version) and use its latest version available.

[mitsuhiko]

Hidden behind this ticket are really two asks:

1. .python-version should encode a version request and not a version itself (eg: 3.7 should ask for latest available 3.7)
2. pin should not try to pin to a specific version

I'm strongly in favor of 1, i'm a bit unsure about how to do 2. I can see two options:

Pin to latest version by default:

rye pin 3.7  # pins 3.7.9
rye pin 3.7 --loose  # pins 3.7

Pin lose by default:

rye pin 3.7  # pins 3.7
rye pin 3.7 --precise # pins 3.7.9

Or a version of that.

[mitsuhiko]

There is also a third ask here which is that for manually registered toolchains, a request also picks the latest available which currently is also not yet supported.

[T-256]

Pin to latest version by default:

rye pin 3.7  # pins 3.7.9
rye pin 3.7 --loose  # pins 3.7

yes, it also makes more sense to me too. (I think loose naming not good here.)
and note that it should not limit to minor part.

> rye pin pypy  # pins [email protected]
> rye pin pypy  --as-is  # pins pypy

[mitsuhiko]

I think I like neither --loose nore --as-is. Maybe --relaxed?

[T-256]

Or --dynamic (that more familiar with me maybe bcz of project.dynamic in pyproject file)
Or --expandable (that points to it would be able expand to the latest version.)

[mitsuhiko]

Most of it is I believe supported in #255 now. Would be nice if you could this this. Note that I did not support rye pin pypy, you need to do rye pin pypy@3 at least. I don't think there is a lot of value in completely version-less pins.

[T-256]

I don't think there is a lot of value in completely version-less pins.

custom toolchains in most of times associated with single version. so that would be nice prevent always write @....

[mitsuhiko]

My biggest worry is that it introduces ambiguous syntax. In theory you can already name your custom tool-chain "1234" too.

[T-256]

it can solve by limit the toolchain naming to match identity stile. (str.isidentifier in py)

[T-256]

it's not that much big problem.