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 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. Well you can't have it both ways, either you want a series of sandboxed applications or you don't. If you don't and are happy to have all your application dependencies tracking Debian unstable rather than using the versions you tested them with, then going with the Debian packages is probably a good choice but I don't think that situation will apply to many people very often. Btw it isn't hard to manually upgrade a series of virtual python or workingenv installs, you just issue easy_install -U "PackageName==new_version_you_want", you could automate it easily if that was an issue for you. > Indeed. If there is a way to package everything Python-wise then creating a > Debian package from it should work. I don't know if you've read the easy_install, virtual python and workingenv docs but they are really very flexible systems which avoid the problem of being "forced" to use the version that are in Debian. Hope that's useful too! Cheers, James --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
