On Wed, Mar 25, 2009 at 3:15 AM, Tres Seaver <tsea...@palladion.com> wrote:
> >> 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 ? > > I think so: it is largely a way to get repeatable / scripted deployment > of software to disk. It uses setuptools to install Python package > distributions, but also can use other means (e.g, configure-make-make > install to install a C library such as libxml2). The end result is a > self-contained directory tree: > > - - Scripts in the 'bin' directory are configured to have the specific > Python pacakges (and versions) they require on the PYTHONPATH. > > - - By convention, released package distributions are installed into the > 'eggs' subdirectory', which is *not* on the PYTHONPATH, nor is it a > 'site' directory for Python. > > - - Other bits are typically in their own subdirectories, often under > 'parts'. Ok - but I don't think it helps much, see below. > When not doing Plone / Zope-specific work (where zc.buildout is a de > facto standard), I use 'virtualenv' to create isolated environments into > which I install the libraries for a given application. If your > application ships as Python package distributions, then documenting the > use of 'virtualenv' as a "supported" way to install it might reduce your > support burden. I now realize why we don't understand each other - in my case, the one doing the installation is the user, who cannot be assumed to know much about python.q11 That's what I mean by "application deployment vs webapp deployment". Ideally, the user has to enter one command/click one button, and he can use the application - he may not even be a programmer (I deploy things based on numpy/scipy for scientific people, who often have little patience for things which take more than 1 minute to set up software-wise). That's the user case I am mostly interested in - and I think it is quite general, and quite different from plone deployment kind of things. > > You can think of zc.buildout or the virtualenv-based script as a form of > bundling, which bootstraps from another already-installed Python, but > remains isolated from anything in its 'site-packages'. Yes, I know what virtualenv is, I use it sometimes - but it is definitely too complicated for the people I want to distribute my software to. > > I never even use that switch manually. zc.buildout does, but that is > because it wants to control the PYTHONPATH by generating the script > code: it doesn't ask users to tweak that. Well, that's the thing: neither do I :) but if my software is a dependency of another software, then I am bothered for problems with software which are not used at all by my own package (because setuptools makes an egg of my software automatically, screw things up, and I am the one blamed for it). > > I don't know why anybody who was not writing a packaging tool, or > packaging a library for something like .deb / .rpm, would even use the > multi-version option for setuptools: I don't see any sane way to > install conflicting requirements into a shared 'site-packages'. But that's the problem: it often happens *even if you don't use setuptools yourself*. I would not be surprised if that's one reason why so many people have a seemingly unfair bias against setuptools. That's certainly the reason in my case. 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
