Re: Deplyoing Pylons applications as Debian packages?
On 3/4/07, Christoph Haas [EMAIL PROTECTED] wrote: Dear list, I'm spending some of my spare time as a Debian developer which means creating Debian (binary) packages from software. In Debian you don't use easy_install to install Python modules but rely on packages that the distribution provides. E.g. to install Pylons and all it's dependencies you issue an aptitude install python-pylons which means that certain other packages are installed automatically: python python-routes python-myghty python-paste python-pastedeploy python-pastescript python-formencode python-simplejson python-webhelpers python-nose python-beaker Naturally I wondered how to properly deploy a self-made Pylons application on Debian. Perhaps someone with more insight of the Paster deployment process can help understand what's going on and whether that can be scripted to make it a Debian package. Or perhaps other readers who are familiar with Debian package have an idea, too? I could imagine a tool like pylons-buildpackage which creates a Pylons application and makes a proper Debian package of it that can be apt-installed. I'm eager to hear other people's ideas on that. For those not being involved into Debian package management: a Debian package takes the (upstream) software itself (usually a software-1.0.tar.gz file) and adds a special debian/ subdirectory that contains control information on the page. Such information deals with copyright, what other packages are needed (as stated above), which files are to be put where in the file system and a Makefile/shell script that is run to make the software (like ./configure; make; make install). 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. -jj -- http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deplyoing Pylons applications as Debian packages?
Piotr Ozarowski wrote: # creating new Pylons app. $ paster create --template=pylons helloworld # creating Egg (f.e. for Windows users) $ python setup.py bdist_egg # will create an Egg in dist dir # creating debian package $ zcat ../helloworld_0.0.0dev-1.diff.gz | patch -p1 # see attachment $ debuild and (as promised on #debian-python) here's pure debhelper version (init.d script is still missing) To Pylons ML readers: here's CDBS one: http://lists.debian.org/debian-python/2007/03/bin0.bin If you're using pkg_resources(), add python-setuptools to Depends: (and other used dependencies, like: python-elixir, python-mako, ...) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- helloworld_0.0.0dev-1.diff.gz Description: application/gunzip pgpdazftrFshC.pgp Description: PGP signature
Re: Deplyoing Pylons applications as Debian packages?
Hi Christoph, I use Debian and the way I deploy my apps is using a virtual Python installation into a user account I setup for each app. I usually then just checkout the latest source code and run: ~/bin/python setup.py develop The problem with trying to package up a Pylons app into a Debian package is that you have to worry about all the dependencies. You could package up all the dependencies too but that would be a pain. I suppose the alternative solution if you really want to use a Debian package is to setup workingenv and then make a package out of the entire workingenv directory with the dependencies included as part of the one package. I've always been happy to stick to using easy_install and eggs myself but when packages have C extensions the benefits of creating .debs become more apparent. Also it is useful to have different packages available to different Pylons apps and if you just use .debs to install software into the main Python directories you can't do that. I'd be interested to hear if you come up with a good solution though? Cheers, James Christoph Haas wrote: Dear list, I'm spending some of my spare time as a Debian developer which means creating Debian (binary) packages from software. In Debian you don't use easy_install to install Python modules but rely on packages that the distribution provides. E.g. to install Pylons and all it's dependencies you issue an aptitude install python-pylons which means that certain other packages are installed automatically: python python-routes python-myghty python-paste python-pastedeploy python-pastescript python-formencode python-simplejson python-webhelpers python-nose python-beaker Naturally I wondered how to properly deploy a self-made Pylons application on Debian. Perhaps someone with more insight of the Paster deployment process can help understand what's going on and whether that can be scripted to make it a Debian package. Or perhaps other readers who are familiar with Debian package have an idea, too? I could imagine a tool like pylons-buildpackage which creates a Pylons application and makes a proper Debian package of it that can be apt-installed. I'm eager to hear other people's ideas on that. For those not being involved into Debian package management: a Debian package takes the (upstream) software itself (usually a software-1.0.tar.gz file) and adds a special debian/ subdirectory that contains control information on the page. Such information deals with copyright, what other packages are needed (as stated above), which files are to be put where in the file system and a Makefile/shell script that is run to make the software (like ./configure; make; make install). 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? :) Kindly Christoph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deplyoing Pylons applications as Debian packages?
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 pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deplyoing Pylons applications as Debian packages?
On 3/5/07, James Gardner [EMAIL PROTECTED] wrote: Hi Christoph, I use Debian and the way I deploy my apps is using a virtual Python installation into a user account I setup for each app. I usually then just checkout the latest source code ... I see your version-control system isn't behind a firewall. :) -- 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 pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deplyoing Pylons applications as Debian packages?
On Monday 05 March 2007 22:29, Ian Bicking wrote: Christoph Haas wrote: I could imagine a tool like pylons-buildpackage which creates a Pylons application and makes a proper Debian package of it that can be apt-installed. I'm eager to hear other people's ideas on that. FWIW, I think such an installer should package up all the libraries in one Debian package, I imagine laid out something like: /usr/lib/some-pylons-app/lib/python/(bunch of eggs) I don't believe it would make things easier. All components like python-sqlalchemy, python-mako, python-webhelpers or python-pylons are already packaged for Debian. If by all the libraries you mean these packages it would create a second installation of them on a system which is not desirable. It would be best if the Pylons user who is about to create a Debian package sets up the proper (Debian-)dependencies in the debian/control file so just the Pylons project itself needs to be packaged. I use workingenv and a workingenv requirements file, and some shell scripts to do the setup from there. I haven't worked with workingenv yet. Is it feasable to ship an application with all the needed dependencies into such a chroot and run them on a production system? Christoph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deplyoing Pylons applications as Debian packages?
On Mon, 2007-03-05 at 22:29 +0100, Christoph Haas wrote: But installing anything using easy_install - and be it just into /usr/local - is chaotic and hard to control. easy_install cannot even remove software properly. So I don't think I would want anything than a binary deb package on my system. Just as a side note to Shannon Behrens who said We're on Ubuntu, and we just use eggs. If you really just install eggs instead of proper binary packages then your Ubuntu package management will get into trouble in no time. (For those not familiar with it: Ubuntu is a sister project of Debian and uses the same package format.) Why is this so? I don't use Ubuntu (rather Gentoo and Fedora), but the problem is mostly the same. Frankly I tend to avoid all distro-provided Python packages and use easy_install exclusively. I think there might be issues mixing the two methods, but I'm not entirely clear how selecting easy_install *exclusively* over the system package manager makes anything worse. I will note that there are two main reasons I prefer easy_install: 1) The packages provided by most distros tends toward the stale side and tend to be far less inclusive than the Cheeseshop. This means that *no matter what* I'd be forced to use easy_install on some packages at some point. If anything is going to cause issues, it's *mixing* easy_install with apt/rpm/emerge/etc. Were I to choose using the system package manager I'd have a rather smallish selection of slightly (or badly) out-of-date packages with no obvious benefit in exchange for this sacrifice. Given that this is the case, selecting to use easy_install exclusively appears to be a no-brainer. 2) For my specific environments, I utilize user-owned site-packages directories (which helps with maintaining version compatibility for deployed applications and allows users to install/maintain their own required packages). This is probably not possible using the system packaging tools. I'll add that while it's true that easy_install cannot remove packages properly, doing so manually is hardly problematic (remove the .egg and its corresponding entry from easy_install.pth). This doesn't resolve dependency issues, but frankly those aren't nearly as much of an issue with Python as they are at the OS level (simply by nature of Python's more limited scope and influence on the system at large). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deplyoing Pylons applications as Debian packages?
[Cliff Wells, 05.03.2007] On Mon, 2007-03-05 at 22:29 +0100, Christoph Haas wrote: But installing anything using easy_install - and be it just into /usr/local - is chaotic and hard to control. easy_install cannot even remove software properly. So I don't think I would want anything than a binary deb package on my system. Just as a side note to Shannon Behrens who said We're on Ubuntu, and we just use eggs. If you really just install eggs instead of proper binary packages then your Ubuntu package management will get into trouble in no time. (For those not familiar with it: Ubuntu is a sister project of Debian and uses the same package format.) Why is this so? You can install your Pylons app. and forget about dependencies for next 2 years. Package maintainers will fix all bugs in related packages. Sure, developers like ez_install. System administrators don't! -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpyit1Asp71B.pgp Description: PGP signature
Re: Deplyoing Pylons applications as Debian packages?
Christoph Haas wrote: Of course I understand that many people find easy_install a good and simple way to install Python packages. But it will destabilize an operating system that keeps track of what's installed. It may be no problem on Windows where you reinstall after a few months anyway. But my Debian system has been installed years ago and just upgraded with the time. I wouldn't want to have cruft flying around. Especially since there is no sane way to get of software I easy_install'ed. So I disagree with your opinion that Python-related software that is shipped through easy_install should blindly be used on any system. If that's what you wanted to express. You shouldn't install into system areas with easy_install -- you should use some kind of isolated environment like workingenv, virtual-python, or zc.buildout. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deplyoing Pylons applications as Debian packages?
On Mon, 2007-03-05 at 23:42 +0100, Piotr Ozarowski wrote: [Cliff Wells, 05.03.2007] On Mon, 2007-03-05 at 22:29 +0100, Christoph Haas wrote: But installing anything using easy_install - and be it just into /usr/local - is chaotic and hard to control. easy_install cannot even remove software properly. So I don't think I would want anything than a binary deb package on my system. Just as a side note to Shannon Behrens who said We're on Ubuntu, and we just use eggs. If you really just install eggs instead of proper binary packages then your Ubuntu package management will get into trouble in no time. (For those not familiar with it: Ubuntu is a sister project of Debian and uses the same package format.) Why is this so? You can install your Pylons app. and forget about dependencies for next 2 years. Package maintainers will fix all bugs in related packages. There is almost zero chance of that happening in the Python world, no matter who's working on it. In fact, if I install a Pylons app written around Pylons 0.9.x, it's almost guaranteed that letting the system package manager update Pylons will break that app at some point in the not-so-distant future (in fact this exact issue around TurboGears was the very reason I moved solely to easy_install). This problem isn't Python-specific either. You'll note that almost all Ruby users use gem to install packages as well. I've also found that PHP does better when using PEAR for the most part. The single exception I've found where the system packaging tools do a better job is when there are C extensions involved (and hence a reliance on system libraries and a dependency tree that might fork outside the realm of Python and easy_install). Sure, developers like ez_install. System administrators don't! That's odd, because I do equal parts of both and greatly prefer easy_install. On my shared hosting boxes, I can use easy_install to maintain specific versions of Python packages as required by specific applications for specific users, something not easily doable (or doable at all) using the system packaging tools. Note that I'm not suggesting that for *some* people using the system tools might not be preferable to easy_install nor that pursuing the packaging of Python libraries and apps as debs/rpms/ebuilds or whatever is a waste. I am, however, contesting the blanket assertions that using easy_install leads to chaos (it doesn't) or that system administrators prefer the system tools over easy_install (this is pure speculation based on the assumption that the sysadmin is clueless about easy_install/gems/PEAR/cpan/et al). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deplyoing Pylons applications as Debian packages?
[Cliff Wells, 05.03.2007] On Mon, 2007-03-05 at 23:42 +0100, Piotr Ozarowski wrote: You can install your Pylons app. and forget about dependencies for next 2 years. Package maintainers will fix all bugs in related packages. There is almost zero chance of that happening in the Python world, no matter who's working on it. Gaupol package (subtitle editor) will be shipped with version 0.7.1 in Debian Etch. This version does not work with new PyGTK. I, as a package maintainer, will make sure [1] that even if someone decides to upload new PyGTK, Gaupol users will have working app. [1] by applying fix from 0.7.2 or forcing new upstream into Etch In fact, if I install a Pylons app written around Pylons 0.9.x, it's almost guaranteed that letting the system package manager update Pylons will break that app at some point in the not-so-distant future (in fact this exact issue around TurboGears was the very reason I moved solely to easy_install). package maintainer will not upload new upstream version to stable (production) distribution. So if you created your app with 0.9.x and distribution contains Pylons 0.9.x - you don't have to worry. Sure, developers like ez_install. System administrators don't! That's odd, because I do equal parts of both and greatly prefer easy_install. On my shared hosting boxes, I can use easy_install to maintain specific versions of Python packages as required by specific applications for specific users, something not easily doable (or doable at all) using the system packaging tools. You know Python, you know how to fix bugs in apps written in Python. Now, lets imagine this: User does not know Python and Pylons at all, he does not follow sqlalchemy, routes, etc. mailing lists and thus will not be aware of security bugs in these modules. He just saw an outstanding app. on a website and decided to install it on his server. He's regularly updating his system, because he knows that if there will be a serious bug discovered in one of his apps or in one of dependencies - update will be available soon. He don't need new fancy version, all he wants is working app. Will you still recommend him to install this app. with ez_install? Now lets say there's new stable version of distribution he uses and our User decides to dist-upgrade to the new version. Will you recommend him to do this upgrade with ez_install? Will you tell him to remove old app first? Will you tell him to reinstall his system first? Will x (and x is a lot) users test this upgrade first? Note that I'm not suggesting that for *some* people using the system tools might not be preferable to easy_install nor that pursuing the packaging of Python libraries and apps as debs/rpms/ebuilds or whatever is a waste. I am, however, contesting the blanket assertions that using easy_install leads to chaos (it doesn't) or that system administrators prefer the system tools over easy_install (this is pure speculation based on the assumption that the sysadmin is clueless about easy_install/gems/PEAR/cpan/et al). I have no idea how gems work, but I still want to use apps written in Ruby. Will you tell me to learn how to use them? (Please note that I already know how to use debs) My point is: not everyone wants newest software. Some people want *stable* software and there are lots of system administrators among them. PS I really should be sleeping now :-( -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp49IKdFUBHF.pgp Description: PGP signature
Re: Deplyoing Pylons applications as Debian packages?
On Mar 5, 2007, at 8:08 PM, Piotr Ozarowski wrote: PS I really should be sleeping now :-( Yes, you should but you really raise some valid points even in your altered state ;-). S Stephen F. Steiner Integrated Development Corporation [EMAIL PROTECTED] www.integrateddevcorp.com (603)433-1232 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Deplyoing Pylons applications as Debian packages?
Piotr Ozarowski wrote: Now, lets imagine this: User does not know Python and Pylons at all, he does not follow sqlalchemy, routes, etc. mailing lists and thus will not be aware of security bugs in these modules. He just saw an outstanding app. on a website and decided to install it on his server. He's regularly updating his system, because he knows that if there will be a serious bug discovered in one of his apps or in one of dependencies - update will be available soon. He don't need new fancy version, all he wants is working app. Will you still recommend him to install this app. with ez_install? The *application* can be shipped as a package without shipping lots of individual libraries. The application package should contain all the libraries that are not already in Debian, and perhaps some of the libraries that already are in Debian if something has been inappropriately packaged. That is, there's *no* way that Mako is at a point when it should be released as a package (or quite a few of the packages used in a typical Pylons application). But an *application* can still be stable despite that, because the application only uses the areas of the library that are stable. However, you should never force newer packages to use an old version of an unstable library just because someone else used it previously; nor should you force a potentially difficult upgrade and repackaging of the application because of a library upgrade that wouldn't effect it. Users who don't know Python or Pylons don't install Python or Pylons libraries, they install applications, and those applications can and should be largely self-contained when installed. Users who do know Python and Pylons and want to hack on software shouldn't use Debian packages. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---