On 3/5/07, Shannon -jj Behrens <[EMAIL PROTECTED]> wrote: > > On 3/4/07, Christoph Haas <[EMAIL PROTECTED]> wrote: > > I'm also interested in how other Debian users deploy Pylons applications. > > Do you just copy the project directory onto another computer? Or do you > > deploy into /usr/local? Or am I the only one using Debian here? :) > > We're on Ubuntu, and we just use eggs.
Another Ubuntu user here. (Though some of my computers are still on Gentoo.) Ultimately the Python community and Linux distributors have to agree on how to repackage eggs in their distribution format. At the PyCon session we didn't get any farther than "this is a problem", and noted that there are disadvantages as well as advantages of using eggs in distributions, not to mention the multiplicity of formats a distro would have to accommodate: Python eggs, Ruby Gems, Java JARs, Perl whatevers. I'm not sure it's worth trying to solve this ourselves as Pylons users. For personal/organizational applications, distributing eggs is much easier than making an OS package. Rsync'ing the application directory to the server is easier still. Deploying a zipped egg is a compromise between the two. Though copying a zipped egg doesn't update its dependencies, so you'd have to do that manually or reinstall the egg (ugh). For distributing Pylons applications publicly, an egg is still easier at this stage. One problem is documentation, which is not included in eggs. Either egg developers should start including them as data files, or eggs need a separate documentation category. In the meantime there's an argument for distributing the source tarball instead of an egg, and installing it in development mode, because that keeps the code and docs together. If in fact there will be any publicly-distributed Pylons applications that aren't just examples. Unfortunately not all distros have gotten the "local site-packages directory distinct from the OS's site-packages directory" concept yet. So one must either install into the global site-packages or use virtual python or workingenv. I'm leaning toward virtual python as the most foolproof and auditable. Theoretically eggs should declare all their dependencies. This leads to duplicate libraries if the same library is installed at the OS level. Organizations can determine a standard set of libraries maintained at the OS level that will be excluded from local eggs. This won't work with publicly-distributed eggs of course. But if the sysadmin has a local site-packages directory and installs libraries there as eggs, easy_installing the application egg would skip reinstalling the library. But just copying a zipped egg will not update its dependencies, so there's the hassle of reinstalling it in case its dependencies have changed. So there's not really one way to do it. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
