python-active-version starts from python3.8 due to walrus operator

The way this is detached from what check-python-versions does, I think it might be better if https://pypi.org/p/python-active-versions/ itself had a command-line script that prints this information.

I do not wish to accept it in the form it currently is in.

python-active-version starts from python3.8 due to walrus operator

That's another reason not to introduce it as a dependency. I have no plans of dropping 3.7 in the near future.

The way this is detached from what check-python-versions does, I think it might be better if https://pypi.org/p/python-active-versions/ itself had a command-line script that prints this information.

It would be amazing if I could do

pipx run python-active-versions

and see that information, especially in contexts where check-python-versions doesn't work (the current working directory is not a Python package).

Maybe I should file a wishlist bug in https://github.com/gpongelli/python-active-versions ?

detached from what check-python-vers

Yes, feel free to fire an issue about CLI tool 😉

It would be amazing if I could do

pipx run python-active-versions

and see that information, especially in contexts where check-python-versions doesn't work (the current working directory is not a Python package).

I'm not used to pipx, what does pipx run do ? launches a cli tool named python-active-versions ?

Maybe I should file a wishlist bug in https://github.com/gpongelli/python-active-versions ?

Yes, you can 😉

pipx is a very nice tool to manage command-line applications written in Python. It creates isolated virtualenvs for you behind the scenes (in ~/.local/pipx/) and symlinks their scripts into a directory on your $PATH (~/.local/bin). I use pipx install to get the latest build tools like tox or virtualenv or coverage or check-python-versions, and then I periodically pipx update-all to keep them up-to-date.

pipx run is a command to try out new tools you're considering using but haven't decided if you want to install them permanently or not, inspired by a similar tool in the NPM ecosystem (npx?). When you pipx run check-python-versions, it will create a temporary virtualenv, pip install check-python-versions inside it, and then run the check-python-versions script from that venv. There's some caching so it won't have to pip install again if you pipx run the same thing a few times in a row. This works great when the name of the script matches the name of the PyPI package.

pipx is a very nice tool to manage command-line applications written in Python. It creates isolated virtualenvs for you behind the scenes (in /.local/pipx/) and symlinks their scripts into a directory on your $PATH (/.local/bin). I use pipx install to get the latest build tools like tox or virtualenv or coverage or check-python-versions, and then I periodically pipx update-all to keep them up-to-date.

pipx run is a command to try out new tools you're considering using but haven't decided if you want to install them permanently or not, inspired by a similar tool in the NPM ecosystem (npx?). When you pipx run check-python-versions, it will create a temporary virtualenv, pip install check-python-versions inside it, and then run the check-python-versions script from that venv. There's some caching so it won't have to pip install again if you pipx run the same thing a few times in a row. This works great when the name of the script matches the name of the PyPI package.

Clear, seems something similar to poetry (env isolation, dependency installation and script run).

anyway I’ve just pushed version 1.4.0 that adds command line script.

looking deeper into python-active-version, I saw I'm not using walrus operator, so I'm going to see if all works since python3.7 , before release next 1.5.0 (just released).

@mgedmin I've released the python-active-version 1.5.0 that works also on python 3.7 and adds a console script, let me know if you're still interested on integrating it here.

As I said before, warning about using EOL versions (i.e. #36) is not a bad idea, but it's pretty low on my priority list. I'm still not sure if I want to depend on python-active-version for the implementation.

Hm, if I do end up depending on it, I could maybe replace the hardcoded CURRENT_PYTHON_VERSION as well. Eh, it's hard to decide, I don't want check-python-versions to stop working when offline.

Hm, if I do end up depending on it, I could maybe replace the hardcoded CURRENT_PYTHON_VERSION as well. Eh, it's hard to decide, I don't want check-python-versions to stop working when offline.

I understand. Network exception are not caught into the package, so probably a compromise could be to use hardcoded CURRENT_PYTHON_VERSION when catching them (just an idea, don't know if it's feasible) .