Remove leading dashes in venv names #2399
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is designed to fix issue #439 without causing a breaking change; it does so by removing only leading slashes, instead of prohibiting slashes anywhere in the virtualenv name, as the original issue proposed.
I slightly changed how
Project._sanitize()
works, but it's not the only potential solution. Another option would be to change howdo_create_virtualenv()
callspew
; a double dash could be used to separate options from positional arguments and then even a virtualenv name that started with a dash would work. That change would look something like this:However, it seems to me that changing the name sanitizing method is a better choice for the following reasons:
Checking a string in a unit test is a fast and easily understood operation. While admittedly the context for the test could be lost if its broader purpose is not made clear, that seems like a decent tradeoff when considering the other option. Changing how
pew
is invoked inpipenv
necessitates a slow integration test that relies on calling external code. Furthermore, it would require either extensive changes to the_PipenvInstance
andTemporaryDirectory
classes to allow specifying a temp dir with a defined name (think/tmp/-dir-with-leading-dash
) or a lot of messy one-off setup and teardown logic.Should
virtualenv_name
be passed to other external commands, options and positional args would not need to be separated by the double dash. Given that a bug of this nature would be stubborn and hard to find, this PR has the potential save a lot of time by preventing other issues before they are introduced.