Cookiecutter-django: New release?

[cshaley]

I'm submitting a...

• [ ] bug report
• [x] feature request
• [ ] support request => Please do not submit support request here, see note at the top of this template.

Do you want to request a feature or report a bug?

• Feature

What is the current behavior?

• Cookiecutter-django was recently updated to support Django 1.11 and more specifically the most recent release of django 1.11. A new release of cookiecutter-django has not yet been published.

What is the expected behavior?

• I would expect that new versions of cookiecutter-django would be packaged as versioned releases as is standard practice. This behavior is specifically expected when the underlying requirements for the package are updated, e.g. the version of django, or when a group of features are added to the package.

What is the motivation / use case for changing the behavior?

• Production systems and environments are often built using pinned package versions. When building an environment that uses cookiecutter-django, I want to be able to specify the (now) current version.

• Short term fix: My team would like to use the current version, and we would prefer if it were packaged into a versioned release.

• Long term: It's standard practice to have a process for releasing updates to software packages. I would like to see regular versioned releases of cookiecutter-django as it and its underlying dependencies are updated. My team is working on getting cookiecutter-django packaged for conda forge (community driven packaging system), and having versioned releases of cookiecutter-django published on github as the package is updated would help greatly in packaging for conda forge!

[pydanny]

Conda forge supports Cookiecutter template releases? How does that work?

While I'm flattered that this project is up for inclusion in Conda forge, I'm a bit worried about the increased maintenance load on our part. As unpaid volunteers we're already having trouble supporting bug and feature requests. And so far no one has been willing to actually pay for support. Adding in the Conda community won't ease that problem. I'm open to suggestions though.

[cshaley]

To be more specific, I want to be able to ship a versioned release of this repo to users via conda forge so that the users can use conda to install a specific version of cookiecutter-django along with all of its dependencies.

It looks like you have 15 prior releases on github, where you just zipped up the repo so that people can download prior working versions for usage. That's essentially all I'm asking for - a zipped up copy of the repo that is updated periodically and versioned with respect to the updates. I think this would be well-worth your time because:

• it's a minimal amount of work (zip everything, put a version number on it, ideally add in some release notes such as dependency updates and major features added/bugs fixed)
• it provides a versioned release history of your software package
• it makes it easier to ship a specific version (rather than bleeding edge) to users, whether or not someone packages it for, for example, conda forge

I can simply package that versioned release into conda forge and update the conda build recipe when you update the release on github. So you wouldn't need to update conda forge on your own - anyone who needs the conda forge package updated can do so on their own if you're shipping your own zipped releases on github.

Does that make sense? Does that sound like something you could buy into?

[pydanny]

Yes, it makes sense.

Tell you what, we need to do some cleanup before we add potentially a larger user base. Specifically, we need to remove the experimental Elastic Beanstalk implementation (#1417 ). I have great success with it, but there's too much tribal knowledge involved. So give us a week or two, okay?

[cshaley]

Not a problem!

[pydanny]

Hi @cshaley, I removed the Elastic Beanstalk components and did the 1.11.9 release (https://github.com/pydanny/cookiecutter-django/releases/tag/1.11.9).

How is that?

[cshaley]

Looks great! I'll try out packaging it for conda forge sometime this week.

[cshaley]

FYI, it looks like there is still a solid list of dependency deficiencies. In order to build cookiecutter-django for conda forge, each of its dependencies must be on conda forge, and specifically, the correct version needs to be there for osx, windows, and linux if available. E.g. django is on version 1.11.4 and 2.0.1 on conda forge and cookiecutter-django requires version 1.11.9, so we need to update django to version 1.11.9 on conda forge.

@sannykr and I have pulled a lot of the dependencies together on conda forge, but it will take a while to get the last few (10 or so) polished. We'll tag you on the conda forge PR when we make it.

[cshaley]

@pydanny It looks like the 1.11.9 release you created is broken and was fixed by this commit.

Could you possibly delete that release and move that tag to the latest commit before updating to django 1.11.10 so that the 1.11.9 release is a working build? Here's the last commit before the update to django 1.11.10.

[cshaley]

@webyneter @pydanny Even if you tag this commit as version 1.11.10, that would be very helpful as the 1.11.9 release is broken.

[pydanny]

Okay, I'll get to this it a few hours

[browniebroke]

@cshaley Created tag 1.11.10: https://github.com/pydanny/cookiecutter-django/releases/tag/1.11.10

[browniebroke]

I've also created tag 2.0.2. I'm going to close this for now. We can re-open if another release is required.