Guido van Rossum wrote:
> > > > This would be very cool. Rather than having to go by python
> > > > version numbers, which seem obscure, an application can declare its
> > > > dependencies by module. Perhaps even some tool to determine an apps
> > > > dependencies. These dependencies can then be checked using the
> > > > current version in a perl-esque regression test style to determine
> > > > how well the current version meets the applications needs (I say
> > > > this because some code may not be run normally but require more
> > > > advanced features - this could also allow for some very interesting
> > > > approaches to modularity and using available python features in larger
> > > > applications). It would then be very easy to determine the cause
> > > > of breakage and/or the need of the application.
> > >
> > > Hm, this sounds like overkill to me. And who's going to write the AI
> > > software to do this automatic regression testing?
> >
> > Perhaps it came across as more than it should be. I meant just specifying
> > the version numbers of the individual modules in a CPAN-like
> > dependency thing. Then, on start-up, the dependencies are just
> > checked. Mostly matching of version numbers. The stats are just a
> > fancy way of saying how screwed you are :)
>
> This has been proposed before, but I don't think anybody really
> understands how to do version dependencies correctly.
But i assume, you do agree that a *working* versioning and dependency scheme
for the standard-lib would be more than nice. (IMHO the more modules and
versions we have the more important it gets).
holger
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4