Cookiecutter-django: Drop support for bare-bones setups in the project template

[webyneter]

It's been quite a while since Docker established a solid presence on DevOps landscape. From my professional and personal experience bare-bones aka virtualenv-based setups have been consistently displaced with Docker-powered ones in the quest for reproducibility and ease of distribution by enterprises and individuals, provided they hadn't been using other containerization and/or virtualization solutions already.

I suggest that we start relieving Cookiecutter Django project template of the maintenance burden brought by virtualenv runtime environment support (which is not as heavy as it might have been yet still omnipresent throughout the project development lifecycle occasionally calling for documentation improvements, workflow clarifications, and bugfixes) eventually leaving Docker as the only officially maintained runtime.

Clearly, that would be a profound decision for the community and the team to make, and even though I personally am sympathetic to the proposal some other developers might not as well be. It's apparent to me that the change would primarily affect those who're just making their first steps in Python / Django world (we've all been there), those, whose primary incentive is to get the ball rolling ASAP whatever the projected cost of technical debt they'd likely accumulate afterwards (or they may not -- it all comes down to real-world constraints while we're referring to the general public here, right?). Speaking of real-world constraints, they do vary dramatically across teams and projects, yes, but nonetheless my deep belief is that it's best to learn the utter basics of modern infrastructure configuration sooner than later.

I perceive the raised issue as a lowest priority endeavour. My being perfectly aware of the topic's highly discussive nature I hope for all stakeholders, to the extent of their availability, of course, to share some feedback on the issue at hand.

[browniebroke]

Thanks for kicking off this discussion. I'm a bit on the fence for this, I get the 2 sides of the question and as you say it's an important decision. I'll give it some thoughts...

PS: The bugfix you link to is under Docker, which seems against your point. Did you copy/paste the wrong one?

[sfdye]

https://github.com/docker/docker.github.io/issues/6910

Now I am not so sure about not considering Docker alternatives.

[webyneter]

@sfdye even though that was unethical of them to add login page for Mac version that's still an ethical concern, not a functional one. I don't see any serious _lightweight_ containerization alternatives to Docker as of now, at least not to my knowledge.

[webyneter]

@shuttle1987 mind elaborating on the nature of your objection?

[shuttle1987]

My objection is that forcing people to sign up to a 3rd party service makes it a functional concern for this project. I've been involved in running workshops where people have to get some packages set up quickly and a base image with something like Docker is great, forcing people to make an account on a 3rd party service is a big pain there. If there was some alternative lightweight containerization services for Mac that could easily be used as a drop in replacement for Docker I think there's really no issues with going the container approach as continuity of the project would be easier to achieve in the case that Docker gets harder to install. I agree that there's not a really good alternative out there on Mac right now and it's that lack availability of alternatives to Docker which would make me very wary to drop support for a non-containerized install.

That said if the only goal is to make it as easy for complete beginners to get started I see the appeal of the containers, since setting up installs that can be replicated is a pain. Pipenv helps this fairly substantially for Python dependencies but there's still the annoying case of system packages that Docker is really good at handling.

So I guess it's a +0 from me in some senses, but I fully acknowledge I'm likely not the target audience for this package and also I'm not the maintainer of this project so if it saves a lot of time in that sense I can see the appeal there.

[jcass77]

When I started my first django project, I really appreciated the fact that cookiecutter-django took care of many of the initial setup and configuration steps of a bare bones setup.

I can see how maintaining all of that detail can be a challenge though.

[webyneter]

It's evident to me know that keeping virtualenv should remain a priority to us. Closing this one until (and unless) opposing opinions come up.