On Wed, Mar 25, 2009 at 2:20 AM, Tres Seaver <tsea...@palladion.com> wrote:
> > Many of us using setuptools extensively tend to adopt an "isolated > environment" strategy (e.g., pip, virtualenv, zc.buildout). We don't > install the packages used by different applications into shared > directories at all. Instead, each environment uses a restricted subset > of packages known to work together. Is that a working solution when you want to enable easy installation on a large number of "customers" ? In those discussions, I often see different solutions depending on the kind of projects people do. I don't know anything about plone, but I can imagine the deployment issues are quite different from the projects I am involved in (numpy and co). Everytime I tried to understand what buildout was about, I was not even sure it could help for my own problems at all. It seems very specific to web development - I may completely miss the point ? virtualenv, pip, yolk, those are useful tools for development/testing, but I don't see how they can help me to make the installation of a numpy environment easier on many different kind of platforms. > >> If the problem is to get a recent enough version of the library, then >> the library would better be installed "locally", for the application. >> If it is too much a problem because the application depends on >> billions of libraries which are 6 months old, the problem is to allow >> such a dependency in the first place. What kind of nightmare would it >> be if programs developed in C would required a C library which is 6 >> months old ? That's exactly what multiple-versions installations >> inflict on us. That's great for testing, development. But for >> deployment on end-user machines, the whole thing is a failure IMO. > > It is wildly successful, even on platforms such as Windows, when you > abandon the notion that separate applications should be sharing the > libaries they need. Well, I may not have been clear: I meant that in my experience, deploying something with several dependencies was easier with bundling than with a mechanism ala setuptools with *system-wide* installation of multiple versions of the same library. So I think we agree here: depending on something stable (python stdlib + a few well known things) system-wide is OK, for anything else, not sharing is easier and more robust in the current state of things, at least when one needs to stay cross platform. Almost every deployment problem I got from people using my own softwares was related to setuptools, and in particular the multiple version thing. For end-users who know nothing about python package mechanism, and do not care about it, that's really a PITA to debug, and give bad mouth taste. The fact that those problems happen when my software was not even *using* setuptools/etc... was a real deal breaker for me, and I am strongly biased against setuptools ever since. > > FHS is something which packagers / distributors care about: I strongly > doubt that the "end users" will ever notice, particularly for silliness > like 'bin' vs. 'sbin', or architecture-specific vs. 'noarch' rules. That's not silly, and that's a bit of a fallacy. Of course end users do not care about the FHS in itself, but following the FHS enables good integration in the system, which end users do care about. I like finding my doc in /usr/share/doc whatever thing I install - as I am sure every window user like to find his installed software in the panel control. > > As a counter-example, I offer the current Plone installer[1], which lays > down a bunch of egg-based packages in a cross-platform way (Windows, > MacOSX, Linux, BSDs). It uses zc.buildout, which makes > configuration-driven (repeatable) installation of add-ons easy. But zc.buildout is not a solution to deploy applications, right ? In my understanding, it is a tool to deploy plone instances on server/test machines, but that's quite a different problem from installing "applications" for users who may not even know what python is. cheers, David _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com