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 [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
-~----------~----~----~----~------~----~------~--~---

Reply via email to