Migrate to Pipfile

[skorokithakis]

• **I'm submitting a ... **
  • bug report
  • feature request
  • support request => Please do not submit support request here, see note at the top of this template.

It might be good if the project migrated from requirements.txt to a Pipfile/pipenv, which is a better method of tracking requirements and is the official Python replacement for requirements.txt as well.

[webyneter]

As far as I know, pipenv utilizes Pipfile "standard "under the hood where the latter doesn't support arbitrary requirements sections except for [packages] and [dev-packages], which is an obstacle for us since cookiecutter-django natively supports test and potentially other environments as well.
My knowledge may be obsolete, though, is it, @skorokithakis ?

[skorokithakis]

Ah, no, that pretty much describes the current status quo, you're exactly right, @webyneter. I didn't realize that was an explicit goal for cookiecutter-django. Feel free to close this ticket!

[webyneter]

@skorokithakis no problem, thank you for your time :)

[raiderrobert]

@webyneter, FYI, at this point, it's never going to get this feature at this point. It was shut down hard as an explicit design decision by pipenv's maintainer.

I expect in the future in order to provide better community support, I'll either have to fork this repo and maintain a separate one based on pipenv or make a feature suggestion to have it as a binary option.

@webyneter, which approach would you prefer?

[luzfcb]

relevant issue: pypa/pipenv#1398
related https://twitter.com/vorpalsmith/status/960252733541384192

[yunti]

as per #1557 we have now removed the test.txt requirements file so now have a setup compatible with pipfile and pipenv, so it's worth reopening this. (Support for pipenv has also just been added to pycharm which may please some users too).

[sfdye]

Maybe open a new issue to add support for pipenv, as we don't want to "migrate to pipfile". requirements.txt isn't going anywhere anytime soon.

[webyneter]

@sfdye I'm thinking about merging all requirements files into the single requirements.txt: that should give us additional reproducibility guarantees in terms of dev-prod parity.

[pydanny]

My concern with a single requirements.txt file is the security issues. Do we really want something like the Patreon staging server fiasco? That happened because:

1. Staging had debug settings on that were ON by default and SUPPOSED to be turned off
2. Staging had a single requirements.txt file that included debugging libraries
3. Human error

The reason behind multiple settings files is that it's a security feature. It is there as another bit of insurance to protect us from making unfortunate mistakes.

[skorokithakis]

Were the libraries the problem, or the fact that DEBUG was on? Would the hack have happened without the libraries?

[webyneter]

that it's a security feature

@pydanny, I understand that, but I've got mixed feelings on the issue: on the one hand, having separate requirements does prevent our users opted for default settings from falling into the same trap in future; on the other, it renders their efforts to make the stack as reproducible as possible useless (whereas a single requirements.txt is a huge step towards the goal).

How about we compromise and allow combining all requirements files into one upon bootstrap through an option?

[webyneter]

The default value for such an option must without doubt be the secure one.

[webyneter]

@skorokithakis

Were the libraries the problem, or the fact that DEBUG was on? Would the hack have happened without the libraries?

Everything was, put together, and that's the thing: you never know when it's gonna kick you.