On Fri, Apr 02, 2010 at 04:23:25PM +0200, Adam GROSZER wrote: > MG> On Fri, Apr 02, 2010 at 12:29:48PM +0200, Adam GROSZER wrote: > >> Hello Wichert, > >> > >> Because of our toolchain to release and deploy apps: mypypi and > >> keas.build. In fact, because of keas.build depends on zc.buildout. > >> > >> Friday, April 2, 2010, 10:53:26 AM, you wrote: > >> > >> WA> On 4/2/10 10:36 , Adam GROSZER wrote: > >> >> zc.buildout is a tough decision, because it's "not upgrading" issue. > >> >> See > >> >> http://mail.python.org/pipermail/distutils-sig/2010-March/015794.html > >> > >> WA> Why would you ever install zc.buildout systemwide? Just as with > >> WA> setuptools I consider that to be a recipe for problems. > > MG> Why not do > > MG> python2.x bootstrap.py > > MG> and then use > > MG> bin/buildout > > MG> instead of the globally-installed buildout? > > MG> Marius Gedminas > > The way you install your app with is: > > $ install -u https://build.twollo.com/buildouts/ -p Twollo -V QA --latest > > Where the install script comes with keas.build.
Overriding the standard Unix 'install' command is not a good idea IMHO. In fact it's a Bad Idea. > At this point nothing exists from your app on the server, not even a > .cfg or svn checkout. > This invokes "buildout -c > https://build.twollo.com/buildouts/Twollo-QA-2.3.4.cfg -t 2...." > or something like this. > (See http://pypi.python.org/pypi/keas.build/0.1.6 for details) > That will gather all necessary packages from (your private) pypi > server. An interesting approach. Looks quite reasonable from first sight. > And that's why I would need zc.buildout installed globally. > It seems to be rather easier to do on a new server: > <install setuptools> > $ easy_install zc.buildout==<whatever version> > $ easy_install keas.build > $ install <my favourite app's install parameters> > and done > > I know, doing a checkout and bin/buildout sounds easier, but there's a > lot more behind keas.build than just ``install``. > > The actual problem is that zc.buildout launched by keas.build must be > the same version as pinned in the .cfg. Maybe it would make sense to add a command-line option for buildout to override version pins? bin/buildout -t 2 -c configfile --pin zc.buildout=1.4.3 \ --pin setuptools=0.9c11 with "--pin zc.buildout=" meaning "use latest version, disregarding the pin in the config file." > A long story... Maybe I just should kick zc.buildout to upgrade itself > in the above situation. That would be the best on the long run. Or that. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
signature.asc
Description: Digital signature
_______________________________________________ Zope-Dev maillist - [email protected] https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
