On 2007-05-21 16:05, Phillip J. Eby wrote:
> At 01:43 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
>> On 2007-05-21 00:07, Talin wrote:
>>> Phillip J. Eby wrote:
>>>> I wanted to get this in before the Py3K PEP deadline, since this is a
>>>> Python 2.6 PEP that would presumably impact 3.x as
>> well. Feedback welcome.
>>>>
>>>> PEP: 365
>>>> Title: Adding the pkg_resources module
>>> I'm really surprised that there hasn't been more comment on this.
>> True.... both ways, I guess: I'm still waiting for a reply to my
>> comments.
>
> What comments are you talking about? I must've missed them.
I've attached the email. Please see below.
>> I'd also like to see more discussion about adding e.g.:
>>
>> * support for user packages
>>
>> (ie. having site.py add a well-defined user home directory
>> based Python path entry to sys.path, e.g.
>> ~/.python/user-packages, much like what MacPython already does
>> now)
>>
>> * support for having the import mechanism play nice
>> with namespace packages
>>
>> (ie. packages that may live in different places on the disk,
>> but appear to be in the same Python package as seen by the
>> import mechanism)
>>
>> I think those two features would go a long way in reducing the
>> number of hacks setuptools currently applies to get this
>> functionality working with code in .pth files, monkey-patching
>> site.py, etc.
>
> These items aren't directly related to the PEP,
> however.
Right. I wasn't referring to this PEP. I think we should have
two more PEPs covering the above points, since they offer
benefits for all users, not just setuptools users.
> pkg_resources doesn't monkeypatch anything or touch any
> .pth files. It only changes sys.path at runtime if you explicitly
> ask it to locate and activate packages for you.
>
> As for namespace packages, pkg_resources provides a more PEP
> 302-compatible alternative to pkgutil.extend_path(). pkgutil doesn't
> support anything but existing filesystem directories, but the
> pkg_resources version supports zipfiles and has hooks to allow
> namespace package support to be registered for any PEP 302 importer. See:
>
> http://peak.telecommunity.com/DevCenter/PkgResources#supporting-custom-importers
>
> (specifically, the register_namespace_handler() function.)
Looking at the code it appears as if you've already formalized
an implementation for this.
However, since this is not egg-specific it should probably be
moved to pkgutil and get a separate PEP with detailed documentation
(the link you provided doesn't really explain the concepts, reading
the code helped a bit).
What I don't understand about your approach is why importers
would have to register with the namespace implementation.
This doesn't seem necessary, since the package __path__ attribute
already provides all functionality needed for redirecting
lookups to different paths.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, May 21 2007)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
--- Begin Message ---
On 2007-05-01 02:29, Phillip J. Eby wrote:
> I wanted to get this in before the Py3K PEP deadline, since this is a
> Python 2.6 PEP that would presumably impact 3.x as well. Feedback welcome.
Could you add a section that explains the side effects of
importing pkg_resources ?
The documentation of the module doesn't mention any, but the
code suggests that you are installing (some form of) import
hooks.
Some other comments:
* Wouldn't it be better to factor out all the meta-data access
code that's not related to eggs into pkgutil ?!
* How about then renaming the remaining module to egglib ?!
* The module needs some reorganization: imports, globals and constants
at the top, maybe a few comments delimiting the various sections,
* The get_*_platform() should probably use the platform module
which is a lot more flexible than distutils' get_platform()
(which should probably use the platform module as well in the
long run)
Thanks,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, May 04 2007)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
> PEP: 365
> Title: Adding the pkg_resources module
> Version: $Revision: 55032 $
> Last-Modified: $Date: 2007-04-30 20:24:48 -0400 (Mon, 30 Apr 2007) $
> Author: Phillip J. Eby <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 30-Apr-2007
> Post-History: 30-Apr-2007
>
>
> Abstract
> ========
>
> This PEP proposes adding an enhanced version of the ``pkg_resources``
> module to the standard library.
>
> ``pkg_resources`` is a module used to find and manage Python
> package/version dependencies and access bundled files and resources,
> including those inside of zipped ``.egg`` files. Currently,
> ``pkg_resources`` is only available through installing the entire
> ``setuptools`` distribution, but it does not depend on any other part
> of setuptools; in effect, it comprises the entire runtime support
> library for Python Eggs, and is independently useful.
>
> In addition, with one feature addition, this module could support
> easy bootstrap installation of several Python package management
> tools, including ``setuptools``, ``workingenv``, and ``zc.buildout``.
>
>
> Proposal
> ========
>
> Rather than proposing to include ``setuptools`` in the standard
> library, this PEP proposes only that ``pkg_resources`` be added to the
> standard library for Python 2.6 and 3.0. ``pkg_resources`` is
> considerably more stable than the rest of setuptools, with virtually
> no new features being added in the last 12 months.
>
> However, this PEP also proposes that a new feature be added to
> ``pkg_resources``, before being added to the stdlib. Specifically, it
> should be possible to do something like::
>
> python -m pkg_resources SomePackage==1.2
>
> to request downloading and installation of ``SomePackage`` from PyPI.
> This feature would *not* be a replacement for ``easy_install``;
> instead, it would rely on ``SomePackage`` having pure-Python ``.egg``
> files listed for download via the PyPI XML-RPC API, and the eggs would
> be placed in the ``$PYTHONEGGS`` cache, where they would **not** be
> importable by default. (And no scripts would be installed) However,
> if the download egg contains installation bootstrap code, it will be
> given a chance to run.
>
> These restrictions would allow the code to be extremely simple, yet
> still powerful enough to support users downloading package management
> tools such as ``setuptools``, ``workingenv`` and ``zc.buildout``,
> simply by supplying the tool's name on the command line.
>
>
> Rationale
> =========
>
> Many users have requested that ``setuptools`` be included in the
> standard library, to save users needing to go through the awkward
> process of bootstrapping it. However, most of the bootstrapping
> complexity comes from the fact that setuptools-installed code cannot
> use the ``pkg_resources`` runtime module unless setuptools is already
> installed. Thus, installing setuptools requires (in a sense) that
> setuptools already be installed.
>
> Other Python package management tools, such as ``workingenv`` and
> ``zc.buildout``, have similar bootstrapping issues, since they both
> make use of setuptools, but also want to provide users with something
> approaching a "one-step install". The complexity of creating bootstrap
> utilities for these and any other such tools that arise in future, is
> greatly reduced if ``pkg_resources`` is already present, and is also
> able to download pre-packaged eggs from PyPI.
>
> (It would also mean that setuptools would not need to be installed
> in order to simply *use* eggs, as opposed to building them.)
>
> Finally, in addition to providing access to eggs built via setuptools
> or other packaging tools, it should be noted that since Python 2.5,
> the distutils install package metadata (aka ``PKG-INFO``) files that
> can be read by ``pkg_resources`` to identify what distributions are
> already on ``sys.path``. In environments where Python packages are
> installed using system package tools (like RPM), the ``pkg_resources``
> module provides an API for detecting what versions of what packages
> are installed, even if those packages were installed via the distutils
> instead of setuptools.
>
>
> Implementation and Documentation
> ================================
>
> The ``pkg_resources`` implementation is maintained in the Python
> SVN repository under ``/sandbox/trunk/setuptools/``; see
> ``pkg_resources.py`` and ``pkg_resources.txt``. Documentation for the
> egg format(s) supported by ``pkg_resources`` can be found in
> ``doc/formats.txt``. HTML versions of these documents are available
> at:
>
> * http://peak.telecommunity.com/DevCenter/PkgResources and
>
> * http://peak.telecommunity.com/DevCenter/EggFormats
>
> (These HTML versions are for setuptools 0.6; they may not reflect all
> of the changes found in the Subversion trunk's ``.txt`` versions.)
>
>
> Copyright
> =========
>
> This document has been placed in the public domain.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mal%40egenix.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/mal%40egenix.com
--- End Message ---
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
