Proposal: Explicit command to create a Pipfile in the current directory

[uranusjr]

Pipenv does not currently have an explicit “new project” command, but automatically ensures everything is in order when you run something. While this works well in general, it may leave people in the dark if the environment configuration is slightly off, as is the case of #2185.

#2185 is obviously a user error, and #2186 would help identify the problem, but the user, unless with substantial understanding to Pipenv internals, would still not be able to understand what action should be taken next.

A similar, but non-user error situation is to create nested Pipfile projects. This is suggested in #2148, which introduces the notion of “including” sub-projects. How this inclusion mechanism should be handled, if at all, is up to further discussion, but the idea of a Pipfile sub-project in itself is currently already problematic. You wouldn’t be able to create a sub-project if you create a parent project first, because all Pipenv commands will see the parent project, and refuse to create a new one.

The only reasonable way to work around this is to create the new Pipfile manually (e.g. touch Pipfile). This is however still hackish, and not at all obvious unless you are knowledgable about Pipenv’s internals. With Pipenv encouraging user to let it handle Pipfile edits entirely (with pipenv install/uninstall [package] commands), it would also confuse users if it breaks consistency here.

The proposal is to provide an obvious way for user to initialise a virtual environment with a Pipfile created in the current directory, similar to npm init. This does not change the current initialisation behaviour, but only provide an additional way to initialise not only the virtual environment, but the Pipfile explicitly, right here. There are several possible ways to implement this:

• An environment variable. This is probably not a good idea, since this needs to be obvious to be useful. Environment variabls are not obvious at all, at least to me. It would also conflict with PIPENV_PIPFILE.
• An option to pipenv, e.g. pipenv --python=... --project=.. This is not as obvious as a top-level subcommand, but is still reasonably visible, and can be combined with other subcommands to perform tasks. It would still conflict with PIPENV_PIPFILE. What would PIPENV_PIPFILE=/path/a/Pipfile pipenv --python=... --project=/path/b even mean?
• An extra sub-command, a la npm init. This is the most obvious solution, but given the history of reluctancy to adding new commands, I can understand this may not be the preferred way to go. I do prefer this the most, and it is the only option that does not conflict with PIPENV_PIPFILE. It can simply throw an error if a Pipfile already exists at the target location, and PIPENV_PIPFILE errors if the specifies location does not exist.

[gsemet]

Pipenv init that only does touch Pipfile (and probably set the source section) would be nice !

[ncoghlan]

I encountered this just now when I went to run pipenv init --help to check the option for configuring whether or not the virtual environment can see the system site-packages or not.

Without the explicit init subcommand, the options that affect how the virtual environment gets created (--site-packages, --python, --two, --three) all live at the top level of the CLI, which is a bit confusing.

[kennethreitz]

nope. this was the original design, actually, and it was removed due to user feedback.

not changing.

[clayg]

Workaround of touch Pipfile worked great for me, thanks.