Repository: pypa/pipenv

Issue:
rm flag fails without Pipfile
When I create a virtualenv for my current environment, but then remove the Pipfile/Pipfile.lock, the command `pipenv --rm` will fail.

```bash
pipenv install  # instantiate
rm Pipfile Pipfile.lock
pipenv --rm  # fails
```

I'm running:
- pip 9.0.1
- Python 2.7.13
- pipenv 3.5.4

See full output below:
<details>

```
~  pipenv install
Creating a Pipfile for this project...
Creating a virtualenv for this project...
⠋New python executable in /Users/ryan/.virtualenvs/ryan-a3k9euAf/bin/python2.7
Also creating executable in /Users/ryan/.virtualenvs/ryan-a3k9euAf/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/ryan/.virtualenvs/ryan-a3k9euAf
No package provided, installing all dependencies.
Pipfile found at /Users/ryan/Pipfile. Considering this to be the project home.
Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...
⠸Locking [packages] dependencies...
⠴Updated Pipfile.lock!
Installing dependencies from Pipfile.lock...
⠦
⠴
To activate this project's virtualenv, run the following:
 $ pipenv shell
~  rm Pipfile*
~  pipenv --rm
Traceback (most recent call last):
  File "/usr/local/bin/pipenv", line 11, in <module>
    sys.exit(cli())
  File "/usr/local/lib/python2.7/site-packages/pipenv/vendor/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/pipenv/vendor/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python2.7/site-packages/pipenv/vendor/click/core.py", line 1043, in invoke
    return Command.invoke(self, ctx)
  File "/usr/local/lib/python2.7/site-packages/pipenv/vendor/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python2.7/site-packages/pipenv/vendor/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/pipenv/vendor/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/pipenv/cli.py", line 713, in cli
    loc = project.virtualenv_location
  File "/usr/local/lib/python2.7/site-packages/pipenv/project.py", line 76, in virtualenv_location
    c = delegator.run('pew dir "{0}"'.format(self.virtualenv_name))
  File "/usr/local/lib/python2.7/site-packages/pipenv/project.py", line 57, in virtualenv_name
    sanitized = re.sub(r'[ $`!*@"\\\r\n\t]', '_', self.name)[0:42]
  File "/usr/local/lib/python2.7/site-packages/pipenv/project.py", line 32, in name
    self._name = self.pipfile_location.split(os.sep)[-2]
AttributeError: 'NoneType' object has no attribute 'split'
```

</details>


Discussion:
Hey @ryanwilsonperkin, thanks for taking the time to open this. We're definitely making an incorrect assumption here that the Pipfile will always exist with the standard cli commands. The virtualenv location that ``--rm`` is trying to remove is bound to the name of the directory the Pipfile resides in. Without that information, we won't be able to run remove reliably.

Since we don't really have a way to store this kind of information without the user navigating to the project directory, it's probably best to raise an exception when a Pipfile can't be found. I'll try to throw this together today or tomorrow, but PRs are welcome as well.
@nateprewitt I'd be happy to take a crack at a PR this evening. Anything in particular I should know about contributing?
@ryanwilsonperkin, nothing particular for contribution. If you open the PR, we'll take a look and see if anything needs tweaking and then should be ready to merge it.

On second glance, I think simply printing a message with click should do the trick. We only want to run `rm` if the Pipfile exists. If not, we should just tell the user we can't find the project.
@nateprewitt from a UX perspective would you prefer that `virtualenv_exists` returns `False` when no Pipfile can be found? That would cause the error
```No virtualenv has been created for this project yet!```
to be printed, which isn't technically true and might confuse a user.

We could choose instead to first check `project.pipfile_exists` and print a different error, but that might not be helpful to the user either, who just wants to delete the virtualenv they expect to be related to the current directory.

Side note: as a user, it was my impression that the virtualenv was based on the directory, not the Pipfile in the directory.

Resolving patch:
diff --git a/pipenv/cli.py b/pipenv/cli.py
--- a/pipenv/cli.py
+++ b/pipenv/cli.py
@@ -3,7 +3,6 @@
 import codecs
 import json
 import os
-import re
 import sys
 import distutils.spawn
 import shutil
@@ -705,6 +704,10 @@ def cli(ctx, where=False, venv=False, rm=False, bare=False, three=False, python=
             do_where(bare=bare)
             sys.exit(0)
 
+        if not project.pipfile_exists:
+            click.echo(crayons.red('No Pipfile found.'), err=True)
+            sys.exit(1)
+
         # --venv was passed...
         elif venv:
 
@@ -1020,12 +1023,12 @@ def check(three=None, python=False):
     # Assert each specified requirement.
     for marker, specifier in p.data['_meta']['requires'].items():
 
-            if marker in results:
-                try:
-                    assert results[marker] == specifier
-                except AssertionError:
-                    failed = True
-                    click.echo('Specifier {0} does not match {1} ({2}).'.format(crayons.green(marker), crayons.blue(specifier), crayons.red(results[marker])))
+        if marker in results:
+            try:
+                assert results[marker] == specifier
+            except AssertionError:
+                failed = True
+                click.echo('Specifier {0} does not match {1} ({2}).'.format(crayons.green(marker), crayons.blue(specifier), crayons.red(results[marker])))
     if failed:
         click.echo(crayons.red('Failed!'))
         sys.exit(1)


Test patch: