[Distutils] developing & managing multiple packages with dependencies
Jason Baker
jbaker at zeomega.com
Fri May 7 15:26:18 CEST 2010
On Fri, May 7, 2010 at 2:43 AM, Antonio Cavallo <a.cavallo at 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. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100507/09f387db/attachment.html>
More information about the Distutils-SIG
mailing list