Packaging/Distributing pyramid apps

[John Anderson]

What are you guys using these days?  easy_install? pip? buildout? etc.. :)     Just looking for more information on what all you guys are using and why so that we can make a better decision on what we are going to go with!

Thanks!

[Alvaro Aguirre]

Hi John, 

I prefer to use buildout + mr.developer. It's very cleaner to move between dev, test and production environments this way for me, and have everything synchronized from our repository.

Using buildout versions.cfg file, we can rapidly recover exact versions of our applications after a "disaster" 

Ex: https://github.com/aaguirre/PythonChile.Buildout/blob/master/buildout.cfg

Also, using buildout recipes I can solve specific problems easily, like the creation of the wsgi files to run my apps under mod_wsgi.

Cheers,

Alvaro. 

2012/6/15 John Anderson <son...@gmail.com>

What are you guys using these days?  easy_install? pip? buildout? etc.. :)     Just looking for more information on what all you guys are using and why so that we can make a better decision on what we are going to go with!

Thanks!

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.

[Michael Merickel]

I was a big proponent of pip because it looked like where everything
was going, however I've all but abandoned it at this point in favor of
easy_install (without attempting to deal with buildout's doctest-style
documentation).

pip does not:
- support binary packages (for windows or scientific packages)
- integrate well with setup.py sub-commands (develop, install, test)

easy_install does not:
- support uninstalling things
- have a freeze operation

I delete virtualenvs when I mess up anyway, so I'll gladly sacrifice
uninstall support, and I can pin things in the setup.py if necessary
rather than freezing the entire environment.

Hopefully packaging (distutils2) solves everything, right?

[Jonathan Vanasco]

pip will also reinstall all dependencies (ie: already met ones) every
time you upgrade a package. it's infuriating and annoying.

[Jonathan Vanasco]

my preferred solution right now is:

merge sourcecode into a 'current_deployed' tag/branch
use fabric/fabfile to ssh into the server , checkout the build,
install it into the virtualenv using 'development mode', set a few
symlinks, and relaunch the app

i decided against running everything through an app that is installed
into the virtualenv site-packages directory. my production
deployments mix pyramid + twisted + http + some java , so I prefer
having everything consolidated into the single directory structure
that correlates to the source.

it's totally a preference, but I like the 'self-contained' world that
replicates itself.

[Robert Forkel]

pip with our own pypi mirror. This makes the pain of pip reinstalling
everything on update a lot easier to take.

[Andi Balke]

we are on the road for distribution packages in our project. in our last company this was also required (by us for every project ;) ) to deliver one rpm/deb. it doesn't matter if you have a buildout or a maven sandbox. 

good reasons are here: 

http://hynek.me/articles/python-deployment-anti-patterns/

http://hynek.me/articles/python-app-deployment-with-native-packages/

a tutorial for easy package building is here: 

http://aboutsimon.com/2012/04/16/building-a-python-deb-in-a-bootstrapped-ubuntu-chroot-with-fpm/

in my case i'm building a fabric task that compiles all dependency packages and the application and builds debs. this is quite far, but not ready yet. using a vm is comfortable as you can reset it in 4 seconds::

vmrun revertToSnapshot /Users/Shared/vm/debian\ 6\ squeeze/Other\ Linux\ 2.6.x\ kernel.vmwarevm/ git_base_install \

  && vmrun start /Users/Shared/vm/debian\ 6\ squeeze/Other\ Linux\ 2.6.x\ kernel.vmwarevm/

also there is a second vm (a system-clone of staging or live then)  which does not contain the compilation toolchain to test the produced deb. 

when this fabric building work is done, the fabric task will move to jenkins and run on commits to the master branch automatically. the result is a deb package on the buildserver which can be installed on a staging, maybe automatically (at least the staging). the concept with having a branch for automatic releases is described here: http://nvie.com/posts/a-successful-git-branching-model/ (in our last company this worked really well for different projects. everyone knows: master commit+version bump will result in a relase version 5-30mins later.)

about the installation itself there will surely come up puppet, but since now i'm glad when the other work is done. 

cheers, andi

 

On 16.06.2012, at 05:38, Fabian Neumann wrote:

+1 on using buildout and mr.developer. Our complete development and deployment setup is based on these plus git and fabric. Been using this combination for years. Once you get it, it's very powerful.

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/pylons-discuss/-/nrD6ueDKVDIJ.

[Thomas G. Willis]

We use buildout and ant because we have a fairly sizable javascript app talking to a pyramid app on appengine. I'm not sure if ant is really necessary for us but it makes things nice for jenkins.