-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Rely on 'selectable' interface for entry points. #2126
Conversation
for more information, see https://pre-commit.ci
efb2d30
to
e294994
Compare
Codecov Report
@@ Coverage Diff @@
## main #2126 +/- ##
==========================================
- Coverage 93.70% 93.67% -0.03%
==========================================
Files 88 88
Lines 4385 4382 -3
==========================================
- Hits 4109 4105 -4
- Misses 276 277 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
… needed for older Pythons.
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jaraco you'll need to fix the failing CI:
@github-actions check / test pypy3 - windows-latest (push)
@jaraco please in future work of your fork, and not create branches in this repo; thanks! |
Would you mind if we sent a PR that conditionalizes this for Python |
I can't speak to virtualenv's position on this request, but I'd like to know more about the motivation. Is the new dependency an issue? |
We have a natural tendency to avoid packaging backports for Python versions that contain the backported code. The Fedora's virtualenv has this patched out entirely on Python 3.10+ and I was wondering if we can drop that difference by doing that here instead. No, bundling is even worse. |
I will accept that, I'm not that keen on the |
I suspect that will address the issue. The question is - should hroncok go project by project requesting this change in contradiction to the recommendation of the backport (https://github.com/jaraco/backports.entry_points_selectable/blame/main/README.rst#L29), or should the backport provide the recommendation and the special incantation for everyone to adopt? I'd prefer to provide the best practices at a centralized place rather than leave it to each project to figure out their localized best practice and leave it to each project to reconcile from a variety of different practices. The main reason I wrote the backport was to provide a one-line solution for each project, but this recommendation is a multi-line implementation that isn't even readily implementable as a cohesive block of code. (import sys and try/except blocks). I'm trying to make it clean and easy for adopters and the proposed change diverges from that.
If you think there's a better way that projects could/should adopt selectable entry points, I'd welcome your feedback at either |
I don't see anything wrong in using backports only where needed. Yes, it is a bit more lines of code, but it clearly shows when it can be deleted. I don't think I know all the best practices of the world, I only cared about virtualenv now. I wanted to avoid a superfluous dependency which would only mean more work for us. If virtualenv would not agree, I would not try to force it in any way. |
Fixes #2093
URL of RTD document: https://virtualenv.readthedocs.io/en/bugfix-2093-new-api/