Pipenv: Running pipenv --three in an empty directory shows Requirements.txt found

[xennygrimmato]

I am trying out pipenv on Mac OS X 10.11.3 - running ZSH on iTerm.

The steps that I followed are:

• mkdir test_pipenv
• cd pipenv
• pipenv --three

Pipenv's logs showed: Requirements.txt found, instead of Pipfile! Converting… - even though I the directory was empty.
Later, it threw a ValueError for an unknown locale.

vaibhavtulsyan:test_pipenv/ $ pipenv --three                                                                                                                                           [19:32:36]
Requirements.txt found, instead of Pipfile! Converting…
Creating a virtualenv for this project…
⠋Traceback (most recent call last):
  File "/usr/local/bin/pew", line 7, in <module>
    from pew.pew import pew
  File "/usr/local/lib/python2.7/site-packages/pew/__init__.py", line 11, in <module>
    from . import pew
  File "/usr/local/lib/python2.7/site-packages/pew/pew.py", line 36, in <module>
    from pew._utils import (check_call, invoke, expandpath, own, env_bin_dir,
  File "/usr/local/lib/python2.7/site-packages/pew/_utils.py", line 22, in <module>
    encoding = locale.getlocale()[1] or 'ascii'
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 564, in getlocale
    return _parse_localename(localename)
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 477, in _parse_localename
    raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: UTF-8

[techalchemy]

There are several issues going on here. Firstly it seems you have installed pipenv and pew with python2 and not with a user-level install per the documentation. Secondly, your shell is misconfigured and you are not setting your locale in your ~/.zprofile. You should add these lines:

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Then you can run, from the command line: source ~/.zprofile

Note that you would have found this if you had googled unknown locale utf-8 mac os x and gone to the first result.

Finally, the reason it is finding a requirements.txt is because you aren't specifying any installation instructions. Pipenv isn't designed to do nothing. If you give it nothing to do, it will go up one directory and look for a Pipfile. If there is no pipfile, it will look for a requirements file. I'm guessing you have a requirements file one directory up.

You should use pipenv to install things and manage their versioning etc. If you just want an empty virtual environment and you have no packages to put in it I am not sure pipenv is useful

[nateprewitt]

I think @techalchemy summed up everything here, so I'm going to close this out. Thanks @techalchemy and @xennygrimmato!

[kennethreitz42]

Let's add this to our output if they aren't defined.

[kennethreitz42]

maybe...

[kennethreitz42]

maybe not.

[kennethreitz42]

[kstohr]

It seems like non-intuitive behavior to automatically install the requirements.txt recursively from directories above. That may well be a totally different project, or a placeholder file (as in my case, which by the way was two directories above...). I had to reinstall three times before finding this posting and understanding that the default behavior was to search (recursively!??) in directories above. If there is no requirements file in the project directory, pipenv should not go searching... or should at least ask before converting a requirements.txt file located in a different directory.

In addition, if the correct usage is pipenv --three install requests to prevent pipenv from using any old requirements file it finds laying about that should be stated more clearly in the documentation.

[techalchemy]

Pipenv has an environment variable that dictates how far it will travel up when searching for pipfiles or requirements files. By default it assumes you are using it inside a project. You can modify how far it will traverse with PIPENV_MAX_DEPTH (default 3). See the documentation on environment variables for more information.

You don't specifically have to install requests, obviously, but pipenv isn't designed to just make virtual environments. I think we should probably do one of two things in this case:

1. Better document the behavior of install which is passed implicitly by pipenv --two and pipenv --three as recursively searching for pipfiles and requirements files; or.
2. Don't recurse up by default for requirements files (maybe only when --three or --two are passed in?) and instead scaffold an empty pipfile with the required python version?

[kstohr]

Thanks! Both solutions would be great.

Here’s the use case. I switched from an existing project with a requests
file full of dependancies. So, I specifically wanted to build a clean file
from scratch. Before installing dozens of pkg’s, naturally, I wanted to
double check the venv was set up correctly. So, there are times when you do
plan to install pkg’s, but you want to establish that the venv is
referencing the right version of python (especially if you have multiple
versions) first. Trust but verify...

In my case, I dumped the old requests file up yonder for reference which
caused the issue. Documentation for pipenv --two and pipenv --three didn’t
mention PIPENV_MAX_DEPTH. To be honest, even if it had the name doesn’t
suggest it’s something you would set to find/prevent conversion of an
existing requirements file. Scaffolding an empty pipfile is preferred. If
you are using pipenv it’s likely you are trying to get away from the issues
associated with requirements files...

Kas

On Mon, Oct 16, 2017 at 5:23 PM Dan Ryan [e-mail] wrote:

Pipenv has an environment variable that dictates how far it will travel up
when searching for pipfiles or requirements files. By default it assumes
you are using it inside a project. You can modify how far it will traverse
with PIPENV_MAX_DEPTH (default 3). See the documentation on environment
variables
https://docs.pipenv.org/advanced.html#configuration-with-environment-variables
for more information.

You don't specifically have to install requests, obviously, but pipenv
isn't designed to just make virtual environments. I think we should
probably do one of two things in this case:

1. Better document the behavior of install which is passed implicitly
   by pipenv --two and pipenv --three as recursively searching for
   pipfiles and requirements files; or.
2. Don't recurse up by default for requirements files (maybe only when
   --three or --two are passed in?) and instead scaffold an empty pipfile with
   the required python version?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kennethreitz/pipenv/issues/527#issuecomment-337081189,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH1md9bSxwZO2hGlDSp0sQ0JeAdzbuv4ks5ss_OUgaJpZM4PU2gA
.

[nateprewitt]

@kstohr, thanks for bringing this back to our attention. I had this flagged to clear up what I previously thought were misconceptions, but after trying things out, I agree that the original functionality has strayed a bit. It's no longer an intuitive experience.

To give some background before we look at options, since the filesystem is a tree structure, we're performing a linear search upwards so we're not doing any recursive magic. It's a check of at most PIPENV_MAX_DEPTH directories (3 by default). This is to allow developers to freely move around inside of a project, but still install things without having to navigate back up to the project root everytime. This functionality still makes sense I think and we should try to keep that the same.

Given a package's (and generally a filesystem's) layout, you wouldn't typically have a dependency file (Pipfile/requirements.txt) above your current directory. The typical exceptions to this case are your directory is either A.) part of the same package, B.) you have another dependency file in your current file specifying some kind of bundled package.

In the case there are files lying around in the users filesystem (a Pipfile in your home directory), we do have an issue though. I think we may want to disable the searching functionality when we create a new environment (explicitly passing --three/--two/--python). This is a pretty deliberate command and one you shouldn't be running routinely while developing. I think it's a reasonable expectation to ask the user to be in the directory they want when creating a new project.

If anyone else has comments on this, please feel free to add them. I think that's probably the direction we should head in though. Also possibly adding a warning for Pipfile like we do requirements.txt when using one we've found outside of the current directory.

[techalchemy]

@nateprewitt I think you described exactly the behavior I would want and expect, and if we already have warnings for requirements.txt if we find it above the current directory, I'd be hesitant to warn about installing into Pipfiles above the current directory -- reason being that I know I personally would find this annoying if I was 1-2 directories above project root and installing stuff which I do regularly

[kstohr]

I think the real issue is that there wasn't any warning or message that
included the path to the requirements.txt file being used. If you can fix
that, and it works in most use cases great. It would be great if you could also disable the feature, maybe solicit a yes/no before converting the requirements.txt found?

[Telichkin]

IMO, it would be better if we add more explicit behaviour to create a new project using the command
pipenv init [OPTIONS]

[normoes]

@techalchemy The link you provided is dead. I searched the docs and found this on setting environment variables when using pipenv.

Also the following works for me and ignores the requirements.txt file in the parent folder: PIPENV_MAX_DEPTH=1 pipenv --python 3.6

[techalchemy]

@normoes the link I provided was provided 7 months ago. Believe it or not time has passed and the link has changed.

And sorry for the sarcasm. But yeah. It was a link to the documentation. Glad you were able to find it.

[laur1s]

Hi, I'm installing a package using pipenv in an empty dir with no requirements.txt file in the tree. However i still get `⠋Already using interpreter /usr/local/opt/python/bin/python3.6
Using base prefix '/usr/local/Cellar/python/3.6.5_1/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users//.local/share/virtualenvs/moviedb-api-Grij1wlp/bin/python3.6
Also creating executable in /Users//.local/share/virtualenvs/moviedb-api-Grij1wlp/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users//.local/share/virtualenvs/moviedb-api-Grij1wlp
requirements.txt found, instead of Pipfile! Converting…`

It always installs bunch of packages I don't need. How can I fix this

[normoes]

What is the exact command you are trying to create the virtual environment with?

Did you try using anything like
PIPENV_MAX_DEPTH=1 pipenv --python 3.6
(with special focus on PIPENV_MAX_DEPTH)?

Here you can find a list of environment variables pipenv uses (Same link as above).