setup.py for project?

[Thomas Güttler]

Using a setup.py for reusable apps makes sense. This way you can
share the code via a pypiserver.

Our projects are very small. They don't have models, only config. With "project" I mean
the small (in our case) git repo which holds settings.py urls.py.

But does a setup.py make sense for the project?

How do you manage your projects (not apps)?

Regards,
Thomas Güttler


--
Thomas Güttler
http://thomas-guettler.de/

[Tim Graham]

The choice depends on your requirements.

The code for djangoproject.com doesn't have a setup.py because we pull the code directly from git to "install" it on server. This makes deploying incremental changes easy as we just run Ansible which pulls the latest changes. We don't have the notion of "versions" or "release branches" for this code.

In a previous job, my team used Jenkins to create source distributions for each release and then installed them on our production servers. This made rolling back easier as we could simply install the previous version instead of reverting all commits for that version.

[Ilya Kazakevich]

Hello.

What exactly are you trying to achieve?

If you have some part of functionality that is interesting for other people/projects and hence should be shared via pypi, you should extract it as reusable app. Projects, how ever, are not reusable. If you need a fast way to install al project requirements on your new server, you need to use requirements.txt (and pep freeze).

Some people use virtualization (vm images, vagrant, or even docker) to deploy "project" (with all environment including databases, daemons etc) on staing or production machines. 

Environment configuration engines like saltstack/chef/cfengine/puppet are also used.

An excelent book "Continuous delivery" is all about "how do you deploy your code on production with one click". It may be interesting for you.

[Thomas Güttler]

Am 02.04.2015 um 03:13 schrieb Ilya Kazakevich:
> Hello.
>
> What exactly are you trying to achieve?
>
> If you have some part of functionality that is interesting for other people/projects and hence should be shared via
> pypi, you should extract it as reusable app. Projects, how ever, are not reusable. If you need a fast way to install al
> project requirements on your new server, you need to use requirements.txt (and pep freeze).
>
> Some people use virtualization (vm images, vagrant, or even docker) to deploy "project" (with all environment including
> databases, daemons etc) on staing or production machines.
> Environment configuration engines like saltstack/chef/cfengine/puppet are also used.
>
> An excelent book "Continuous delivery" is all about "how do you deploy your code on production with one click". It may
> be interesting for you.

I just checked my favourite book seller. There are many books about this topic. Which one do you recommend?

Regards,
Thomas Güttler

--

[Simon Brunning]

On 2 April 2015 at 11:56, Thomas Güttler <h...@tbz-pariv.de> wrote:
> There are many books about this topic. Which one do you recommend?

Continuous Delivery: Reliable Software Releases through Build, Test,
and Deployment Automation, ISBN 978-0321601919

Very good indeed.

Cheers,
Simon B.
@brunns
07963 351009

[Ilya Kazakevich]

Simon is right. I recommend this http://martinfowler.com/books/continuousDelivery.html