Allow per-project pipenv configuration in Pipfile, ".pipenv.cfg", setup.cfg, or some other per-project configuration file

[sirosen]

There are quite a few pipenv configuration options presented as environment variables. I would like to be able to set these on a per-project basis, committed to version control, loaded and understood by pipenv itself and not by a secondary tool.

The documentation section for them recommends using direnv. While I'm sure direnv is a lovely solution, it's another dependency for developer machines and for any infrastructure where we want to use pipenv.
I don't think it's unreasonable to want pipenv to be able to have its own config file or read from an existing config like setup.cfg or even a special section of Pipfile.

I'd suggest even using a section of pyproject.toml, but that seems downright confusing to mix with Pipfile.
One easy way out is to just load a special .pipenv.cfg with configparser.

Allowing the use of --config FILENAME to use a custom config file location would be a logical added goody.

More than anything else, I want to be able to set PIPENV_VENV_IN_PROJECT=1 in my projects, especially since /.venv/ is in my .gitignore.

Apologies if this has been requested before, but I don't see it in any of the closed issues.
I'm happy to work on this in a PR if it gets the ol' 👍 from people.

[techalchemy]

This issue will need to go through the new enhancement proposal process -- nothing too fancy, just an organized way for triaging stuff with Kenneth

See here for the initial description and then you can simply just create a PR with a markdown description for review

Thanks!

[MIKNOTAURO]

Hi guys, I do not know if this is related but, is there a way to set the path of my environment per project basis?
I know if you set PIPENV_VENV_IN_PROJECT=1 you got a .venv in the root directory but this does not work for me... I need to set my env outside of my root directory (one level up, like ../.venev) and it would be awesome if we can set the name of the env.

Any help?

[AndrewPrifer]

I don't think that the rc file should be necessarily project specific. An rc file would have advantages globally as well (see e.g. #2949). I think if we are talking about package managers, a good model to follow would be .npmrc, which layers builtin, global, per-user and per-project config files on top of each other. I wouldn't add these settings to the Pipfile in any case because these settings are specific to Pipenv and not to Pipfile, which could be used by other tools too.

[ncoghlan]

In the discussion at pypa/pipfile#120 regarding adding a [tools] section to the Pipfile format (which would have allowed a [tools.pipenv] section to store pipenv settings), the current conclusion is that we're not going to do that, and we're instead going to advise projects like BeeWare to put their settings in the existing pyproject.toml tools table.

This means that Pipfile becomes specifically "The place where you declare Python ecosystem dependencies that aren't meant to be published to PyPI as dependency metadata" (e.g. you're using your CI provider's build pipeline format to publish a web application, or the items you have in Pipfile are for setting up a recommended development environment, and go beyond the essentials of what's needed to build and install the project)

This means that at the very least it would be good to support a [tools.pipenv] table in pyproject.toml (to allow per-project config, such as always enforcing venv-in-repo).

A per-user config file would also make sense, for things like terminal interaction settings, PyPI mirror settings, etc.

[matteius]

This is basically going to be supported as named category package groupings, which has a working prototype and is being tracked in: #4745