-
-
Notifications
You must be signed in to change notification settings - Fork 374
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
Rework determination of virtualenv site-packages flags for v20 #578
Rework determination of virtualenv site-packages flags for v20 #578
Conversation
virtualenv 20.0 removed --no-site-packages so we cannot pass that. This means we have three version scenarios to cope with: < 1.7: site packages installed by default, with --no-site-packages to opt out 1.7 - 20.0: --no-site-packages present and default, --system-site-packages to opt back in > 20.0: no site packages by default, --system-site-packages to opt back in
$system_pkgs_flag = $systempkgs ? { | ||
# --system-site-packages was introducd in 1.7, and --no-site-packages | ||
# became the default | ||
true => versioncmp($_virtualenv_version,'1.7') > 0 ? { |
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.
Note: I thiiink that this should probably be >=
, however I believe the current spelling has the same error.
This moves to my fork of puppet-python as it contains a fix for working with virtualenv >= 20. Otherwise this is just poking puppet-python to cope with Fedora 33 *only* having Python 3, which it makes it available as both `python` and `python3`. See voxpupuli/puppet-python#578 for the aforementioned virtualenv fix.
This moves to my fork of puppet-python as it contains a fix for working with virtualenv >= 20. Otherwise this is just poking puppet-python to cope with Fedora 33 *only* having Python 3, which it makes it available as both `python` and `python3`. See voxpupuli/puppet-python#578 for the aforementioned virtualenv fix.
This moves to my fork of puppet-python as it contains a fix for working with virtualenv >= 20. Otherwise this is just poking puppet-python to cope with Fedora 33 *only* having Python 3, which it makes it available as both `python` and `python3`. See voxpupuli/puppet-python#578 for the aforementioned virtualenv fix.
This moves to my fork of puppet-python as it contains a fix for working with virtualenv >= 20. Otherwise this is just poking puppet-python to cope with Fedora 33 *only* having Python 3, which it makes it available as both `python` and `python3`. See voxpupuli/puppet-python#578 for the aforementioned virtualenv fix.
This moves to my fork of puppet-python as it contains a fix for working with virtualenv >= 20. Otherwise this is just poking puppet-python to cope with Fedora 33 *only* having Python 3, which it makes it available as both `python` and `python3`. See voxpupuli/puppet-python#578 for the aforementioned virtualenv fix.
This moves to my fork of puppet-python as it contains a fix for working with virtualenv >= 20. Otherwise this is just poking puppet-python to cope with Fedora 33 *only* having Python 3, which it makes it available as both `python` and `python3`. See voxpupuli/puppet-python#578 for the aforementioned virtualenv fix.
I have tested your branch at our CI. The result is what I expected: The CI fails due to the fact $virtualenv is not set, because it is not installed for a fresh system and the fact itself is been set in the beginning of the run and not been updated while My PR which was based on the $OS, like: if $os == 20.04 => remove --no-site-packages parameter has not been accepted due to the fact the removal of the parameter is based on the virtualenv version. I think we will have to modify the exec for |
The actual cases are:
Which in the end is:
I am not sure if we still need to check on the case if $virtualenv_version < 1.7. On any OSes we are using the $virtualenv_version is > 1.7. But still: The value for the fact $virtualenv_version is unset on the fresh installation. Therefore we only can rely on the fact if it is set. |
Ah, just seen that #552 was a previous attempt at this.
From a quick look these seem correct, but incomplete -- there's no handling for
I would expect that support is required unless the module explicitly declares that it doesn't support the version. (as a user, I'd also hope that it would warn clearly about that somewhere, perhaps at runtime when trying to use an incompatible |
From
|
virtualenv in version 1.7 has been release 9 years ago. I don't find anything if it is already EOL but I think we are safe to drop its support. https://pypi.org/project/virtualenv/1.7/ I have checked all supported OS (from metadata.json). All have virtualenv => 15 for their default repository available. |
I think we are safe to just add
|
hey people. I created #589 . can you both please take a look? I'm also open for suggestions to properly test if this is working |
hey people. Since #593 got merged, this issue can be closed? |
Yup, that PR has fixed it for me also. |
virtualenv
20.0 removed--no-site-packages
so we cannot pass that on that version. This means we have three version scenarios to cope with:< 1.7
: site packages installed by default, with--no-site-packages
to opt out1.7
-20.0
:--no-site-packages
present and default,--system-site-packages
to opt back in> 20.0
: no site packages by default,--system-site-packages
to opt back inThis PR aims to add support for the last of these, so that all three are supported.
This was mentioned at #534 (comment) and I've hit this myself (on Fedora 33, where this patch fixes it for me).
Meta: I've not yet added any tests; I'm not sure how to do that, but if you can point me in the right direction I'm happy to give it a go.