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

Use extras instead of deps in tox.ini #445

Merged
merged 1 commit into from
Feb 7, 2024
Merged

Use extras instead of deps in tox.ini #445

merged 1 commit into from
Feb 7, 2024

Conversation

mtelka
Copy link
Contributor

@mtelka mtelka commented Feb 6, 2024

The current specification of test dependencies via the deps keyword is effectively saying that in addition to both test and recommended extras there needs to be also zest.releaser installed. This causes inconvenience for downstream packagers because it is creating some sort of circular dependency.

See also: https://peps.python.org/pep-0508/#extras

Copy link

@icemac icemac left a comment

Choose a reason for hiding this comment

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

I like the suggested change, using extras in zopefoundation all the time.

@reinout
Copy link
Collaborator

reinout commented Feb 7, 2024

Thanks, looks good. I'm not that experienced with tox yet, so I've learned something again :-)

I wonder though: how can this influence downstream packaging? tox.ini is just for running the tests within this project, it isn't the same as the list of dependencies you get when you install it. The tox.ini does work, without any circular problems.

Or are you using tox.ini as something of an installation instruction? Then the way the config is handled is really a sort of documentation. I'm asking as it might help me write better tox.ini files.

@reinout reinout merged commit b4d76bb into zestsoftware:master Feb 7, 2024
6 checks passed
@mtelka
Copy link
Contributor Author

mtelka commented Feb 7, 2024

I wonder though: how can this influence downstream packaging? tox.ini is just for running the tests within this project, it isn't the same as the list of dependencies you get when you install it. The tox.ini does work, without any circular problems.

tox itself by default works without any issue because it installs zest.releaser anyway.

Or are you using tox.ini as something of an installation instruction? Then the way the config is handled is really a sort of documentation. I'm asking as it might help me write better tox.ini files.

I'm packaging Python projects for OpenIndiana and during packaging we run tests to make sure everything is okay. We prefer tox if available. To run tests we do not use the default tox configuration, because it tests in virtual environment. Since our packages runs in real environment testing in virtual env would be of little added value for us.

To run in real (current) environment we use the tox-current-env plugin. Running in current env means that we cannot leave test dependency resolution on tox, but we need to provide them via operating system packages. To get the list of needed testing deps we simply ask tox. With the previous deps-style deps we've got zest.releaser too.

Thank you for merging this.

@mtelka
Copy link
Contributor Author

mtelka commented Feb 7, 2024

FYI, here is this change as a downstream patch.

reinout added a commit that referenced this pull request Feb 7, 2024
@reinout
Copy link
Collaborator

reinout commented Feb 7, 2024

Thanks for the info, I didn't know about tox-current-env (which might be something I can use later on, btw).

I don't know if you need a release for this, but as zest.releaser makes it so easy I put out 9.1.3 :-)

@mtelka
Copy link
Contributor Author

mtelka commented Feb 7, 2024

I don't know if you need a release for this, but as zest.releaser makes it so easy I put out 9.1.3 :-)

No. I do not need release for this change only. Actually, it is better to NOT release with this change only because every release adds some work for us and since this adds no value for us (we already have the patch downstream), then it is definitely better to go without the release yet :-).

Thank you.

@mtelka
Copy link
Contributor Author

mtelka commented Feb 7, 2024

Okay. It looks like I was late and 9.1.3 is already tagged :-).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants