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

pipenv fails when inside a directory starting with a dash #439

Closed
knkski opened this issue Jul 18, 2017 · 3 comments · Fixed by #2415
Closed

pipenv fails when inside a directory starting with a dash #439

knkski opened this issue Jul 18, 2017 · 3 comments · Fixed by #2415

Comments

@knkski
Copy link

knkski commented Jul 18, 2017

The real issue is filed here, but would it make sense to add - to the list of characters to sanitize here?

A test case:

$ git clone http://github.com/foo/bar.git -- "-deleteme"
Cloning into '-deleteme'...
remote: Counting objects: 1176, done.
remote: Compressing objects: 100% (61/61), done.
remote: Total 1176 (delta 121), reused 131 (delta 104), pack-reused 1001
Receiving objects: 100% (1176/1176), 3.81 MiB | 1.42 MiB/s, done.
Resolving deltas: 100% (473/473), done.
$ cd -deleteme/
$ pipenv --three
Creating a virtualenv for this project...
⠋usage: pew [-h] [-p PYTHON] [-i PACKAGES] [-r REQUIREMENTS] [-d] [-a PROJECT]
           envname
pew: error: argument -d/--dont-activate: ignored explicit argument 'eleteme-srGrfIGO'

Virtualenv location: 
@nateprewitt
Copy link
Member

So I don't think there are any technical reasons we can't add - to that list, but that's a breaking change and is likely to irritate a lot of users since - is a pretty common character.

Before we start making decisions on how to address this though, I just want to make sure I understand the situation. From what I gathered in your issue on the pew repository, Jenkins is stripping path names to meet an 80 character max. Is that correct? Have you attempted to use this suggested solution for Jenkins?

@knkski
Copy link
Author

knkski commented Aug 21, 2017

You are correct on what the issue is, and I did use that solution to successfully fix it for my situation. It's possible that pipenv would be used in a situation where it's not possible to use that solution, such as a hosted Jenkins instance, but that is probably too much of an edge case to consider making a breaking change in pipenv for, particularly since the real issue lies in pew.

@kennethreitz
Copy link
Contributor

closing as 'won't fix'

dnoetzel added a commit to dnoetzel/pipenv that referenced this issue Jun 21, 2018
If the name given to a virtualenv starts with a dash, it can be
misinterpreted as an argument when passed to external commands,
such as when pew is used create a new virtual environment.

Since pipenv has not been able to create a virtual environment in
a directory whose name begins with a dash, there are no deployments
to break with this change.

Fixes pypa#439
dnoetzel added a commit to dnoetzel/pipenv that referenced this issue Jun 25, 2018
Invoke pew with a double dash separator ("--"), to make it clear that
the virtualenv name is a positional argument. Since the virtualenv
name includes all or at least the beginning of the directory name,
trying to create a virtualenv in a directory with a leading dash in
its name will cause pew to erroneously parse the virtualenv name as an
optional argument. Adding the separator causes the virtualenv name to
be parsed correctly.

Fixes pypa#439
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 a pull request may close this issue.

3 participants