Commits

Daniel Holth committed ed0a197

virtualenv headers path, docs

Comments (0)

Files changed (4)

+0.13.0
+======
+- Use distutils instead of sysconfig to get installation paths; can install
+  headers.
+- Improve WheelFile() sort.
+- Allow bootstrap installs without any pkg_resources.
+
 0.12.0
 ======
 - Unit test for wheel.tool.install
 
 A built-package format for Python.
 
-A wheel is a ZIP-format archive with a specially formatted filename and
-the .whl extension. It is designed to contain all the files for a PEP 376
-compatible install in a way that is very close to the on-disk format. Many
-packages will be properly installed with only the "Unpack" step
-(simply extracting the file onto sys.path), and the unpacked archive
+A wheel is a ZIP-format archive with a specially formatted filename
+and the .whl extension. It is designed to contain all the files for a
+PEP 376 compatible install in a way that is very close to the on-disk
+format. Many packages will be properly installed with only the "Unpack"
+step (simply extracting the file onto sys.path), and the unpacked archive
 preserves enough information to "Spread" (copy data and scripts to their
 final locations) at any later time.
 
 The wheel project provides a `bdist_wheel` command for setuptools
 (requires distribute >= 0.6.28). Wheel files can be installed with a
-patched `pip` from https://github.com/dholth/pip.
+patched `pip`.
 
-*The pip patch is in flux and is being split into separate `install` and
-a `build` patches. Check the branch called `wheel` for the most features.*
+*The pip patch is in flux. See http://wheel.rtfd.org/ for the details.*
 
-The wheel documentation is at http://wheel.rtfd.org/. The file format is
-documented in the draft PEP 427 (http://www.python.org/dev/peps/pep-0427/).
+The wheel documentation is at http://wheel.rtfd.org/. The
+file format is documented in the draft PEP 427
+(http://www.python.org/dev/peps/pep-0427/).
 
 Why not egg?
 ------------
    You can adapt this file completely to your liking, but it should at least
    contain the root `toctree` directive.
 
-Wheel
-=====
-
-A built-package format for Python.
-
-A wheel is a ZIP-format archive with a specially formatted filename and
-the .whl extension. It is designed to contain all the files for a PEP 376
-compatible install in a way that is very close to the on-disk format. Many
-packages will be properly installed with only the “Unpack” step
-(simply extracting the file onto sys.path), and the unpacked archive
-preserves enough information to “Spread” (copy data and scripts to their
-final locations) at any later time.
-
-The wheel project provides a `bdist_wheel` command for setuptools
-(requires distribute >= 0.6.28). Wheel files can be installed with a
-patched `pip` from https://github.com/dholth/pip.
-
-Why not egg?
-------------
-
-Python's egg format predates the packaging related standards we have today,
-the most important being PEP 376 "Database of Installed Python Distributions"
-which specifies the .dist-info directory (instead of .egg-info) and PEP 345 
-"Metadata for Python Software Packages 1.2" which specifies how to express
-dependencies (instead of requires.txt in .egg-info).
-
-Wheel implements these things. It also provides a richer file naming
-convention that communicates the Python implementation and ABI as well as
-simply the language version used in a particular package.
-
-Unlike .egg, wheel will be a fully-documented standard at the binary level
-that is truly easy to install even if you do not want to use the reference
-implementation.
+.. include:: ../README.txt
 
 Usage
 -----
 and all its dependencies as wheels, and then installs pyramid from the
 built packages::
 
-        # Install pip, wheel
-        pip install git+https://github.com/dholth/pip#egg=pip wheel
+        # Install pip (the wheel_build branch)
+        pip install -e git+https://github.com/qwcode/pip@wheel_build#egg=pip
+        # Install wheel
+        pip install wheel
 
-        # Build a directory of wheels
-        mkdir /tmp/wheel-cache
-        pip install --wheel-cache=/tmp/wheel-cache --no-install pyramid
+        # Build a directory of wheels for pyramid and all its dependencies
+        pip install --wheel-dir=/tmp/wheelhouse pyramid
         
         # Install from cached wheels
-        pip install --use-wheel --no-index --find-links=file:///tmp/wheel-cache pyramid
-
-(Newer versions of the pip fork may use 'pip build' to produce wheels.)
+        pip install --use-wheel --no-index --find-links=/tmp/wheelhouse pyramid
 
 For lxml, an up to 3-minute "search for the newest version and compile"
 can become a less-than-1 second "unpack from wheel".
 
 Wheel's builtin utility can be invoked directly from wheel's own wheel::
 
-    $ python wheel-0.10.0-py2.py3-none-any.whl/wheel -h
+    $ python wheel-0.13.0-py2.py3-none-any.whl/wheel -h
     usage: wheel [-h] {keygen,sign,verify,unpack,install,convert,help} ...
 
     positional arguments:
 	    
 	$ export WHEEL_TOOL=/path/to/wheel	
 	$ python setup.py bdist_wheel
-	
-Signing is done in a subprocess because it is not convenient for 
-the build environment to contain bindings to the keyring and 
-cryptography libraries.
+
+Signing is done in a subprocess because it is not convenient for the
+build environment to contain bindings to the keyring and cryptography
+libraries. The keyring library may not be able to find your keys (choosing
+a different key storage back end based on available dependencies) unless
+you run it from the same environment used for keygen.
 
 A future version of `wheel sign` will be able to choose different signing
-keys depending on the package name, in case a user wishes to reserve a more
-widely trusted key for packages they intend to distribute.
+keys depending on the package name, in case a user wishes to reserve a
+more widely trusted key for packages they intend to distribute.
 
 Format
 ------
 Map the .data/ subdirectory names to install paths.
 """
 
-from distutils.command.install import install, SCHEME_KEYS
+import os.path
+import sys
+import distutils.dist as dist
+import distutils.command.install as install
 
 def get_install_paths(name):
     """
     Return the (distutils) install paths for the named dist.
     
     A dict with ('purelib', 'platlib', 'headers', 'scripts', 'data') keys.
-    """
-     # can't import up top due to monkeypatching
-    from distutils.dist import Distribution
+    """    
+    paths = {}
 
-    paths = {}
-    d = Distribution({'name':name})
-    i = install(d)
+    # late binding due to potential monkeypatching
+    d = dist.Distribution({'name':name})
+    i = install.install(d)
     i.finalize_options()
-    for key in SCHEME_KEYS:
+    for key in install.SCHEME_KEYS:
         paths[key] = getattr(i, 'install_'+key)
+        
+    # pip uses this path as an alternative to the system's (read-only) 
+    # include directory:
+    if hasattr(sys, 'real_prefix'): # virtualenv
+        paths['headers'] = os.path.join(sys.prefix, 
+                                        'include', 
+                                        'site', 
+                                        'python' + sys.version[:3])
+
     return paths
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.