Re: [Distutils] does easy_install.py need to guess the site-packages path?
At 09:54 PM 6/7/2011 -0700, James wrote: On Tue, Jun 7, 2011 at 6:30 PM, P.J. Eby mailto:p...@telecommunity.comp...@telecommunity.com wrote: At 12:00 AM 6/7/2011 -0700, James wrote: As an example I'm looking at setuptools-0.6c11-py2.7.egg, can someone tell me why setuptools/command/east_install.py in get_site_dirs() does its own computation of where site-packages is? As of 2.7 there are already 4 separate places in the python where this path is computed. Maybe I'm missing something but I don't see why an egg would have an opinion on this matter. It doesn't do that in order to know where to install things; it does it to know what places are *safe* to install things that need .pth support. I'm seeing it make up the path and then fail in a copytree since the computed dest directory in my case doesn't exist So I'm not exactly sure what you mean when you say it doesn't. Unless you override it, easy_install asks the distutils where to install things. So, the made up path you're referring to came from the distutils. (Which has yet *another* set of code to generate the path(s)!) If you set DISTUTILS_DEBUG=yes in your environment variables, and run the easy_install again, you'll see exactly where every setting comes from. The output of get_site_dirs() is *not* used to determine the installation path, only to *validate* it. (And unfortunately, there is no way to obtain this list from the site module directly.) I guess that is the nub, oh well. cheers, - James ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] DRAFT PEP 396 - module version number
Given Ben's and Fred's feedback, what do you think about this list in the Specification's section: #. In general, modules in the standard library SHOULD NOT have version numbers. They implicitly carry the version number of the Python release they are included in. #. On a case-by-case basis, standard library modules which are also released in standalone form for other Python versions MAY include a module version number when included in the standard library, and SHOULD include a version number when packaged separately. #. When a module (or package) includes a version number, the version SHOULD be available in the ``__version__`` attribute. #. For modules which live inside a namespace package, the sub-package name SHOULD include the ``__version__`` attribute. The namespace module itself SHOULD NOT include its own ``__version__`` attribute. #. The ``__version__`` attribute's value SHOULD be a string. #. Module version numbers SHOULD conform to the normalized version format specified in PEP 386 [6]_. #. Module version numbers SHOULD NOT contain version control system supplied revision numbers, or any other semantically different version numbers (e.g. underlying library version number). #. The ``version`` attribute in a classic distutils ``setup.py`` file, or the PEP 345 [7]_ ``Version`` metadata field SHOULD be derived from the ``__version__`` field, or vice versa. -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] DRAFT PEP 396 - module version number
Barry Warsaw ba...@python.org writes: #. The ``__version__`` attribute's value SHOULD be a string. I may be fighting against the tide here; but this screams to me that the PEP should not be talking at all about “version number” (except to point out that they're strings, not numbers). Instead, the term should be “version string” throughout. Much damage is done to understanding version strings by calling them “version numbers”, with all the baggage about parsing and sequencing etc. that entails. We don't have to make the same mistake in this PEP. -- \ “He may look like an idiot and talk like an idiot but don't let | `\ that fool you. He really is an idiot.” —Groucho Marx | _o__) | Ben Finney pgpzMM8LaKN5W.pgp Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] DRAFT PEP 396 - module version number
Barry Warsaw ba...@python.org writes: #. When a module (or package) includes a version number, the version SHOULD be available in the ``__version__`` attribute. #. For modules which live inside a namespace package, the sub-package name SHOULD include the ``__version__`` attribute. The namespace module itself SHOULD NOT include its own ``__version__`` attribute. I still find a little ambiguity in “the ``__version__`` attribute”, but it's much improved, thanks. I think those paragraphs are good. -- \ “It is clear that thought is not free if the profession of | `\ certain opinions makes it impossible to earn a living.” | _o__) —Bertrand Russell, _Free Thought and Official Propaganda_, 1928 | Ben Finney pgpluWOIsEqsP.pgp Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] DRAFT PEP 396 - module version number
On Wed, Jun 8, 2011 at 6:14 PM, Barry Warsaw ba...@python.org wrote: #. For modules which live inside a namespace package, the sub-package name SHOULD include the ``__version__`` attribute. The namespace module itself SHOULD NOT include its own ``__version__`` attribute. I've no idea what you're saying here. What's a sub-package? If you're referring to a package like zope.testing, I'd just call that a package; there's nothing special about that. I'd expect the __version__, if it exists, to be present in the file zope/testing/__init__.py. An namespace package, like zope or zc, should not have a __version__. Ben Finney wrote: I may be fighting against the tide here; but this screams to me that the PEP should not be talking at all about “version number” (except to point out that they're strings, not numbers). Instead, the term should be “version string” throughout. I'd rather we just say 'version' instead of 'version number' or 'version string'. Natural use of natural language is... natural. A separate sentence can state simply that versions are expressed as strings. -Fred -- Fred L. Drake, Jr. fdrake at acm.org Give me the luxuries of life and I will willingly do without the necessities. --Frank Lloyd Wright ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] DRAFT PEP 396 - module version number
Fred Drake fdr...@acm.org writes: On Wed, Jun 8, 2011 at 6:14 PM, Barry Warsaw ba...@python.org wrote: #. For modules which live inside a namespace package, the sub-package name SHOULD include the ``__version__`` attribute. The namespace module itself SHOULD NOT include its own ``__version__`` attribute. I've no idea what you're saying here. What's a sub-package? Moreover, how can a “sub-package name” include an attribute? I agree that needs to be clarified. If you're referring to a package like zope.testing, I'd just call that a package; there's nothing special about that. I'd expect the __version__, if it exists, to be present in the file zope/testing/__init__.py. Yes, but how to specify that? The ‘__init__.py’ file is a module. What's that, then; a package module? Ben Finney wrote: I may be fighting against the tide here; but this screams to me that the PEP should not be talking at all about “version number” (except to point out that they're strings, not numbers). Instead, the term should be “version string” throughout. I'd rather we just say 'version' instead of 'version number' or 'version string'. Natural use of natural language is... natural. A separate sentence can state simply that versions are expressed as strings. −1. A version is a state of the code base at a point in its development; what we're talking about here are strings which act as identifiers for versions of the code. I would argue for “version identifier”, but that has virtually no actual use :-) -- \ “I was sleeping the other night, alone, thanks to the | `\ exterminator.” —Emo Philips | _o__) | Ben Finney ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] DRAFT PEP 396 - module version number
I wrote: If you're referring to a package like zope.testing, I'd just call that a package; there's nothing special about that. I'd expect the __version__, if it exists, to be present in the file zope/testing/__init__.py. Ben Finney responded Yes, but how to specify that? The ‘__init__.py’ file is a module. What's that, then; a package module? The package zope.testing includes the module zope.testing (implemented in zope/testing/__init__.py), as well as other modules (zope.testing.cleanup for example). The zope.testing module SHOULD contain any appropriate __version__ attribute. The only real special cases are namespace packages like zc, zope, and many others. Since those are *not* tied to a single distribution, they SHOULD NOT have __version__ attributes. (I think we agree on this, but language is tedious, since there are many casual uses of the term 'package' here, and 'namespace packages' aren't as commonly known outside particular segments of the community.) -Fred -- Fred L. Drake, Jr. fdrake at acm.org Give me the luxuries of life and I will willingly do without the necessities. --Frank Lloyd Wright ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
