Skip to content
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

feat: support for reuse_venv option #730

Merged
merged 12 commits into from
Feb 25, 2024

Conversation

samypr100
Copy link
Contributor

Closes #488

This PR introduces a new option reuse_venv at the CLI and nox.options level as discussed in #488. It takes 4 possible values, namely no, yes, never, and always as discussed in the issue.
The code that evaluates if a venv should be reused has been switched to use this new option, and backwards compatiblity with reuse_existing_virtualenvs is kept using appropriate finalizer_func and merge_func on _options.py.

I've added tests to test new functionality as well do backwards compatibility checks and hopefully 🤞 updated the docs properly. I also added a new fixture generate_noxfile_options that helps with more dynamic configuration of resources/noxfile_options.py used in the tests to reduce boilerplate.

@johnthagen
Copy link
Contributor

@theacodes We're excited to get to use this feature, was wondering if you were able to review or your thoughts? Thanks!

@johnthagen
Copy link
Contributor

@FollowTheProcess Would you be willing to review this MR? Thanks.

nox/_options.py Outdated Show resolved Hide resolved
@funkyfuture
Copy link

funkyfuture commented Dec 16, 2023

i only looked on the user docs and i'm wondering:

  • could always and never be used for nox.options.reuse_venv?
  • if so, do these values make any sense at that level / should they be disallowed to protect users from confusion?

thanks for the feature implementation!

@funkyfuture
Copy link

the prose about the feature and its usage is fine, but as a user i think the section would aso benefit from a summary such as #488 (comment) or a table.

Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
@henryiii
Copy link
Collaborator

henryiii commented Feb 24, 2024

--reuse-venv is a bit longer then --reuse (and you always have to specify a value, too, so it's a little lengthy on the command line, but the current long option is --reuse-existing-virtualenvs. The option draws a parallel with reuse_venv: bool = ... in the sessions, so I would be okay with the longer from, but wouldn't object at all to the shorter --reuse either, especially since there's not a short option for it.
Anyone have thoughts? Otherwise, this looks good to me.

nox/sessions.py Outdated
# sessions marked True will always be reused unless never is specified
self.func.reuse_venv is True
and self.global_config.reuse_venv != "never",
# session marked False will never be reused unless always is specified
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment doesn't relate to the code below

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to clarify this function with even more documentation here 715bc9a, let me know if it's better.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is super helpful

@@ -422,7 +475,8 @@ def _tag_completer(
"--no-reuse-existing-virtualenvs",
),
group=options.groups["environment"],
help="Reuse existing virtualenvs instead of recreating them.",
help="This is an alias for '--reuse-venv=yes|no'.",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd love to see this called out in the docs as well

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be in the docs, near the end of this statement in config.rst:

* ``nox.options.reuse_existing_virtualenvs`` is equivalent to specifying :ref:--reuse-existing-virtualenvs . You can force this off by specifying ``--no-reuse-existing-virtualenvs`` during invocation. Alias of ``nox.options.reuse_venv``.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs should state explicitly that --reuse-venv=yes is equivalent to --reuse-existing-virtualenvs.

I'm happy for this to land as-is though. We probably want to deprecate the longer version anyway.

(OT: It might also be a nice improvement to allow specifying --reuse-venv without a value, defaulting to yes.)

Copy link
Contributor Author

@samypr100 samypr100 Feb 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, I didn't explicitly deprecate it on this PR but it can be done so in a follow up one. When that happens I think it makes sense to augment --reuse-venv (or add --reuse/--no-reuse like @henryiii prefers) to default to yes when specified. Note -r is a valid shorthand for --reuse-venv=yes since it's a shorcut to --reuse-existing-virtualenvs .

Copy link
Contributor Author

@samypr100 samypr100 Feb 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs should state explicitly that --reuse-venv=yes is equivalent to --reuse-existing-virtualenvs.

Done in fdf876c and 88d11b7

@cjolowicz
Copy link
Collaborator

cjolowicz commented Feb 24, 2024

Personally I like the more explicit --reuse-venv. There are other things one might "reuse" (wheels?). AFAIU -r also becomes a short option for --reuse-venv=yes since it's equivalent.

@cjolowicz cjolowicz merged commit 5a097cd into wntrblm:main Feb 25, 2024
22 checks passed
github-actions bot pushed a commit to msclock/sphinx-deployment that referenced this pull request Mar 4, 2024
## [0.0.20](v0.0.19...v0.0.20) (2024-03-04)

### Chores

* **deps:** bump wntrblm/nox from 2023.04.22 to 2024.03.02 ([#57](#57)) ([d177375](d177375)), closes [wntrblm/nox#762](wntrblm/nox#762) [wntrblm/nox#787](wntrblm/nox#787) [wntrblm/nox#730](wntrblm/nox#730) [wntrblm/nox#780](wntrblm/nox#780) [wntrblm/nox#770](wntrblm/nox#770) [wntrblm/nox#707](wntrblm/nox#707) [wntrblm/nox#687](wntrblm/nox#687) [wntrblm/nox#756](wntrblm/nox#756) [wntrblm/nox#652](wntrblm/nox#652) [wntrblm/nox#712](wntrblm/nox#712) [wntrblm/nox#781](wntrblm/nox#781) [wntrblm/nox#786](wntrblm/nox#786) [wntrblm/nox#684](wntrblm/nox#684) [wntrblm/nox#723](wntrblm/nox#723) [wntrblm/nox#725](wntrblm/nox#725) [wntrblm/nox#714](wntrblm/nox#714) [wntrblm/nox#715](wntrblm/nox#715) [wntrblm/nox#696](wntrblm/nox#696) [wntrblm/nox#774](wntrblm/nox#774) [wntrblm/nox#782](wntrblm/nox#782) [wntrblm/nox#722](wntrblm/nox#722) [wntrblm/nox#724](wntrblm/nox#724) [wntrblm/nox#721](wntrblm/nox#721) [wntrblm/nox#744](wntrblm/nox#744) [wntrblm/nox#738](wntrblm/nox#738) [wntrblm/nox#762](wntrblm/nox#762) [wntrblm/nox#787](wntrblm/nox#787) [wntrblm/nox#730](wntrblm/nox#730) [wntrblm/nox#780](wntrblm/nox#780) [wntrblm/nox#770](wntrblm/nox#770) [wntrblm/nox#707](wntrblm/nox#707) [wntrblm/nox#687](wntrblm/nox#687) [wntrblm/nox#756](wntrblm/nox#756) [wntrblm/nox#652](wntrblm/nox#652) [wntrblm/nox#712](wntrblm/nox#712) [wntrblm/nox#781](wntrblm/nox#781) [wntrblm/nox#786](wntrblm/nox#786) [wntrblm/nox#684](wntrblm/nox#684) [wntrblm/nox#723](wntrblm/nox#723) [wntrblm/nox#725](wntrblm/nox#725) [wntrblm/nox#714](wntrblm/nox#714) [wntrblm/nox#715](wntrblm/nox#715) [wntrblm/nox#696](wntrblm/nox#696) [wntrblm/nox#774](wntrblm/nox#774) [wntrblm/nox#782](wntrblm/nox#782) [wntrblm/nox#722](wntrblm/nox#722) [wntrblm/nox#724](wntrblm/nox#724) [wntrblm/nox#721](wntrblm/nox#721) [wntrblm/nox#744](wntrblm/nox#744) [#789](https://github.com/msclock/sphinx-deployment/issues/789) [#787](https://github.com/msclock/sphinx-deployment/issues/787) [#786](https://github.com/msclock/sphinx-deployment/issues/786) [#781](https://github.com/msclock/sphinx-deployment/issues/781) [#784](https://github.com/msclock/sphinx-deployment/issues/784) [#780](https://github.com/msclock/sphinx-deployment/issues/780) [#730](https://github.com/msclock/sphinx-deployment/issues/730) [#782](https://github.com/msclock/sphinx-deployment/issues/782) [#783](https://github.com/msclock/sphinx-deployment/issues/783) [#762](https://github.com/msclock/sphinx-deployment/issues/762)

### CI

* set proper permission for preview job ([#56](#56)) ([d65e8a1](d65e8a1))
@samypr100 samypr100 deleted the new-global-option-reuse-venv branch November 3, 2024 23:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] --no-reuse-existing-virtualenvs doesn't seem to work
6 participants