On 07/04/2011 12:10, Michael Foord wrote:
> On 06/04/2011 15:26, 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.
>>
>>> On 4/5/2011 11:52 AM, Barry Warsaw wrote:
>>>
>>> DEFAULT_VERSION_RE = re.compile(r'(?P<version>\d+\.\d(?:\.\d+)?)')
>>>
>>> __version__ = pkgutil.get_distribution('elle').metadata['version']
>>>
>
> I really dislike this way of specifying the version. For a start it is
> really ugly.
>
> More importantly it means the version information is *only* available
> if the package has been installed by "packaging", and so isn't
> available for the parts of my pre-build process like building the
> documentation (which import the version number to put into the docs).
>
And in fact it would make the module itself unimportable unless
installed by "packaging", so not compatible with other installation
methods (including the ever-loved 'just drop it somewhere on sys.path)
or earlier versions of Python that don't have the required apis (or
don't have packaging installed).
So I don't think recommending
"pkgutil.get_distribution('elle').metadata['version']" as a way for
packages to provide version information is good advice.
All the best,
Michael Foord
> Currently all my packages have the canonical version number
> information in the package itself using:
>
> __version__ = '1.2.3'
>
> Anything that needs the version number, including setup.py for upload
> to pypi, has one place to look for it and it doesn't depend on any
> other tools or processes. If switching to "packaging" prevents me from
> doing this then it will inhibit me using "packaging".
>
> What I may have to do is use a python script that will generate the
> static metadata, which is not such a bad thing I guess as it will only
> need to be executed at package build time. I won't be switching to
> that horrible technique for specifying versions within my packages
> though.
>
> All the best,
>
> Michael
>>> The RE as given won't match alpha, beta, rc, dev, and post suffixes
>>> that are
>>> discussed in POP 386.
>> Indeed, I really don't like the RE suggestion - better to tell people
>> to just move the version info into the static config file and use
>> pkgutil to make it available as shown. That solves the build time vs
>> install time problem as well.
>>
>>> Nor will it match the code shown and quoted for the alternative
>>> distutils2
>>> case.
>>>
>>>
>>> Other comments:
>>>
>>> Are there issues for finding and loading multiple versions of the same
>>> module?
>> No, you simply can't do it. Python's import semantics are already
>> overly complicated even without opening that particular can of worms.
>>
>>> Should it be possible to determine a version before loading a
>>> module? If
>>> yes, the version module would have to be able to find a parse version
>>> strings in any of the many places this PEP suggests they could be...
>>> so that
>>> would be somewhat complex, but the complexity shouldn't be used to
>>> change
>>> the answer... but if the answer is yes, it might encourage fewer
>>> variant
>>> cases to be supported for acceptable version definition locations
>>> for this
>>> PEP.
>> Yep, this is why the version information should be in the setup.cfg
>> file, and hence available via pkgutil without loading the module
>> first.
>>
>> Cheers,
>> Nick.
>>
>
>
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
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