-
-
Notifications
You must be signed in to change notification settings - Fork 523
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Present install_commands instead of only install_command #715
Comments
tox 3.4 introduced commands_pre and commands_post. Maybe the install_command option should be kept as is, but instead install_commands_pre and install_commands_post should be added? |
That could work too, but does feel a little artificially constrained... that you can only have multiple install steps in pre or post, and that the sole install command must stand alone and special. -0 |
So maybe they shall all accept multiple values. |
one way or another - things get rough when you have multiple requirement files/index servers. my case: some of the requirements are on one devpi server, some are on different one. So my tox.ini looks simillar to below:
and the my_custom_script.sh looks like this:
this results in the my_custom_script.sh being invoked twice - once for each of the requirements file. And in such a form it of course fails, as after installing requirements from the "requirements-one" file the second command fails. (TLDR: ) so to sum up - any custom actions that depend on already installed packages (but not instaling packages themselves) should be executed in a separate step - thats why it would be nice to have this install_commands_post feature :) |
I'm piggybacking off of the issue, as I'm in favor of enhancing the My use case is when tox works with tools like Poetry. At the moment, Poetry recommends configuring tox as follows. [tox]
isolated_build = true
envlist = py{36,37}-unit
[testenv]
whitelist_externals = poetry
commands =
poetry install -v
poetry run pytest tests The To that end, I would have liked to configure tox with something along the lines of the config below. [tox]
isolated_build = true
envlist = py{36,37}-unit
[testenv]
whitelist_externals = poetry
install_commands = poetry install -v
commands =
poetry run pytest tests Unfortunately, this raises a For the record, if I add $ tox
.package create: /Users/magus/Development/url-check/.tox/.package
.package installdeps: poetry>=0.12
ERROR: invocation failed (exit code 1), logfile: /Users/magus/Development/url-check/.tox/.package/log/.package-2.log
ERROR: actionid: .package
msg: get-build-requires
cmdargs: "/Users/magus/Development/url-check/.tox/.package/bin/python -c 'import poetry.masonry.api\nimport json\n\nbackend = poetry.masonry.api\nfor_build_requires = backend.get_requires_for_build_sdist(None)\nprint(json.dumps(for_build_requires))'"
Traceback (most recent call last):
File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'poetry' |
@jambonrose I had an idea similar to yours, but I think that I eventually managed to get it to work. I am using a fake [tox]
isolated_build = true
envlist = flake8, py36, py37
skipsdist=True
skip_install=True
[testenv:flake8]
basepython = python3.7
install_command = poetry {packages} -v
whitelist_externals = poetry
commands =
poetry run flake8 package
deps =
install I also had to create an empty |
tox 4 exposes the install API, allowing plugins to implement this. https://github.com/tox-dev/tox/blob/rewrite/src/tox/tox_env/installer.py#L12 |
I present a feature request, inspired by an environment where I wish to install both Python packages and node packages, similar to the request in StackOverflow 37187753.
I propose that instead of having a single command for the install step, tox could expose
install_commands
, which would be more congruous with thecommands
syntax. It could still accept{opts}
and{packages}
substitutions such that one (or more) of the commands could honor those options.I suspect
install_command
was originally meant as a way to provide a bridge for other Python installers, but if the concept could be generalized to provide more functionality for install, much like CI environments do in their install steps. Then, if one wanted to add a node environment to their environment, they could do something like this:The text was updated successfully, but these errors were encountered: