This allows to specify version like `3.11` or `pypy3.10` in workflows before those versions are released.
This lessen the burden for users of `setup-python` by not having to modify their workflow twice: once when a pre-release is available (e.g. `3.11-dev`) and once when the first stable release is published (e.g. `3.11`)
* Use correct Poetry config when collecting Poetry projects
When collecting Poetry projects for caching, a '**/poetry.lock' glob is
used. However, in order to process the Poetry configuration, the
"poetry" command is run from the repo's root directory; this causes
Poetry to return an invalid configuration when there is a Poetry project
inside an inner directory.
Instead of running a single Poetry command, glob for the same pattern,
and run a Poetry command for every discovered project.
* Fix typo: saveSatetSpy -> saveStateSpy
* poetry: Support same virtualenv appearing in multiple projects
* Add nested Poetry projects test
* poetry: Set up environment for each project individually
* tests/cache-restore: Do not look for dependency files outside `data`
When the default dependency path is used for cache distributors, they
are looking for the dependency file in the project's root (including the
source code), which leads to tests taking a significant amount of time,
especially on Windows runners. We thus hit sporadic test failures.
Change the test cases such that dependency files are always searched for
inside of `__tests__/data`, ignoring the rest of the project.
* poetry: Simplify `virtualenvs.in-project` boolean check
* README: Explain that poetry might create multiple caches
* poetry: Run `poetry env use` only after cache is loaded
The virtualenv cache might contain invalid entries, such as virtualenvs
built in previous, buggy versions of this action. The `poetry env use`
command will recreate virtualenvs in case they are invalid, but it has
to be run only *after* the cache is loaded.
Refactor `CacheDistributor` a bit such that the validation (and possible
recreation) of virtualenvs happens only after the cache is loaded.
* poetry: Bump cache primary key
This option allows to specify if the action shall update environment variables (default) or not.
This allows to use the setup-python action in a composite action without side effect (except downloading/installing python if version is missing).
This versioning scheme is consistent with other
tools in the python ecosystem so it feels more natural
and allows better interaction with other tools.
fixes#346
* Rework python-pipenv-dependencies-caching test
* Update Pipfile.lock hash in the tests
* Rework python-pipenv-dependencies-caching-path test
* Set location for pipenv test
* Remove requests package from tests
* Test pipenv without caching
* Enable pipenv cache
* test for pypy new version notation
* formatting
* uncommented condition
* test
* added pypy to test matrix
* test
* test
* restored all tests
* removed logs, added multiarch support for toolcache
* reduced test matrix
* removed extra condition about arch
* Add support of unstable Python versions
* Update README
* Get rid of stable boolean input
* Fix typo in the test.yml
* Update README
Co-authored-by: MaksimZhukov <v-mazhuk@microsoft.com>
This pull-request improves `setup-python` action to add ability to download specific version of Python on flight if it is not available by default.
**Details:**
`setup-python` action will download and install specific Python version from GitHub releases ([actions/python-versions](https://github.com/actions/python-versions/releases)) in case the version is not found in the local cache. All versions of Python available for installation are published in [actions/python-versions](https://github.com/actions/python-versions) repository.
All available versions are listed in the [version-manifest.json](https://github.com/actions/python-versions/blob/master/versions-manifest.json) file.
**Installation time:**
- Ubuntu / macOS: 10-20 seconds
- Windows: ~ 1 minute (mostly related to fact that we use MSI installer for Python on Windows)
Co-authored-by: MaksimZhukov <v-mazhuk@microsoft.com>
Co-authored-by: Konrad Pabjan <konradpabjan@github.com>
Co-authored-by: Brian Cristante <33549821+brcrista@users.noreply.github.com>
