Showing content from http://mail.python.org/pipermail/python-dev/attachments/20110407/781fc3bb/attachment.html below:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#330033" bgcolor="#ffffff">
On 4/6/2011 11:53 PM, Nick Coghlan wrote:
<blockquote
cite="mid:BANLkTimD06e01Rzsz_k=A39Ak=f8n-iKEA@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, Apr 7, 2011 at 2:55 PM, Glenn Linderman <a class="moz-txt-link-rfc2396E" href="mailto:v+python@g.nevcal.com"><v+python@g.nevcal.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">__version__ = "7.9.7xxxx" # replaced by "packaging"
If you don't upload your module to PyPI, then you can do whatever you
want with your versioning info. If you *do* upload it to PyPI, then
part of doing so properly is to package it so that your metadata is
where other utilities expect it to be. At that point, you can move the
version info over to setup.cfg and add the code into the module to
read it from the metadata store.
The PEP doesn't mention PyPI, and at present none of the modules there use
"packaging" :)
</pre>
</blockquote>
<pre wrap="">
They all use distutils (or setuptools or distutils2) though, which is
what packaging replaces.
(Sorry for not making that clear - it's easy to forget which aspects
of these issues aren't common knowledge as yet)
</pre>
</blockquote>
<br>
I knew that packaging replaced those others, but was unaware that
those were the only two methods used on PyPI. Not that I'd heard of
or experienced any others from that source, but there are many
packages there.<br>
<br>
<br>
<blockquote
cite="mid:BANLkTimD06e01Rzsz_k=A39Ak=f8n-iKEA@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">So it wasn't obvious to me that the PEP applies only to
PyPI, and I have used modules that were not available from PyPI yet were
still distributed and packaged somehow (not using "packaging" clearly).
</pre>
</blockquote>
<pre wrap="">
packaging is the successor to the current distutils package.
Distribution via PyPI is the main reason to bother with creating a
correctly structured package - for internal distribution, people use
all sorts of ad hoc schemes (often just the packaging systems of their
internal target platforms). I'll grant that some people do use
properly structured packages for purely internal use, but I'd also be
willing to bet that they're the exception rather than the rule.
What I would like to see the PEP say is that if you don't *have* a
setup.cfg file, then go ahead and embed the version directly in your
Python source file. If you *do* have one, then put the version there
and retrieve it with "pkgutil" if you want to provide a __version__
attribute.
Barry is welcome to make a feature request to allow that dependency to
go the other way, with the packaging system reading the version number
out of the source file, but such a suggestion doesn't belong in an
Informational PEP. If such a feature is ever accepted, then the
recommendation in the PEP could be updated.
</pre>
<blockquote type="cite">
<pre wrap="">While there has been much effort (discussion by many) to make "packaging"
useful to many, and that is probably a good thing, I still wonder why a
packaging system should be loaded into applications when all the code has
already been installed. Or is the runtime of "packaging" packaged so that
only a small amount of code has to be loaded to obtain "version" and
"__version__"? I don't recall that being discussed on this list, but maybe
it has been on more focused lists, sorry for my ignorance... but I also read
about embedded people complaining about how many files Python opens at start
up, and see no need for a full packaging system to be loaded, just to do
version checking.
</pre>
</blockquote>
<pre wrap="">
pkgutil will be able to read the metadata - it is a top level standard
library module, *not* a submodule of distutils/packaging.
It may make sense for the version parsing support to be in pkgutil as
well, since PEP 345 calls for it to be stored as a string in the
package metadata, but it needs to be converted with NormalizedVersion
to be safe to use in arbitrary version range checks. That's Tarek's
call as to whether to provide it that way, or as a submodule of
packaging. As you say, the fact that distutils/packaging are usually
first on the chopping block when distros are looking to save space is
a strong point in favour of having that particular functionality
somewhere else.
</pre>
</blockquote>
<br>
This sounds more practical; if I recall prior discussions correctly,
pkgutil reads a standard set of metadata data packaging systems
should provide, and version would seem to be part of that, more so
than of packaging itself... seems things would have a better
(smaller at runtime) dependency tree that way, from what I
understand about it.<br>
<br>
<blockquote
cite="mid:BANLkTimD06e01Rzsz_k=A39Ak=f8n-iKEA@mail.gmail.com"
type="cite">
<pre wrap="">That said, I've seen people have problems because a Python 2.6
redistributor decided "contextlib" wasn't important and left it out,
so YMMV regardless of where the code ends up.
</pre>
</blockquote>
<br>
:)<br>
<br>
<blockquote
cite="mid:BANLkTimD06e01Rzsz_k=A39Ak=f8n-iKEA@mail.gmail.com"
type="cite">
<pre wrap="">Cheers,
Nick</pre>
</blockquote>
<br>
Thanks Nick, for the info in this thread. This is mostly a thank
you note for helping me understand better.<br>
</body>
</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