Re: Deplyoing Pylons applications as Debian packages?
On Tuesday 06 March 2007 02:17, Stephen F. Steiner wrote: 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 ;-). He raised a lot of valid points that widely used GNU/Linux distribution is based upon. I really start to wonder why you prefer having the newest software over having stable versions that developers and administrators can rely on. But I can only assume that you haven't worked with Debian or even RPM-based distributions. I stand my point... blindly installing software that you can't get rid of and just update versions and not caring for other people's applications isn't quite admin like. On your own workstation that may be feasable. But if I break our intranet web site just because I was in the mood of updating some component I'd have a nice talk with my boss. Perhaps you can show some arguments telling why this is bad. The Debian developers have been discussing the whole egg problem for a while now because - just as we see here - people think different. And I don't claim this is the perfect solution. But Debian will never have stable versions that suddenly change in behavior. Debian of course has other components that include daily changes. So if you like a newer version of python-mako you just install it from there (the so called testing and unstable branches - although their names are misleading). It's even an automatic process to update your packages. But on my intranet server there will be the same version of Mako for two years until I find time to evaluate what has changed. 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?
Hi Christoph, I think there are two issues here: 1. People like to install multiple versions of the software on the same machine 2. Python software, pylons included, isn't as stable from version to version as most of the software in Debian stable Although Debian packages are brilliant when you want a system-wide installation of a particular piece of software, they are less good when you want multiple versions of the same software installed on the same machine. A lot of the arguments you've made also make the assumption that any Debian package is going to be stable from one release to the next due to the efforts of the maintainer to ensure a smooth upgrade path. That works fine for system packages but seriously, Python software develops at a much faster rate than say Apache and whilst we try to maintain backward compatibility in Pylons, there are still one or two very small incompatibilities along the 0.9.x branch which I do not believe could easily be solved by a package maintainer because otherwise we would have solved them ourselves in the first place! The truth is that incompatibilities between different versions of Python software aren't *solved* by the packaging mechanism so Debian packages can't be better in that regard than using easy_install. The issue really boils down to which system you understand better. For most people who understand easy_install *and* the Debian package management system, easy_install with workingenv or a virtual Python install is the best approach and the one we will continue to recommend. As I mentioned in my first email though, if you can find a way of neatly packaging a virtual Python install or a workingenv install into a Debian package, that might be a good compromise between the two! Hope that helps, James --~--~-~--~~~---~--~~ 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?
James, thanks for your point-of-view. I hope mine isn't seen as trolling. I'm seriously trying to find a way to unite both the easy_install and the deb-package world. And at the moment everybody just seems to defend their own position. Many Python developer probably don't even care for Debian. :) On Tuesday 06 March 2007 11:57, James Gardner wrote: 1. People like to install multiple versions of the software on the same machine Why is that needed in reality? To try out the newest features? Or are there really multiple applications on a server where each one uses different versions of software? I'm running Debian's unstable branch at home which means having mostly the same versions of Python modules installed that are in the CheeseShop - just as Debian packages. 2. Python software, pylons included, isn't as stable from version to version as most of the software in Debian stable The application I am currently about to write should be running for years (at least a Debian stable period which is 1-3 years) without having to bother about new Pylons versions. So my intent is to use the current Paste version and the current Pylons version (and what else is needed). Debian stable doesn't mean that all the packages are perfectly stable. It means that a certain set of software packages is frozen and put into one distribution. Everybody who develops for that Debian stable release will always know which versions are available. The only drawback: while other developers may already use features of newer versions they are stuck with the ancient version from the time the software was frozen. A lot of the arguments you've made also make the assumption that any Debian package is going to be stable from one release to the next due to the efforts of the maintainer to ensure a smooth upgrade path. That works fine for system packages but seriously, Python software develops at a much faster rate than say Apache and whilst we try to maintain backward compatibility in Pylons, there are still one or two very small incompatibilities along the 0.9.x branch which I do not believe could easily be solved by a package maintainer because otherwise we would have solved them ourselves in the first place! I understand that. But wouldn't it be feasable to just use a set of packages that are considered stable _now_ and use them for the next time? I know a few web developers who prefer a stable API over the newest features. When working with Pylons I currently get these annoying deprecation versions because the version of Pylons here didn't work with the newer Paste version. If I had the old versions installed I didn't have to deal with such issues. The truth is that incompatibilities between different versions of Python software aren't *solved* by the packaging mechanism so Debian packages can't be better in that regard than using easy_install. That's right. The pace is a bit slower if you stay with Debian stable. But there is a time that you surely update the software and then applications may break. At least during that period nobody has to expect surprises. The issue really boils down to which system you understand better. For most people who understand easy_install *and* the Debian package management system, easy_install with workingenv or a virtual Python install is the best approach and the one we will continue to recommend. I'll start working with it and see if that's feasible. That approach surely has advantages. You always have the newest version if you like. And you don't have to create another package from something that looks like a package already. Say, is there a way to package a Pylons application with all dependent packages into a single egg? I mean... if there would be an easy way to distribute an egg that creates a workingenv without interfering with the rest of the system that is at least one valid approach. You will just have multiple versions flying around and it hurts me to not be able to update them all at once. After all a security flaw may go unnoticed because the system has no notion of that local installation. As I mentioned in my first email though, if you can find a way of neatly packaging a virtual Python install or a workingenv install into a Debian package, that might be a good compromise between the two! Indeed. If there is a way to package everything Python-wise then creating a Debian package from it should work. 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?
Hi Christoph, thanks for your point-of-view. I hope mine isn't seen as trolling. I'm seriously trying to find a way to unite both the easy_install and the deb-package world. And at the moment everybody just seems to defend their own position. Many Python developer probably don't even care for Debian. :) No, I understand, there are pros and cons to both approaches. Why is that needed in reality? To try out the newest features? Or are there really multiple applications on a server where each one uses different versions of software? Well, for example I have authkit.org, formbuild.org, 3aims.com, pythonweb.org and a load of test applications under 3aimsapps.com all running on the same server. I updated authkit.org more recently than 3aims.com so it runs a different version of Pylons. Because there are minor changes between different Pylons versions it is handy to sandbox each installation so that I can start a new project with the latest Pylons without changing the software used by the old ones which I've tested and know works. I'm running Debian's unstable branch at home which means having mostly the same versions of Python modules installed that are in the CheeseShop - just as Debian packages. That's fine then, you just have to make sure all your application are constantly modified so they work with whatever is in unstable at any particular moment. That could be tricky though because those packages will probably change fairly often. I prefer to sandbox each Pylons app in its own virtual install so each app can use whichever versions are most appropriate for it. That way I don't have to worry about ensuring I'm always using the latest software for each app but I know that the app is using the software I tested it with. It is really just the most pragmatic approach. The application I am currently about to write should be running for years (at least a Debian stable period which is 1-3 years) without having to bother about new Pylons versions. So my intent is to use the current Paste version and the current Pylons version (and what else is needed). Great, well use a virtual Python install with easy_install and you won't have to worry about it again because the Pylons dependencies are kept separate from the constantly changing versions in Debian unstable. I understand that. But wouldn't it be feasable to just use a set of packages that are considered stable _now_ and use them for the next time? Yes but it is up to you which ones you consider stable for your purposes. By using a virtual Python install and easy install you can make that decision based on your needs rather than having to use whatever the Debian packagers decide is best. I know a few web developers who prefer a stable API over the newest features. When working with Pylons I currently get these annoying deprecation versions because the version of Pylons here didn't work with the newer Paste version. If I had the old versions installed I didn't have to deal with such issues. Well, if you used a virtual Python install and easy_install you could just setup your application to use the old version of Paste that doesn't have the warnings. It is about control being in the hands of the developer (who knows what is best for their application) rather than in the hands of the package maintainers. That's right. The pace is a bit slower if you stay with Debian stable. But there is a time that you surely update the software and then applications may break. At least during that period nobody has to expect surprises. But it works on an a very long cycle, the release cycle for Pylons is about 3 months max with lots of changes to the dependencies along the way so the Debian model doesn't fit projects like Pylons so well. That's not to say we won't eventually or either to imply the Debian approach is better, they are just different. I'll start working with it and see if that's feasible. That approach surely has advantages. You always have the newest version if you like. And you don't have to create another package from something that looks like a package already. Let me know if it works! Say, is there a way to package a Pylons application with all dependent packages into a single egg? I mean... if there would be an easy way to distribute an egg that creates a workingenv without interfering with the rest of the system that is at least one valid approach. I don't understand why you'd want to do this. You can specify the *exact* dependencies you wish to use (down to the version number of an SVN checkout if you like) in your setup.py file and they'll be automatically installed with easy_install so you always ensure the exact dependencies your app needs are installed anyway. You can even specify that easy_install should install the required eggs from your server rather than the cheeseshop you can guarantee your packages are going to be installed. You will
Re: Deplyoing Pylons applications as Debian packages?
On 3/5/07, Christoph Haas [EMAIL PROTECTED] wrote: Piotr, On Monday 05 March 2007 21:49, Piotr Ozarowski wrote: 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, ...) Thanks for sharing your thoughts. This is very close to what I had in mind but didn't know how to do it exactly. Creating a simple (native) Debian package from an egg file is a good way to make Debian's package maintenance system know about the Pylons application. Your patch creates a working Debian package already. And there are two things I intend to do in the next days: - create a script that debianizes a Pylons project (similar to dh_make) trying to create proper dependencies, an init.d script etc. - write an article on how to deploy Pylons projects as Debian packages (currently working on) Of course a Debian package has the drawback that you need root permissions to install the package. Then again a user can probably just take the *.egg file and put it into their $PYTHONPATH to run it with user permissions. 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.) Thanks for the comment. Perhaps, but I doubt it. Given the choice between an egg and a Debian package, I lean toward using eggs. My system is not a chaotic mess because I'm hyper attentive to documenting everything I do as root. I keep track of everything I install, including dependencies. I do wish I could delete eggs more easily, though. I'm not saying that this is how it should always be. I'm just saying that this is what works for me. Best Regards, -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?
On 3/6/07, James Gardner [EMAIL PROTECTED] wrote: 2. Python software, pylons included, isn't as stable from version to version as most of the software in Debian stable A lot of the arguments you've made also make the assumption that any Debian package is going to be stable from one release to the next due to the efforts of the maintainer to ensure a smooth upgrade path. That works fine for system packages but seriously, Python software develops at a much faster rate than say Apache and whilst we try to maintain backward compatibility in Pylons, there are still one or two very small incompatibilities along the 0.9.x branch which I do not believe could easily be solved by a package maintainer because otherwise we would have solved them ourselves in the first place! We're comparing brand-new unstable Python projects with mature other software. The versions are 1.0 to indicate this. Pylons is at 0.9.4, Mako is 0.1.3, Genshi is 0.3, SQLAlchemy is 0.3.4, setuptools is 0.6c5. 0.x means we're still verifying the API is robust enough for the real world so it may be subject to change. In contrast, Apache has three production branches which are guaranteed stable (2.2, 2.0, 1.3). Vim is 7.0, and has built an expectation that it should more or less work the same when upgrading from 6.0 or 5.0. How many people even care which version of vim it is, because they only use features that have existed for years? The nature of Python also has something to do with it. It's so easy to try out an innovation and publish it that people do it all the time. And other people want or need the latest and greatest, even though the OS package developers can't keep up. Virtual Python is looking better and better for deployed Pylons sites. Setuptools needs to grow an uninstall option, upgrade-dependencies, etc. Then it will be easier to upgrade a site with one command. -- 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/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 -~--~~~~--~~--~--~---
