Clarify core concepts for tox-pipenv usage

[vlcinsky]

Even though there is an issue #7 (Add example into readme), I feel, there are some open questions which is good to have clarified before writing any sort of documentation.

Namely:

How to install

Probably into system python or into the same virtualenv, where is tox installed.

Is pipsi tox-pipenv sufficient?

Initiate Pipfile and Pipfile.lock

Is user expected to create Pipfile and Pipfile.lock before creating and using tox.ini?

Probably yes.

Putting files under source control

Is Pipfile.lock expected to be under source control? According to pipenv doc Pipfile.lock is not recommended under source control if it is going to be used under multiple Python versions.

Role of requirements.txt file

Often, tox users use requirements.txt which is then referenced from within tox.ini file as deps.

Is this expected usage?

Caveat: if the requirements.txt file is created before first pipenv usage, it will be automatically used. It may surprise some users.

Is tox.ini deps section really in control?

It seems to me, that with tox-pipenv the Pipfile is always used for any of created virtualenvs and it includes the --dev dependencies..

This sounds contradicting "explicit is better than implicit".

I would prefer similar usage to existing -rrequirements.txt in deps section where I could explicitly require certain dependencies. Alternatively a directive such as installfrompipfile which would take any of options for pipenv install e.g. nothing (to install all except --dev), --dev to install all incl. --dev), or explicit package names (so we need a list value).

Take into account, that tox.ini is often used for multiple purposes:

• run a test (so production and --dev section of Pipfile are good fit
• just run, but do not test (only production section is relevant)
• build Sphinx doc (completely different story).

Are we installing into tox managed venvs or into pipenvone?

pipenv allows installing packages into it's own virtualenv. But if there is an activated one, it installs into the activated one.

I feel, we shall install into the tox created virtualenv.

To me it seems (after quick test) that it installs into it's own pipenv virtualenv located in .venv directory. This prevents development scenario, where tox is used to create multiple virtualenvs and developer can easily switch from one to another without recreating them.

Do we really need special tox-pipenv plugin?

Sorry for this stupid question.

After elaborating the previous conceptual question I have found alternative method for coexistence of tox.ini and Pipfile.*:

Simply add into commands section the pipenv install --dev or pipenv instal jinja2 or whatever. As it runs under activated virtual environment it prints out:

Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project.

Conclusions?

We are still in search of proper tox and pipenv usage as pipenv is still very fresh. I appreciate the effort put into integrating tox and pipenv as tox is really my very favourite tool. Please, read my comments as contribution to the discussion, not as disregarding your effort.

[tonybaloney]

thanks @vlcinsky this is really useful. When this plugin was started running pipenv within a virtual environment wasn't allowed and pipenv would exit.
The last version (1.5.) will execute pipenv graph instead of pip freeze to show you the actual packages and the expected dependencies which I hope other users will find useful.

And to be frank I'm still trying to figure out how these tools should interact and I'm not the only one!

This is a great start, I'll these to the README