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" :)  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).
    
    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.
    
    
    
      The guidelines in 396 really only apply to distributed packages, so it doesn't make sense to obfuscate by catering to esoteric use cases. If prviate modules don't work with the standard tools, who is going to care? The module author clearly doesn't, and they aren't distributing it to anyone else. Once they *do* start distributing it, then their new users will help bring them into line. Having the recommended practice clearly documented just makes it easier for those users to point new module distributors in the right direction.     
    
    Oh, I fully agree that there be a PEP with guidelines, and yesterday     converted my private versioning system to conform with the names in     the PEP, and the style of version string in the referenced PEP.  And     I distribute my modules -- so far only in a private group, and so     far as straight .py files... no use of "packaging".  And even if I     never use "packaging", it seems like a good thing to conform to this     PEP, if I can.  Version checking is useful.
    
    
      (Also, tsk, tsk, Barry for including Standards track proposals in an Informational PEP!)">

(original) (raw)

On 4/6/2011 9:08 PM, Nick Coghlan wrote: 
On Thu, Apr 7, 2011 at 7:58 AM, Glenn Linderman <v+python@g.nevcal.com> wrote:  

Perhaps a different technique would be that if packaging is in use, that it  
could somehow inject the version from setup.cfg into the module, either by  
tweaking the source as it gets packaged, or installed, or tweaking the  
module as/after it gets loaded (the latter still required some runtime  
dependency on code from the packaging system).  A line like the following in  
some designated-to-"packaging" source file could be replaced during  
packaging:


__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" :)  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).



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.






The guidelines in 396 really only apply to distributed packages, so it
doesn't make sense to obfuscate by catering to esoteric use cases. If
prviate modules don't work with the standard tools, who is going to
care? The module author clearly doesn't, and they aren't distributing
it to anyone else. Once they *do* start distributing it, then their
new users will help bring them into line. Having the recommended
practice clearly documented just makes it easier for those users to
point new module distributors in the right direction.




Oh, I fully agree that there be a PEP with guidelines, and yesterday
converted my private versioning system to conform with the names in
the PEP, and the style of version string in the referenced PEP.  And
I distribute my modules -- so far only in a private group, and so
far as straight .py files... no use of "packaging".  And even if I
never use "packaging", it seems like a good thing to conform to this
PEP, if I can.  Version checking is useful.




(Also, tsk, tsk, Barry for including Standards track proposals in an
Informational PEP!)


Cheers,
Nick.


P.S. A nice coincidental progression: PEP 376, 386 and 396 are all
related to versioning and package metadata