Should pipenv be used for apistar?


#1

we talked about it in #498 .
Personally I find it very convenient. I use for my own.
But I totally agree with @audiolion about it https://github.com/encode/apistar/pull/498#issuecomment-384993560 I had the same feeling about it.

I was on the way proposing a PR for it but considering the pipenv issues, maybe it’s to early adding it to apistar.

does anyone know big project already using pipenv ?
whats your opinion about it ?

Jimmy


#2

I’ve been using it for my smaller libraries and various applications. It’s been fine for those use cases, though occasionally buggy (as @audiolion points out). For example, the latest release (11.10.1) has a bug where if you start a fresh project in an existing venv and try to pipenv install something, it’ll fail. Something like this happens once every couple of releases in my experience so they seem to have a real issue with quality control and their changelog is… not great (due to entries like " - Bugfixes." which basically tell you nothing).

I attempted to “upgrade” Dramatiq to use pipenv this weekend, but quickly gave up due to the aforementioned issue and lack of clarity on how pipenv and tox should be integrated.

Also, for what it’s worth, it’s significantly slower than using plain pip. Installing all of Dramatiq’s dev dependencies takes about 2 seconds on my machine using plain pip install -r ..., but pipenv took about 30 seconds to a minute (on version 11.10.0).


#3

I don’t particularly mind one way or the other, but given:

Do not keep Pipfile.lock in version control if multiple versions of Python are being targeted.

https://docs.pipenv.org/basics/#general-recommendations-version-control

There’s not a lot of difference between the two cases. We’d have a Pipfile instead of a requirements.txt. That’d give us the ability to have a [dev-packages] section, but given that the requirements are only there for development/testing on the package itself, it’s not really obvious that we need the separation.

pipenv install will work just fine against the project as it currently stands, so I guess there’s no particular reason to move to Pipfile instead of sticking with a plain old requirements.txt.


#4

Sure that the Script folder does what pipenv do about the virtualenv

this close the discussion

ps : for curious people look at the new poetry for depedency and packaging : https://github.com/sdispater/poetry