Re: [Distutils] Simple idea to resolve versioning problems
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. I was just stressing that versioning does not solve the deployment problem, but merely is a small part of the solution. > > Consequently, the developer will be unable to make it work on > his own machine, and will therefore never attempt to deploy it! It can happen easily once you have different systems: maybe on my os it is not a problem, but maybe it is on yours. Python is not exactly the same everywhere, the version of python is not the same everywhere, etc... > > That's what I'm talking about! As long as the API remains > backward compatible, there is no need to have anything but the > latest version installed -- and in fact, in the kind of system > I have in mind, the earlier versions would *never be used* > even if they were installed. What's the point of having it installed, then ? I am confused. >> IOW, enabling version requirement without strong API compatibility is >> the path to dependency hell. > > I fully agree. However, this is a social issue, not a > technical one. Yes, that's mainly a social issue, which is why I wanted to stress that versioning won't magically solve it (just to be clear, I am not saying that that's what you said, but I felt like one general idea in this thread was that once you have versioning, you solve deployment issues). All I am saying is: - If you use a package without a strong API commitment, and if you use versioning to use it, you will make problems worse, not better. - If you use versioning for packages with strong API commitment, then it is definitely useful. cheers, David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simple idea to resolve versioning problems
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 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. Consequently, the developer will be unable to make it work on his own machine, and will therefore never attempt to deploy it! > It is ok to have a few > major, side by side versions for fundamental packages (on my ubuntu > system, I do have system installed qt 3 and qt 4, for example). This > would be good to have in python, I agree. That's what I'm talking about! As long as the API remains backward compatible, there is no need to have anything but the latest version installed -- and in fact, in the kind of system I have in mind, the earlier versions would *never be used* even if they were installed. That's because the program would say something like "Please give me gtk-2.3", and the system would know that anything called gtk-2.x with x >= 3 is compatible with that, and would pick the one with the greatest x out of those available. However, if a gtk-3.0 ever comes out, it implies that the API is *not* backward compatible. So then it makes sense to have both a gtk-2.x and a gtk-3.y installed, and the versioning system will keep them from getting confused. This relies on a couple of things: (a) library developers sticking rigidly to the version numbering semantics; (b) applications always requesting the version they actually require. > IOW, enabling version requirement without strong API compatibility is > the path to dependency hell. I fully agree. However, this is a social issue, not a technical one. Everyone using the versioning system would need to understand the rules and be willing to follow them. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simple idea to resolve versioning problems
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 with no form of reference counting. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simple idea to resolve versioning problems
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 experience with packaging on linux systems, but if it was allowed multiple versions of the same library (say gtk 2.4, gtk 2.6, etc...) with incompatible changes of API in between, it would be a nightmare. What will happen if multiple versions of the same package are allowed in python ? Everyone will start to say :I need version == N, and quickly, it will be unmanageable, because the above diamond diagram A <- (B <- D1, C <- D2) will happen all the time. You really need to be able to say I need version >= N, which means maintaining API. It is ok to have a few major, side by side versions for fundamental packages (on my ubuntu system, I do have system installed qt 3 and qt 4, for example). This would be good to have in python, I agree. So my point is that package versioning only work if you can depends on one version and all revision after, which means side by side installation of several minor revisions does not help. Having 2,3 major different versions of the same package is OK, if the package changes say every two years (like python). But it won't work if it changes every month (imagine what would happen if python 2.3.1 was not compatible with 2.3.2 ?) IOW, enabling version requirement without strong API compatibility is the path to dependency hell. If you enable side by side installation of many versions of the same package, you will make the problem worse, not better. If you need to use a package without strong API compatibility commitment, then the only real solution is to make your own copy. cheers, David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simple idea to resolve versioning problems
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 version of one package A, > and B another one? If they really do need different versions, this is insoluble. If they can actually use the same version because it's compatible enough, it may be necessary to make Python smart enough to notice that they're symlinks to the same file and only import it once. Or maybe something does need to be added to the language that understands version numbering, compatibility rules, etc. as I suggested in another post. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)
Paul Moore wrote: > Is there anything I can do to get it applied, or should I just leave > it now for someone to decide if they care enough? (As it's a library > change, I don't know to what extent the "no API changes after the next > alpha" rule will apply). I'm looking into it now - assuming it applies cleanly and the tests run happily afterwards (and I don't see any reason it won't after reading the patch), it should be checked in later tonight. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simple idea to resolve versioning problems
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, actually, which is not much better. As far as I understand, with .net, MS started to support multiple version (several runtimes could be installed at the same time), but it did not really solve the deployment issues. > > Seriously, the problems being discussed here seem very similar to > those encountered in the past by Windows with differing versions of > DLLs. A number of solutions have been tried, with varying degrees of > success. Anyone looking to address this problem for Python, really > should take a look at the DLL hell history in Windows, if only to see > what types of approach didn't work. One of the recent approach I am aware of is the GAC (global assembly cache) for .net support. It enable multiple versions of the same assembly (more or less equivalent to a python module) to be installed at the same time: http://www.mono-project.com/Assemblies_and_the_GAC This document is actually very interesting (I've just read it while looking for a link for the GAC). Although aimed at .net development, it is almost entirely applicable to the problems we are talking about here. Interestingly, it recommends against having multiple versions of the same assembly in the GAC without committment to stable API. cheers, David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)
On 19/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I'm currently working on an addition to pkgutil to provide this type > > of function. I'm considering going a little further (adding functions > > to get a file-like object, test for existence, and list available > > resources, modelled on the pkg_resources functions - but these extra > > ones are not supported by the loader protocol, so I'm undecided as to > > whether it's worth it, I'll see how complex the code gets). > > I'd only do what __loader__ offers. People can always wrap a StringIO around > it. > > > Once I have a patch, I'll post it to the tracker. What's the best > > approach? Code a patch for 3.0 and backport, or code for 2.6 and let > > the merging process do its stuff? > > Code for 2.6, let the merge do its thing. I've had a patch in http://bugs.python.org/issue2439 for a few weeks now. It just adds a get_data function, on the basis that that's all the loader API offers. I think it's complete - Phillip Eby helped thrash out a couple of problems. Is there anything I can do to get it applied, or should I just leave it now for someone to decide if they care enough? (As it's a library change, I don't know to what extent the "no API changes after the next alpha" rule will apply). Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simple idea to resolve versioning problems
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 earlier version, > even if the new API is backwards compatible. Is nobody but me seeing shades of Windows "DLL hell" in all of this? Seriously, the problems being discussed here seem very similar to those encountered in the past by Windows with differing versions of DLLs. A number of solutions have been tried, with varying degrees of success. Anyone looking to address this problem for Python, really should take a look at the DLL hell history in Windows, if only to see what types of approach didn't work. Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
