Jeff Younker wrote:
That's good and fine for the situation where one application is
being deployed on a Python installation, but that isn't a very realistic
situation. There is usually more than one application/script/whatever
running off of a given Python installation.
Here's an example of ho
Jeff Younker wrote:
Thats a great theory, but that's not how the real world works. Python
packages are an ecology where there will be inconsistencies between
different minor versions of the same package.
I'm not sure what you're arguing here. If you're saying
that having a version management
On Apr 15, 2008, at 9:09 PM, Greg Ewing wrote:
David Cournapeau wrote:
Greg Ewing wrote:
If they really do need different versions, this is insoluble.
But that's by far the most significant problem of packages with a
lot of
dependencies !
But if your application really does depend on t
David Cournapeau wrote:
> Greg Ewing wrote:
>
> > the earlier versions would *never be used*
> > even if they were installed.
>
> What's the point of having it installed, then ? I am confused.
I never said there was a point. When I mentioned multiple
installed versions, I was talking about multi
Greg Ewing wrote:
>
> But if your application really does depend on two libraries that
> have conflicting requirements like this, the application itself
> is screwed to begin with. There's *no* way of making it work
> on *any* system, whether that system has library versioning or
> not.
Of course.
David Cournapeau wrote:
> Greg Ewing wrote:
>
> > If they really do need different versions, this is insoluble.
>
> But that's by far the most significant problem of packages with a lot of
> dependencies !
But if your application really does depend on two libraries that
have conflicting requireme
Paul Moore wrote:
> Is nobody but me seeing shades of Windows "DLL hell" in all of this?
I think DLL Hell occurred partly because people *didn't*
distinguish different API versions clearly with different
file names.
Also because programs were allowed to put shared stuff
in the system directory w
Greg Ewing wrote:
>
> If they really do need different versions, this is insoluble.
>
But that's by far the most significant problem of packages with a lot of
dependencies ! And by enabling multiple versions, side by side, you will
make this problem more pervasive.
I don't know if you have e
David Cournapeau wrote:
> Library versioning without API
> stability just does not make sense to me.
Yes, obviously if you have library versioning you need to
use it properly in order for it to be any use.
> How do you do if you have a package D
> which depends on both C and B, and C needs one
Paul Moore wrote:
>
> Is nobody but me seeing shades of Windows "DLL hell" in all of this?
Dll hell was caused because there was no versioning, and new dll
overwrote older ones, while not being compatible. If we add a versioning
checking, we won't have dll hell problem, but dependency hell, actu
On 15/04/2008, Greg Ewing <[EMAIL PROTECTED]> wrote:
> That's a nice ideal to aim for, but it's only achievable
> for old and mature packages.
>
> One could change the package name every time the API
> changes, but then *any* change to the API would make the
> package unusable by apps expecting an
Cliff Wells wrote:
>
> I think the convention is major.minor where minor releases are
> backwards-compatible and major releases aren't expected to be (but might
> be).
>
AFAIK, that's the general rule, but python itself does not respect this
convention, so I don't see this happening for pyth
On Tue, 2008-04-15 at 13:01 +1200, Greg Ewing wrote:
> David Cournapeau wrote:
> > what is needed is a stable API for the used packages.
>
> That's a nice ideal to aim for, but it's only achievable
> for old and mature packages.
I don't think so. It requires vigil on the part of the maintainer,
Greg Ewing wrote:
> David Cournapeau wrote:
>> what is needed is a stable API for the used packages.
>
> That's a nice ideal to aim for, but it's only achievable
> for old and mature packages.
>
Yes, many packages can't have a stable API, at least for some time. But
then, should you rely on them
David Cournapeau wrote:
> what is needed is a stable API for the used packages.
That's a nice ideal to aim for, but it's only achievable
for old and mature packages.
One could change the package name every time the API
changes, but then *any* change to the API would make the
package unusable by a
15 matches
Mail list logo
