Jim Fulton wrote: > > Are you aware of zc.sourcerelease? > > http://pypi.python.org/pypi/zc.sourcerelease >
No ! thanks for mentioning it. We did a similar tool that creates tarballs over buildouts (http://pypi.python.org/pypi/iw.releaser) it also works at eggs level to release them, then control that there's no more "develop" section in the buildout, builds it and create a tarball with offline options. (and does svn tags) -> I need to drop the tarball part in favor of zc.sourcerelease I guess Jim Fulton wrote: > >> Now I am working on the best ways to prepare upgrades for the >> production and I try to find a way to avoid recreating a big tarball >> again just for a few changes. > > IMO, the benefit doesn't justify the extra complexity. IMO, > deployments should involve as little thought and thus risk as > possible. Our RPMs typically install in a few seconds, which is fast > enough for me. :) > I agree, but in some cases, my fellows that does upgrades from SSH or Terminal Server are angry because they have to upload a big tarball that often weight > 100 megas just for two changes in some python files. They also argue that sometimes it can be a pain with some firewalls rules. So my idea was to try to make their life easier in that case. The current work consists of creating buildout releases in svn branches after the buildout is created, with a small '.snapshot' file in the folder. It's a shorcut to avoid a complex scanning of .installed.cfg for instance. It lists all folders and files (non recursive) that where collected in the eggs/ folder and the download-cache (and its dist) folders in a flat list. On the next release, the tool knows how to build a small tarball by comparing what is has collected with the .snapshot of the previous release. (work in progress) Jim Fulton wrote: > >> My guess is that a snapshot of the download-cache and eggs directory >> is enough, so a diff can be made to "upgrade" a production server >> with a tarball of the two directories and the new .cfg >> >> But I was wondering if someone had similar experiences already, and >> maybe a simple, better way ? > > > There are ways to use a download cache to speed creation of a source > release. If you're interested, I could expand on this. > I'd love to learn more, please :) ++ Tarek -- View this message in context: http://www.nabble.com/buildouts-upgrades-in-production-tp14296760p14312913.html Sent from the Python - distutils-sig mailing list archive at Nabble.com. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
