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.

[luzfcb]

someone had free time to test poetry https://github.com/sdispater/poetry , and see if it meets our requirements?

[browniebroke]

I'm -1 on merging all the requirements into one.

[webyneter]

@browniebroke how about an option?

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

[browniebroke]

how about an option?

I don't know...

On one hand, I'm neutral because I have no personal interest in using this option. On the other hand, I'm still against it because it (a) would add some complexity to the template and (b) would encourage a bad security practice.

I guess I'm -0...

[webyneter]

@browniebroke we'd really be compromising on security in the opposite case, I agree...

[webyneter]

I'm afraid, there really is no one-size-fits-all solution, at least I don't see it.

[yunti]

I can see the benefit on having testing/production parity but dev/production parity? I don't think that's a good idea. There will always be extra things we want to do/packages to install that we want in dev but not in production.

@luzfcb I think poetry is a great idea and looks to have a better api than pipenv, although as it stands it doesn't support Heroku though - although it wouldn't take much for that to happen. python-poetry/poetry#100

[webyneter]

@yunti without dev-prod parity, you're not guaranteed to see anything working in production even though it works in dev, strictly speaking.

[yunti]

@webyneter isn't that what a testing platform is for?

It all depends on your workflow I suppose

[webyneter]

@yunti that's a fair statement. As I said, strictly speaking only :)

[yunti]

:)

Perhaps we can just keep an eye on pypa/pipfile#99
and see if they broaden the use case, although this seems quite a bit further out on their roadmap.

poetry doesn't fit many different types of deployments yet, although it's making great progress.

So perhaps one to leave for now, but I'll leave that up to you.

[lassiter]

@yunti Poetry has an export command now, would that work?