cleanup bin-script creation, fix docs, add FAQ entry about py.test --version
--HG-- branch : trunk
This commit is contained in:
		
							parent
							
								
									1580b2c8da
								
							
						
					
					
						commit
						8a5c3c0c69
					
				|  | @ -8,6 +8,9 @@ Changes between 1.1.2 and 1.1.1 | |||
| 
 | ||||
| - skip some install-tests if no execnet is available | ||||
| 
 | ||||
| - fix docs, fix internal bin/ script generation | ||||
| 
 | ||||
| 
 | ||||
| Changes between 1.1.1 and 1.1.0 | ||||
| ===================================== | ||||
| 
 | ||||
|  |  | |||
|  | @ -1,6 +1,6 @@ | |||
| from _findpy import py | ||||
| import py | ||||
| 
 | ||||
| bindir = py.magic.autopath().dirpath().dirpath("py").join("bin") | ||||
| bindir = py.path.local(__file__).dirpath().dirpath("bin") | ||||
| assert bindir.check(), bindir | ||||
| 
 | ||||
| def getbasename(name): | ||||
|  | @ -31,5 +31,3 @@ if __name__ == "__main__": | |||
|         if name[0] != "_": | ||||
|             genscript_unix(name) | ||||
|             genscript_windows(name) | ||||
|          | ||||
|          | ||||
|  |  | |||
|  | @ -1,7 +1,9 @@ | |||
| #!/usr/bin/env python  | ||||
| 
 | ||||
| # | ||||
| # find and import a version of 'py' | ||||
| # find and import a version of 'py' that exists in a parent dir | ||||
| # of the current working directory. fall back to import a  | ||||
| # globally available version | ||||
| # | ||||
| import sys | ||||
| import os | ||||
|  |  | |||
|  | @ -63,6 +63,15 @@ issues where people have used the term "magic" in the past: | |||
| .. _`py namespaces`: index.html | ||||
| .. _`py/__init__.py`: http://bitbucket.org/hpk42/py-trunk/src/trunk/py/__init__.py | ||||
| 
 | ||||
| Where does my ``py.test`` come/import from?  | ||||
| ---------------------------------------------- | ||||
| 
 | ||||
| You can issue:: | ||||
| 
 | ||||
|     py.test --version | ||||
| 
 | ||||
| which tells you both version and import location of the tool. | ||||
| 
 | ||||
| 
 | ||||
| function arguments, parametrized tests and setup | ||||
| ==================================================== | ||||
|  |  | |||
|  | @ -116,52 +116,47 @@ in order to work inline with the tools and the lib of your checkout. | |||
| 
 | ||||
| .. _`directly use a checkout`:  | ||||
| 
 | ||||
| directly use a checkout or tarball  | ||||
| directly use a checkout or tarball / avoid setuptools  | ||||
| ------------------------------------------------------------- | ||||
| 
 | ||||
| Once you got yourself a checkout_ or tarball_ it is usually a good  | ||||
| idea to add the parent directory of the ``py`` package directory  | ||||
| to your ``PYTHONPATH`` and ``py/bin`` or ``py\bin\win32`` to your  | ||||
| system wide ``PATH`` settings.  There are helper scripts that  | ||||
| set ``PYTHONPATH`` and ``PATH`` on your system:  | ||||
| Get a checkout_ or tarball_ and add paths to your environment variables: | ||||
| 
 | ||||
| on windows execute:: | ||||
| * ``PYTHONPATH`` needs to contain the root directory (where ``py`` resides) | ||||
| * ``PATH`` needs to contain ``ROOT/bin`` or ``ROOT\bin\win32`` respectively.  | ||||
| 
 | ||||
| There also are helper scripts that set the variables accordingly.  On windows  | ||||
| execute:: | ||||
| 
 | ||||
|     # inside autoexec.bat or shell startup | ||||
|     c:\\path\to\checkout\bin\env.cmd | ||||
| 
 | ||||
| on linux/OSX add this to your shell initialization::  | ||||
| 
 | ||||
|     # inside .bashrc  | ||||
|     # inside e.g. .bashrc  | ||||
|     eval `python ~/path/to/checkout/bin/env.py`  | ||||
| 
 | ||||
| both of which which will get you good settings  | ||||
| for ``PYTHONPATH`` and ``PATH``. | ||||
| both of which which will get you good settings.  If you install  | ||||
| the pylib this way you can easily ``hg pull && hg up`` or download | ||||
| a new tarball_ to follow the development tree. | ||||
| 
 | ||||
| If you install ``py.test`` this way you can easily | ||||
| ``hg pull && hg up`` your checkout to follow the | ||||
| development tree. | ||||
| 
 | ||||
| note: scripts look for "nearby" py-lib  | ||||
| ----------------------------------------------------- | ||||
| 
 | ||||
| Note that all `command line scripts`_ will look  | ||||
| for "nearby" py libs, so if you have a layout like this:: | ||||
| Note that the scripts manually added like this will look for  | ||||
| py libs in the chain of parent directories of the current working dir.   | ||||
| For example, if you have a layout like this:: | ||||
| 
 | ||||
|     mypkg/ | ||||
|         subpkg1/ | ||||
|             tests/ | ||||
|         tests/ | ||||
|     py/  | ||||
|     py/ | ||||
| 
 | ||||
| issuing ``py.test subpkg1`` will use the py lib | ||||
| from that projects root directory.   Giving the | ||||
| state of Python packaging there can be confusion | ||||
| in which case issuing:: | ||||
| from that projects root directory.   If in doubt over where | ||||
| the pylib comes from you can always do:: | ||||
| 
 | ||||
|     py.test --version | ||||
| 
 | ||||
| tells you both version and import location of the tool. | ||||
| to see where py.test is imported from.  | ||||
| 
 | ||||
| .. _`command line scripts`: bin.html | ||||
| .. _contact: contact.html | ||||
|  |  | |||
		Loading…
	
		Reference in New Issue