On Fri, May 7, 2010 at 2:43 AM, Antonio Cavallo <a.cavallo@cavallinux.eu> wrote:
Beside the technical reasons, from a network administration point of view
is a bad way to replace a native way to install things. Plenty of company
have developers without administrator privileges on a machine.

All of a sudden if you are a syadmin and must  know what is installed
on a remote machine (possible in another continent) you could not use
any longer the standard system tools (rpm -qi on linux) but you need
to be logged as the developer and go figuring out the way he/she
installed things.

Again I suggest to stay away from anything that relies on setuptools, that
is my professional experience, and I haven't seen any (good) reason
to suggest the contrary: you needs might be different.

I agree that using native operating system tools to install packages is a good thing.  There's one big problem with that though:  it becomes near impossible to sandbox packages into their own virtualenvs.      This is important to us because we have multiple packages that may rely upon different versions of different packages.
 
Traceability is I give you the "product" (in business lingo "deliverable") now the questions are:
 - What it depends upon? python + module foo version X + module bar version Y and so on.
 - How do I rebuild it if you company goes bankrupt (I hope not but it is an eventuality)?
 - Is there any hidden backdoor any of you employee has put in one of the many component?
 - How do we get the name of the offender if that happen?

I suppose I can see the benefit of having dependencies in version control.  I'm not sure I like the idea of ruling things with an iron fist though.  I could see managing dependencies and managing the build process turning into a full time job.  I suppose there may be benefits to that, but whether or not we can dedicate a person to it is a decision that is well above me.  :-)