Hi, Le 06/04/2011 23:58, Glenn Linderman a écrit : > On 4/6/2011 7:26 AM, Nick Coghlan wrote: >> On Wed, Apr 6, 2011 at 6:22 AM, Glenn >> Linderman<v+python at g.nevcal.com> wrote: >>> With more standardization of versions, should the version module be >>> promoted >>> to stdlib directly? >> When Tarek lands "packaging" (i.e. what distutils2 becomes in the >> Python 3.3 stdlib), the standardised version handling will come with >> it. > > I thought that might be part of the answer :) But that, and below, > seem > to indicate that use of "packaging" suddenly becomes a requirement > for > all modules that want to include versions. The packaging of > "version" > inside a version of "packaging" implies more dependencies on a larger > body of code for a simple function. Not really. Some parts of distutils2/packaging are standalone modules that are deliberately exposed publicly for third parties to use: version, metadata, markers, etc. packaging.version is just the full name of the module implementing PEP 386. (The first implementation, called verlib, has not been explicitly ended, nor the references in the PEP updated.) > So, no support for single .py file modules, then? From packaging’s viewpoint, a project (something with a name and a version) is a directory with a setup.cfg file. The directory can contain zero or more Python modules, Python packages, extension modules or data files. > Caveat: I'm not 100% clear on when/how any of "distutils", > "setuptools", > or "packaging" are invoked FTR: setuptools is a monkey-patching set of extensions to distutils: packaging is a full replacement of distutils. packaging does not depend on distutils nor setuptools; it is a fork of distutils with some ideas and code taken from setuptools. Regards
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