4 ms·

I think native packages make things too rigid. A private PyPI server hits the sweet spot for us. The steps to deploy an update is as simple as: 1. activate vir

by j-kidd 14y ago

I think native packages make things too rigid. A private PyPI server hits the sweet spot for us. The steps to deploy an update is as simple as: 1. activate virtualenv 2. run `easy_install -U app` and no root permission is required. It also has the added benefit to allow having multiple copies of the same package in the same machine [1], which can't be done with native package. [1] In one deployment, we have staging instance and production instance in the same machine...

sciurus 14y ago
Sure you can have multiple version installed with native packages; for examples, see the discussion at https://groups.google.com/group/devops-toolchain/browse_thread/thread/e99e93b34433e14d/1fc5b50feae310a7 https://groups.google.com/group/devops-toolchain/browse_thre...
- j-kidd 14y ago
  Of course, it has always been possible to have multiple versions installed with native packages. Gentoo supports that since day 1. What I was talking about though (and I didn't make it clear), is having the same version installed multiple times in different locations (i.e. separate virtualenv).
oasisbob 14y ago
For some environments, this may be the case. I find native packaging to be really helpful in mixed environments. On a daily basis I need to deploy Rails/PHP/Python, and using a native package manager is a nice common denominator. When I first heard about this strategy I thought it was crazy -- but have since come to really like it.
hynek 14y ago
I think you missed one point here: The package _contains_ the virtualenv, so you even _must_ have multiple copies of the same package for every app that needs it. That’s the whole point of it: have a consistent and reliable way to deploy whole applications including all dependencies.
- j-kidd 14y ago
  That is exactly my point - you have to build multiple packages for the same app, even for the same version (app1_venv_a-1.0, app1_venv_b-1.0), if there is a need to have more than one instances of it running on the same machine. Until emerge/apt-get/yum/etc add support for virtualenv, I will stick with .egg packages and be python-native rather than system-native.
  - hynek 14y ago
    That’s wrong. The package contains only the application, it’s up to you how you start it. That’s where for configuration (e.g. Puppet or Chef) comes into the game.

by j-kidd 14y ago

sciurus 14y ago

Sure you can have multiple version installed with native packages; for examples, see the discussion at https://groups.google.com/group/devops-toolchain/browse_thread/thread/e99e93b34433e14d/1fc5b50feae310a7 https://groups.google.com/group/devops-toolchain/browse_thre...

j-kidd 14y ago
Of course, it has always been possible to have multiple versions installed with native packages. Gentoo supports that since day 1. What I was talking about though (and I didn't make it clear), is having the same version installed multiple times in different locations (i.e. separate virtualenv).

oasisbob 14y ago

For some environments, this may be the case. I find native packaging to be really helpful in mixed environments. On a daily basis I need to deploy Rails/PHP/Python, and using a native package manager is a nice common denominator. When I first heard about this strategy I thought it was crazy -- but have since come to really like it.

hynek 14y ago

I think you missed one point here: The package _contains_ the virtualenv, so you even _must_ have multiple copies of the same package for every app that needs it. That’s the whole point of it: have a consistent and reliable way to deploy whole applications including all dependencies.

j-kidd 14y ago
That is exactly my point - you have to build multiple packages for the same app, even for the same version (app1_venv_a-1.0, app1_venv_b-1.0), if there is a need to have more than one instances of it running on the same machine. Until emerge/apt-get/yum/etc add support for virtualenv, I will stick with .egg packages and be python-native rather than system-native.
- hynek 14y ago
  That’s wrong. The package contains only the application, it’s up to you how you start it. That’s where for configuration (e.g. Puppet or Chef) comes into the game.