[RFE] Micropipenv get-python-version

[frenzymadness]

Given these two facts:

• micropipenv is able to parse all the .lock and pyproject files and
• micropipenv is not able to create a Python virtual environment

it might make sense to implement a new command get-python-version. The new command would basically just print out the information about the Python version the configuration is prepared for.

Let's say I'd like to use micropipenv instead of pipenv in an automated script for deploying applications. I'm able to create my own virtual environment for the application but I need to know which Python version to use. And this is the spot micropipenv can help me. All the logic to find the proper file and parse all the JSONs or TOMLs is already there so this new feature would enable us to do something like:

PYTHON_VERSION=`micropipenv get-python-version`
python$PYTHON_VERSION -m venv venv
source venv/bin/activate
micropipenv install

@encukou I hope that I described your idea correctly.

This is slightly related to #187

Possible problems to solve:

• requirements.txt files do not contain Python version, what to return in this case?
• poetry can use version specifiers like ==3.6.7 or >=3.6.7 or worse ^3.7, what version return in case of such ranges?
• pipfile should contain only one version and it's generated there automatically but the specification is kinda vague and it seems to me that a pipfile without python_version is valid and pipenv works fine in that case without any issues of warnings.

[encukou]

One idea would be a filter-python-versions command.
Given a file like:

3.9.7
3.8.12
3.7.12
3.6.15
3.5
3.10.0rc2

then cat versions | micropipenv filter-python-versions would output all versions that match: all of them for requirements.txt; matching ones for Poetry; only the configured one for pipenv with python_version; all of them for pipenv without python_version.

Creating the list (and possibly ordering it by desrability) would be left to the caller, as would choosing a default/error if the result is empty.

[fridex]

+1 on my side, the extension sounds reasonable.

Possible problems to solve:

• requirements.txt files do not contain Python version, what to return in this case?

It might be a good idea to end with an error here - following "Explicit is better than implicit." Then, let the user decide which version to use. Alternatively, create a flag like --default-sys-executable that would default to the Python available in sys.executable in these cases.

• poetry can use version specifiers like ==3.6.7 or >=3.6.7 or worse ^3.7, what version return in case of such ranges?

The lowest matching might make sense here. Maybe create a flag that would assist in choosing the appropriate version in this case as well.

[goern]

/kind feature
/priority backlog

[sesheta]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[fridex]

/remove-lifecycle stale

[sesheta]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[harshad16]

/lifecycle frozen