"P.J. Eby" <p...@telecommunity.com> writes: > That depends on whether this PEP's version scheme is also going to be > embedded in the code implied by PEP 376. If so, then nobody will have > any reason to switch from using pkg_resources to the PEP 376 pkgutil > code, because they won't be able to manage their test, dev, and > collaboration environments that way.
What prevents them from doing so merely by choosing version strings that conform to the specification? > That's precisely it - there aren't any visible benefits to doing so, > but there *are* visible problems. I think a significant benefit will be that the version comparison semantics will be implemented *in Python*, and I know there are very many people who would like to drop a dependency on third-party tools. Alternatively, if this version string scheme is to be implemented in PEP 365, that has the same effect: it will be “part of Python”, which is a huge benefit compared to an implementation outside Python. > We need to have a way to translate existing version schemes to the new > one, if we're to be able to have a reasonable upgrade path -- This certainly deserves consideration. However, I remind readers that part of the problem we're trying to solve here is that version string schemes are *already* non-standard and inconsistent; we would have to choose only a sub-set of existing version schemes to be supported for upgrade. -- \ “In the long run, the utility of all non-Free software | `\ approaches zero. All non-Free software is a dead end.” —Mark | _o__) Pilgrim, 2006 | Ben Finney _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
