This role ensures that a specific pip-installable command is
available.
Example usage:
- role: ensure-python-command
vars:
ensure_python_command_name: poetry
ensure_python_command_version: ==1.8.5 # omit to install latest
In this case, if the `poetry` command is not already available, pip will
install it in a new venv. Either way, after running this role, the
`ensure_python_command_executable` variable will hold the full path to
the command.
We already have similar roles for specific commands:
- ensure-nox
- ensure-poetry
- ensure-pyproject-build
- ensure-tox
- ensure-twine
- ensure-uv
These roles are essentially copies of each other with different command
names. This new role consolidates that code. The existing roles now act
as wrappers that just set variables and call the new role.
> Note: The `ensure-tox` role has not been refactored due to exclusive
> legacy code related to Python 2, which must be removed first.
The new role introduces three variables to replace the overloaded
`ensure_<command>_executable` variable from the other roles:
- `ensure_python_command_name` (input, command name)
- `ensure_python_command_existing` (input, existing path for the command)
- `ensure_python_command_executable` (output, detected/installed path)
This separation avoids using the same variable as both input and output,
which can cause issues due to Ansible's variable precedence rules:
https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html
Understanding variable precedence
...
19. set_facts / registered vars
20. role (and include_role) params
...
Since we use `set_fact` inside the role, it is ineffective when the same
variable is also passed as a role parameter :/
I'm not adding tests for the new role because its functionality is
already covered by the existing tests for all the refactored roles:
- test-playbooks/ensure-nox.yaml
- test-playbooks/ensure-poetry.yaml
- test-playbooks/ensure-pyproject-build.yaml
- test-playbooks/ensure-twine.yaml
- test-playbooks/ensure-uv.yaml
Change-Id: Idd970cb31bd928576bca3602ce96fbc491ecdb60
Install twine into a venv and set appropriate environment
variables. Also added tests.
Based on commit adding `ensure-nox` (77b1b24) role.
Related-bug: #2095514
Change-Id: Ibb4e89f79879b4d0ae0294440c9c0b79fc57a7fa
Newer ansbile-lint finds "when" or "become" statements that are at the
end of blocks. Ordering these before the block seems like a very
logical thing to do, as we read from top-to-bottom so it's good to see
if the block will execute or not.
This is a no-op, and just moves the places the newer linter found.
Change-Id: If4d1dc4343ea2575c64510e1829c3fe02d6c273f
This was added with I55ef79bf9c5af9e4d1da24ed654821277edb663b but
unfortunately breaks the OpenDev use where this runs on the executor
and doesn't have sudo. Let's just leave it the way it was.
Change-Id: I2cf4224228860b8a2cddd360636bb8633967b07e
Make the default twine python installation use "python3". Use the
ensure-pip role before calling pip.
This role currently isn't tested; it is added with upload-pypi testing
in the follow-on Ie40ec32b3b2ffc4646301c6e145c527fe6a3bae2
Change-Id: I55ef79bf9c5af9e4d1da24ed654821277edb663b
This dependency was added with
Iaf4da5aedaa3814b2ecebed4391da2324d3e388d to prevent a warning when
using "twine check" with text/markdown descriptions.
Per [1], this check doesn't really do anything and will never fail.
We are now having issues using this role with with Python 3.8 on the
executor as the md dependency pulls in cmarkgfm which has binary
dependencies but does not publish any wheels; meaning the executor
fails to install as it does not have a toolchain setup. Unfortunately
upstream is not particularly active, so building good manylinux wheels
is not something we're going to be able to deal with in a timely
fashion.
Given that this is not a failure, and isn't really doing anything and
blocks Python 3.8, it seems our best course is to remove this
dependency.
[1] https://github.com/pypa/twine/pull/421
Change-Id: Iac5c9f63d41375889e4fdad67b9a45a24a644341
On a static node where twine isn't present in the PATH, twine would be
always reinstalled even if already present in venv because it's not checked.
This patch adds twine pip check, the first matching line is used to get
executable path
Change-Id: I2c972147269bf717c30f093975ca6349bed68fbe
While making test with a node:
- with tox installed using "pip install --user" as a non-root user
- PATH modified using ~/.ssh/environment
- declared in nodepool to run as this non-root user
twine executable is not found:
using "command": twine is not found
using "shell" without /bin/bash: twine is not found
using "shell" with /bin/bash: twine is found!
Change-Id: Ia06218a830b5d44f04e0f10e0444be2cf9ad682e
This reverts commit a874df58650a8893c54f6cd6adff40522a7f03fc
and follow on fix 9674e1d442869e22256de045a51a274c7742eada.
Change-Id: I6bcc4ca9025cd26f2c9c7bb5dce8e6dcf09db485
Formatting output for printing out python environment information was
incorrect. This fixes the debug task.
Change-Id: Id33157eb52267e1646a42587777fd974340932d3
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This looks up some runtime environment information and emits it for
debugging.
Change-Id: I7ac121f38d4e01e4f0a2a51199a8da5d055c5030
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This release of requests-toolbelt expects pyOpenSSL to be installed for
urllib3, but does not have it in its default requirements. This is being
tracked in [0], so should be fixed post 0.9.0. For now, block the use of
the 0.9.0 version.
[0] https://github.com/requests/toolbelt/compare/0.8.0...0.9.0
Change-Id: I06445adaaeecf244f6482b6db26db58a09426489
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Add twine_python so we can control the version of python used to
install twine.
Change-Id: I36ddbdf78f549ddc022cce86f3ada9631fb19c37
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
block allows adding a name - but it's not actually emitted anywhere in
the logging. So while this documents the source code, it's not reflected
in logging.
I just happened to learn this elsewhere.
Change-Id: I95362ed94418144e332f7289b1bfa5b2ade68de7
This didn't work as expected on executor. So, now pip install
depending on the rc status of which.
Change-Id: Icd9da523d220973c66bc7cb4fbbd9999ec6c0dd0
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
