diff options
Diffstat (limited to 'assets/info/setuptools.info')
| -rw-r--r-- | assets/info/setuptools.info | 26390 |
1 files changed, 26390 insertions, 0 deletions
diff --git a/assets/info/setuptools.info b/assets/info/setuptools.info new file mode 100644 index 00000000..48a55082 --- /dev/null +++ b/assets/info/setuptools.info @@ -0,0 +1,26390 @@ +This is setuptools.info, produced by makeinfo version 6.5 from +setuptools.texi. + + setuptools 50.3.2, Dec 04, 2020 + + Python Packaging Authority + + Copyright © Python Packaging Authority + +INFO-DIR-SECTION Miscellaneous +START-INFO-DIR-ENTRY +* setuptools: (setuptools.info). One line description of project +END-INFO-DIR-ENTRY + + + Generated by Sphinx 2.3.1. + + +File: setuptools.info, Node: Top, Next: Building and Distributing Packages with Setuptools, Up: (dir) + +setuptools +********** + + setuptools 50.3.2, Dec 04, 2020 + + Python Packaging Authority + + Copyright © Python Packaging Authority + +Setuptools is a fully-featured, actively-maintained, and stable library +designed to facilitate packaging Python projects. + +Documentation content: + +* Menu: + +* Building and Distributing Packages with Setuptools:: +* Build System Support:: +* Package Discovery and Resource Access using pkg_resources:: +* Keywords:: +* Roadmap:: +* Building and Distributing Packages with Setuptools: Building and Distributing Packages with Setuptools<2>. +* Development on Setuptools:: +* Guides on backward compatibility & deprecated practice:: +* History: History<2>. +* Credits:: +* Index:: + + — The Detailed Node Listing — + +Building and Distributing Packages with Setuptools + +* Transition to PEP517:: + +Transition to PEP517 + +* setuptools Quickstart:: +* Package Discovery and Namespace Package:: +* Entry Points:: +* Dependencies Management in Setuptools:: +* Data Files Support:: +* “Development Mode”:: +* Tagging and “Daily Build” or “Snapshot” Releases:: +* Generating Source Distributions:: +* Distributing Extensions compiled with Cython:: +* Specifying Your Project’s Version:: +* Creating distutils Extensions:: +* Configuring setup() using setup.cfg files: Configuring setup using setup cfg files. +* New and Changed setup() Keywords: New and Changed setup Keywords. +* Command Reference:: +* Using setuptools to package and distribute your project:: +* Automatic Resource Extraction:: +* Defining Additional Metadata:: +* Setting the zip_safe flag:: + +setuptools Quickstart + +* Installation:: +* Python packaging at a glance:: +* Basic Use:: +* Automatic package discovery:: +* Entry points and automatic script creation:: +* Dependency management:: +* Including Data Files:: +* Development mode:: +* Uploading your package to PyPI:: +* Transitioning from setup.py to setup.cfg: Transitioning from setup py to setup cfg. +* Resources on Python packaging:: + +Package Discovery and Namespace Package + +* Using find; or find_packages: Using find or find_packages. +* Using find_namespace; or find_namespace_packages: Using find_namespace or find_namespace_packages. +* Legacy Namespace Packages:: + +Legacy Namespace Packages + +* pkg_resource style namespace package:: +* pkgutil style namespace package:: + +Entry Points + +* Console Scripts:: +* Advertising Behavior:: +* Dependency Management:: + +Dependencies Management in Setuptools + +* Build system requirement:: +* Declaring required dependency:: +* Optional dependencies:: +* Python requirement:: + +Build system requirement + +* Package requirement:: + +Declaring required dependency + +* Platform specific dependencies:: +* Dependencies that aren’t in PyPI:: + +Data Files Support + +* Accessing Data Files at Runtime:: +* Non-Package Data Files:: + +Generating Source Distributions + +* Making “Official” (Non-Snapshot) Releases: Making “Official” Non-Snapshot Releases. + +Creating distutils Extensions + +* Adding Commands:: +* Adding setup() Arguments: Adding setup Arguments. +* Customizing Distribution Options:: +* Adding new EGG-INFO Files:: +* Adding Support for Revision Control Systems:: + +Configuring setup() using setup.cfg files + +* Using a src/ layout:: +* Specifying values:: + +Specifying values + +* Metadata:: +* Options:: + +Command Reference + +* alias - Define shortcuts for commonly used commands:: +* bdist_egg - Create a Python Egg for the project:: +* develop - Deploy the project source in “Development Mode”:: +* egg_info - Create egg metadata and set build tags:: +* rotate - Delete outdated distribution files:: +* saveopts - Save used options to a configuration file:: +* setopt - Set a distutils or setuptools option in a config file:: +* test - Build package and run a unittest suite:: +* upload - Upload source and/or egg distributions to PyPI:: + +egg_info - Create egg metadata and set build tags + +* Release Tagging Options:: +* Other egg_info Options:: +* egg_info Examples:: + +saveopts - Save used options to a configuration file + +* Configuration File Options:: + +Build System Support + +* What is it?:: +* How to use it?:: + +Package Discovery and Resource Access using pkg_resources + +* Overview:: +* API Reference:: + +API Reference + +* Namespace Package Support:: +* WorkingSet Objects:: +* Environment Objects:: +* Requirement Objects:: +* Entry Points: Entry Points<2>. +* Distribution Objects:: +* ResourceManager API:: +* Metadata API:: +* Exceptions:: +* Supporting Custom Importers:: +* Utility Functions:: + +WorkingSet Objects + +* Basic WorkingSet Methods:: +* WorkingSet Methods and Attributes:: +* Receiving Change Notifications:: +* Locating Plugins:: + +Requirement Objects + +* Requirements Parsing:: +* Requirement Methods and Attributes:: + +Entry Points + +* Convenience API:: +* Creating and Parsing:: +* EntryPoint Objects:: + +Distribution Objects + +* Getting or Creating Distributions:: +* Distribution Attributes:: +* Distribution Methods:: + +ResourceManager API + +* Basic Resource Access:: +* Resource Extraction:: +* “Provider” Interface:: + +Metadata API + +* IMetadataProvider Methods:: + +Supporting Custom Importers + +* IResourceProvider:: +* Built-in Resource Providers:: + +Utility Functions + +* Parsing Utilities:: +* Platform Utilities:: +* PEP 302 Utilities:: +* File/Path Utilities:: +* History:: + +Building and Distributing Packages with Setuptools + +* Developer’s Guide:: + +Developer’s Guide + +* TRANSITIONAL NOTE:: + +TRANSITIONAL NOTE + +* setup.cfg-only projects: setup cfg-only projects. +* Configuration API:: +* Mailing List and Bug Tracker:: + +Development on Setuptools + +* Developer’s Guide for Setuptools:: +* Release Process:: + +Developer’s Guide for Setuptools + +* Recommended Reading:: +* Project Management:: +* Authoring Tickets:: +* Making a pull request:: +* Auto-Merge Requests:: +* Testing:: +* Semantic Versioning:: +* Building Documentation:: +* Vendored Dependencies:: + +Making a pull request + +* Adding change notes with your PRs:: +* Alright! So how to add a news fragment?:: +* Examples for adding changelog entries to your Pull Requests:: + +Release Process + +* Release Frequency:: +* Release Managers:: + +Guides on backward compatibility & deprecated practice + +* Supporting both Python 2 and Python 3 with Setuptools:: +* The Internal Structure of Python Eggs:: +* Easy Install:: +* Porting from Distutils:: +* “Eggsecutable” Scripts:: + +Supporting both Python 2 and Python 3 with Setuptools + +* Using 2to3:: +* Distributing Python 3 modules:: +* Advanced features:: + +Using 2to3 + +* Differential conversion:: + +The Internal Structure of Python Eggs + +* Eggs and their Formats:: +* Standard Metadata:: +* Other Technical Considerations:: + +Eggs and their Formats + +* Code and Resources:: +* Project Metadata:: +* Filename-Embedded Metadata:: +* Egg Links:: + +Standard Metadata + +* .txt File Formats: txt File Formats. +* Dependency Metadata:: +* namespace_packages.txt – Namespace Package Metadata: namespace_packages txt – Namespace Package Metadata. +* entry_points.txt – “Entry Point”/Plugin Metadata: entry_points txt – “Entry Point”/Plugin Metadata. +* The scripts Subdirectory:: +* Zip Support Metadata:: +* top_level.txt – Conflict Management Metadata: top_level txt – Conflict Management Metadata. +* SOURCES.txt – Source Files Manifest: SOURCES txt – Source Files Manifest. + +Dependency Metadata + +* requires.txt: requires txt. +* setup_requires.txt: setup_requires txt. +* dependency_links.txt: dependency_links txt. +* depends.txt – Obsolete, do not create!: depends txt – Obsolete do not create!. + +Zip Support Metadata + +* native_libs.txt: native_libs txt. +* eager_resources.txt: eager_resources txt. +* zip-safe and not-zip-safe:: + +Other Technical Considerations + +* Zip File Issues:: +* Installation and Path Management Issues:: + +Zip File Issues + +* The Extraction Process:: +* Extension Import Wrappers:: + +Installation and Path Management Issues + +* Script Wrappers:: + +Easy Install + +* Using “Easy Install”:: +* Reference Manual:: + +Using “Easy Install” + +* Installing “Easy Install”:: +* Downloading and Installing a Package:: +* Upgrading a Package:: +* Changing the Active Version:: +* Uninstalling Packages:: +* Managing Scripts:: +* Executables and Launchers:: +* Tips & Techniques:: +* Password-Protected Sites:: +* Using .pypirc Credentials: Using pypirc Credentials. + +Installing “Easy Install” + +* Troubleshooting:: +* Windows Notes:: + +Executables and Launchers + +* Windows Executable Launcher:: +* Natural Script Launcher:: + +Tips & Techniques + +* Multiple Python Versions:: +* Restricting Downloads with --allow-hosts:: +* Installing on Un-networked Machines:: +* Packaging Others’ Projects As Eggs:: +* Creating your own Package Index:: + +Using .pypirc Credentials + +* Controlling Build Options:: +* Editing and Viewing Source Packages:: +* Dealing with Installation Conflicts:: +* Compressed Installation:: + +Reference Manual + +* Configuration Files:: +* Command-Line Options:: +* Custom Installation Locations:: +* Package Index “API”:: + +Custom Installation Locations + +* Use the “–user” option:: +* Use the “–user” option and customize “PYTHONUSERBASE”:: +* Use “virtualenv”:: + +Porting from Distutils + +* Prefer Setuptools:: + +History + +* v50.3.2: v50 3 2. +* v50.3.1: v50 3 1. +* v50.3.0: v50 3 0. +* v50.2.0: v50 2 0. +* v50.1.0: v50 1 0. +* v50.0.3: v50 0 3. +* v50.0.2: v50 0 2. +* v50.0.1: v50 0 1. +* v50.0.0: v50 0 0. +* v49.6.0: v49 6 0. +* v49.5.0: v49 5 0. +* v49.4.0: v49 4 0. +* v49.3.2: v49 3 2. +* v49.3.1: v49 3 1. +* v49.3.0: v49 3 0. +* v49.2.1: v49 2 1. +* v49.2.0: v49 2 0. +* v49.1.3: v49 1 3. +* v49.1.2: v49 1 2. +* v49.1.1: v49 1 1. +* v49.0.1: v49 0 1. +* v49.1.0: v49 1 0. +* v49.0.0: v49 0 0. +* v48.0.0: v48 0 0. +* v47.3.2: v47 3 2. +* v47.3.1: v47 3 1. +* v47.3.0: v47 3 0. +* v47.2.0: v47 2 0. +* v47.1.1: v47 1 1. +* v44.1.1: v44 1 1. +* v47.1.0: v47 1 0. +* v47.0.0: v47 0 0. +* v46.4.0: v46 4 0. +* v46.3.1: v46 3 1. +* v46.3.0: v46 3 0. +* v46.2.0: v46 2 0. +* v46.1.3: v46 1 3. +* v46.1.2: v46 1 2. +* v46.1.1: v46 1 1. +* v46.1.0: v46 1 0. +* v44.1.0: v44 1 0. +* v46.0.0: v46 0 0. +* v45.3.0: v45 3 0. +* v45.2.0: v45 2 0. +* v45.1.0: v45 1 0. +* v45.0.0: v45 0 0. +* v44.0.0: v44 0 0. +* v43.0.0: v43 0 0. +* v42.0.2: v42 0 2. +* v42.0.1: v42 0 1. +* v42.0.0: v42 0 0. +* v41.6.0: v41 6 0. +* v41.5.1: v41 5 1. +* v41.5.0: v41 5 0. +* v41.4.0: v41 4 0. +* v41.3.0: v41 3 0. +* v41.2.0: v41 2 0. +* v41.1.0: v41 1 0. +* v41.0.1: v41 0 1. +* v41.0.0: v41 0 0. +* v40.9.0: v40 9 0. +* v40.8.0: v40 8 0. +* v40.7.3: v40 7 3. +* v40.7.2: v40 7 2. +* v40.7.1: v40 7 1. +* v40.7.0: v40 7 0. +* v40.6.3: v40 6 3. +* v40.6.2: v40 6 2. +* v40.6.1: v40 6 1. +* v40.6.0: v40 6 0. +* v40.5.0: v40 5 0. +* v40.4.3: v40 4 3. +* v40.4.2: v40 4 2. +* v40.4.1: v40 4 1. +* v40.4.0: v40 4 0. +* v40.3.0: v40 3 0. +* v40.2.0: v40 2 0. +* v40.1.1: v40 1 1. +* v40.1.0: v40 1 0. +* v40.0.0: v40 0 0. +* v39.2.0: v39 2 0. +* v39.1.0: v39 1 0. +* v39.0.1: v39 0 1. +* v39.0.0: v39 0 0. +* v38.7.0: v38 7 0. +* v38.6.1: v38 6 1. +* v38.6.0: v38 6 0. +* v38.5.2: v38 5 2. +* v38.5.1: v38 5 1. +* v38.5.0: v38 5 0. +* v38.4.1: v38 4 1. +* v38.4.0: v38 4 0. +* v38.3.0: v38 3 0. +* v38.2.5: v38 2 5. +* v38.2.4: v38 2 4. +* v38.2.3: v38 2 3. +* v38.2.2: v38 2 2. +* v38.2.1: v38 2 1. +* v38.2.0: v38 2 0. +* v38.1.0: v38 1 0. +* v38.0.0: v38 0 0. +* v37.0.0: v37 0 0. +* v36.8.0: v36 8 0. +* v36.7.3: v36 7 3. +* v36.7.2: v36 7 2. +* v36.7.1: v36 7 1. +* v36.7.0: v36 7 0. +* v36.6.1: v36 6 1. +* v36.6.0: v36 6 0. +* v36.5.0: v36 5 0. +* v36.4.0: v36 4 0. +* v36.3.0: v36 3 0. +* v36.2.7: v36 2 7. +* v36.2.6: v36 2 6. +* v36.2.5: v36 2 5. +* v36.2.4: v36 2 4. +* v36.2.3: v36 2 3. +* v36.2.2: v36 2 2. +* v36.2.1: v36 2 1. +* v36.2.0: v36 2 0. +* v36.1.1: v36 1 1. +* v36.1.0: v36 1 0. +* v36.0.1: v36 0 1. +* v36.0.0: v36 0 0. +* v35.0.2: v35 0 2. +* v35.0.1: v35 0 1. +* v35.0.0: v35 0 0. +* v34.4.1: v34 4 1. +* v34.4.0: v34 4 0. +* v34.3.3: v34 3 3. +* v34.3.2: v34 3 2. +* v34.3.1: v34 3 1. +* v34.3.0: v34 3 0. +* v34.2.0: v34 2 0. +* v34.1.1: v34 1 1. +* v34.1.0: v34 1 0. +* v34.0.3: v34 0 3. +* v34.0.2: v34 0 2. +* v34.0.1: v34 0 1. +* v34.0.0: v34 0 0. +* v33.1.1: v33 1 1. +* v33.1.0: v33 1 0. +* v33.0.0: v33 0 0. +* v32.3.1: v32 3 1. +* v32.3.0: v32 3 0. +* v32.2.0: v32 2 0. +* v32.1.3: v32 1 3. +* v32.1.2: v32 1 2. +* v32.1.1: v32 1 1. +* v32.1.0: v32 1 0. +* v32.0.0: v32 0 0. +* v31.0.1: v31 0 1. +* v31.0.0: v31 0 0. +* v30.4.0: v30 4 0. +* v30.3.0: v30 3 0. +* v30.2.1: v30 2 1. +* v30.2.0: v30 2 0. +* v30.1.0: v30 1 0. +* v30.0.0: v30 0 0. +* v29.0.1: v29 0 1. +* v29.0.0: v29 0 0. +* v28.8.0: v28 8 0. +* v28.7.1: v28 7 1. +* v28.7.0: v28 7 0. +* v28.6.1: v28 6 1. +* v28.6.0: v28 6 0. +* v28.5.0: v28 5 0. +* v28.4.0: v28 4 0. +* v28.3.0: v28 3 0. +* v28.1.0: v28 1 0. +* v28.0.0: v28 0 0. +* v27.3.1: v27 3 1. +* v27.3.0: v27 3 0. +* v27.2.0: v27 2 0. +* v27.1.2: v27 1 2. +* v27.1.1: v27 1 1. +* v27.1.0: v27 1 0. +* v27.0.0: v27 0 0. +* v26.1.1: v26 1 1. +* v26.1.0: v26 1 0. +* v26.0.0: v26 0 0. +* v25.4.0: v25 4 0. +* v25.3.0: v25 3 0. +* v25.2.0: v25 2 0. +* v25.1.6: v25 1 6. +* v25.1.5: v25 1 5. +* v25.1.4: v25 1 4. +* v25.1.3: v25 1 3. +* v25.1.2: v25 1 2. +* v25.1.1: v25 1 1. +* v25.1.0: v25 1 0. +* v25.0.2: v25 0 2. +* v25.0.1: v25 0 1. +* v25.0.0: v25 0 0. +* v24.3.1: v24 3 1. +* v24.3.0: v24 3 0. +* v24.2.1: v24 2 1. +* v24.2.0: v24 2 0. +* v24.1.1: v24 1 1. +* v24.1.0: v24 1 0. +* v24.0.3: v24 0 3. +* v24.0.2: v24 0 2. +* v24.0.1: v24 0 1. +* v24.0.0: v24 0 0. +* v23.2.1: v23 2 1. +* v23.1.0: v23 1 0. +* v23.0.0: v23 0 0. +* v22.0.5: v22 0 5. +* v22.0.4: v22 0 4. +* v22.0.3: v22 0 3. +* v22.0.2: v22 0 2. +* v22.0.1: v22 0 1. +* v22.0.0: v22 0 0. +* v21.2.2: v21 2 2. +* v21.2.1: v21 2 1. +* v21.2.0: v21 2 0. +* v21.1.0: v21 1 0. +* v21.0.0: v21 0 0. +* v20.10.0: v20 10 0. +* v20.9.0: v20 9 0. +* v20.8.1: v20 8 1. +* v20.8.0: v20 8 0. +* v20.7.0: v20 7 0. +* v20.6.8: v20 6 8. +* v20.6.7: v20 6 7. +* v20.6.6: v20 6 6. +* v20.6.0: v20 6 0. +* 20.5: 20 5. +* 20.4: 20 4. +* 20.3.1: 20 3 1. +* 20.3: 20 3. +* 20.2.2: 20 2 2. +* 20.2.1: 20 2 1. +* 20.2: 20 2. +* 20.1.1: 20 1 1. +* 20.1: 20 1. +* 20.0: 20 0. +* 19.7: 19 7. +* 19.6.2: 19 6 2. +* 19.6.1: 19 6 1. +* 19.6: 19 6. +* 19.5: 19 5. +* 19.4.1: 19 4 1. +* 19.4: 19 4. +* 19.3: 19 3. +* 19.2: 19 2. +* 19.1.1: 19 1 1. +* 19.1: 19 1. +* 19.0: 19 0. +* 18.8.1: 18 8 1. +* 18.8: 18 8. +* 18.7.1: 18 7 1. +* 18.7: 18 7. +* 18.6.1: 18 6 1. +* 18.6: 18 6. +* 18.5: 18 5. +* 18.4: 18 4. +* 18.3.2: 18 3 2. +* 18.3.1: 18 3 1. +* 18.3: 18 3. +* 18.2: 18 2. +* 18.1: 18 1. +* 18.0.1: 18 0 1. +* 18.0: 18 0. +* 17.1.1: 17 1 1. +* 17.1: 17 1. +* 17.0: 17 0. +* 16.0: 16 0. +* 15.2: 15 2. +* 15.1: 15 1. +* 15.0: 15 0. +* 14.3.1: 14 3 1. +* 14.3: 14 3. +* 14.2: 14 2. +* 14.1.1: 14 1 1. +* 14.1: 14 1. +* 14.0: 14 0. +* 13.0.2: 13 0 2. +* 13.0.1: 13 0 1. +* 13.0: 13 0. +* 12.4: 12 4. +* 12.3: 12 3. +* 12.2: 12 2. +* 12.1: 12 1. +* 12.0.5: 12 0 5. +* 12.0.4: 12 0 4. +* 12.0.3: 12 0 3. +* 12.0.2: 12 0 2. +* 12.0.1: 12 0 1. +* 12.0: 12 0. +* 11.3.1: 11 3 1. +* 11.3: 11 3. +* 11.2: 11 2. +* 11.1: 11 1. +* 11.0: 11 0. +* 10.2.1: 10 2 1. +* 10.2: 10 2. +* 10.1: 10 1. +* 10.0.1: 10 0 1. +* 10.0: 10 0. +* 9.1: 9 1. +* 9.0.1: 9 0 1. +* 9.0: 9 0. +* 8.4: 8 4. +* 8.3: 8 3. +* 8.2.1: 8 2 1. +* 8.2: 8 2. +* 8.1: 8 1. +* 8.0.4: 8 0 4. +* 8.0.3: 8 0 3. +* 8.0.2: 8 0 2. +* 8.0.1: 8 0 1. +* 8.0: 8 0. +* 7.0: 7 0. +* 6.1: 6 1. +* 6.0.2: 6 0 2. +* 6.0.1: 6 0 1. +* 6.0: 6 0. +* 5.8: 5 8. +* 5.7: 5 7. +* 5.6: 5 6. +* 5.5.1: 5 5 1. +* 5.5: 5 5. +* 5.4.2: 5 4 2. +* 5.4.1: 5 4 1. +* 5.4: 5 4. +* 5.3: 5 3. +* 5.2: 5 2. +* 5.1: 5 1. +* 5.0.2: 5 0 2. +* 5.0.1: 5 0 1. +* 5.0: 5 0. +* 3.7.1 and 3.8.1 and 4.0.1: 3 7 1 and 3 8 1 and 4 0 1. +* 4.0: 4 0. +* 3.8: 3 8. +* 3.7: 3 7. +* 3.6: 3 6. +* 3.5.2: 3 5 2. +* 3.5.1: 3 5 1. +* 3.5: 3 5. +* 3.4.4: 3 4 4. +* 3.4.3: 3 4 3. +* 3.4.2: 3 4 2. +* 3.4.1: 3 4 1. +* 3.4: 3 4. +* 3.3: 3 3. +* 3.2: 3 2. +* 3.1: 3 1. +* 3.0.2: 3 0 2. +* 3.0.1: 3 0 1. +* 3.0: 3 0. +* 2.2: 2 2. +* 2.1.2: 2 1 2. +* 2.1.1: 2 1 1. +* 2.1: 2 1. +* 2.0.2: 2 0 2. +* 2.0.1: 2 0 1. +* 2.0: 2 0. +* 1.4.2: 1 4 2. +* 1.4.1: 1 4 1. +* 1.4: 1 4. +* 1.3.2: 1 3 2. +* 1.3.1: 1 3 1. +* 1.3: 1 3. +* 1.2: 1 2. +* 1.1.7: 1 1 7. +* 1.1.6: 1 1 6. +* 1.1.5: 1 1 5. +* 1.1.4: 1 1 4. +* 1.1.3: 1 1 3. +* 1.1.2: 1 1 2. +* 1.1.1: 1 1 1. +* 1.1: 1 1. +* 1.0: 1 0. +* 0.9.8: 0 9 8. +* 0.9.7: 0 9 7. +* 0.9.6: 0 9 6. +* 0.9.5: 0 9 5. +* 0.9.4: 0 9 4. +* 0.9.3: 0 9 3. +* 0.9.2: 0 9 2. +* 0.9.1: 0 9 1. +* 0.9: 0 9. +* 0.8: 0 8. +* 0.7.8: 0 7 8. +* 0.7.7: 0 7 7. +* 0.7.6: 0 7 6. +* 0.7.5: 0 7 5. +* 0.7.4: 0 7 4. +* 0.7.3: 0 7 3. +* 0.7.2: 0 7 2. +* 0.7.1: 0 7 1. +* 0.7: 0 7. +* 0.7b4: 0 7b4. +* 0.6.49: 0 6 49. +* 0.6.48: 0 6 48. +* 0.6.47: 0 6 47. +* 0.6.46: 0 6 46. +* 0.6.45: 0 6 45. +* 0.6.44: 0 6 44. +* 0.6.43: 0 6 43. +* 0.6.42: 0 6 42. +* 0.6.41: 0 6 41. +* 0.6.40: 0 6 40. +* 0.6.39: 0 6 39. +* 0.6.38: 0 6 38. +* 0.6.37: 0 6 37. +* 0.6.36: 0 6 36. +* 0.6.35: 0 6 35. +* 0.6.34: 0 6 34. +* 0.6.33: 0 6 33. +* 0.6.32: 0 6 32. +* 0.6.31: 0 6 31. +* 0.6.30: 0 6 30. +* 0.6.29: 0 6 29. +* 0.6.28: 0 6 28. +* 0.6.27: 0 6 27. +* 0.6.26: 0 6 26. +* 0.6.25: 0 6 25. +* 0.6.24: 0 6 24. +* 0.6.23: 0 6 23. +* 0.6.21: 0 6 21. +* 0.6.20: 0 6 20. +* 0.6.19: 0 6 19. +* 0.6.18: 0 6 18. +* 0.6.17: 0 6 17. +* 0.6.16: 0 6 16. +* 0.6.15: 0 6 15. +* 0.6.14: 0 6 14. +* 0.6.13: 0 6 13. +* 0.6.12: 0 6 12. +* 0.6.11: 0 6 11. +* 0.6.10: 0 6 10. +* 0.6.9: 0 6 9. +* 0.6.8: 0 6 8. +* 0.6.7: 0 6 7. +* 0.6.6: 0 6 6. +* 0.6.5: 0 6 5. +* 0.6.4: 0 6 4. +* 0.6.3: 0 6 3. +* 0.6.2: 0 6 2. +* 0.6.1: 0 6 1. +* 0.6: 0 6. +* 0.6c9: 0 6c9. +* 0.6c7: 0 6c7. +* 0.6c6: 0 6c6. +* 0.6c5: 0 6c5. +* 0.6c4: 0 6c4. +* 0.6c3: 0 6c3. +* 0.6c2: 0 6c2. +* 0.6c1: 0 6c1. +* 0.6b4: 0 6b4. +* 0.6b3: 0 6b3. +* 0.6b2: 0 6b2. +* 0.6b1: 0 6b1. +* 0.6a11: 0 6a11. +* 0.6a10: 0 6a10. +* 0.6a9: 0 6a9. +* 0.6a8: 0 6a8. +* 0.6a7: 0 6a7. +* 0.6a6: 0 6a6. +* 0.6a5: 0 6a5. +* 0.6a3: 0 6a3. +* 0.6a2: 0 6a2. +* 0.6a1: 0 6a1. +* 0.5a12: 0 5a12. +* 0.5a11: 0 5a11. +* 0.5a10: 0 5a10. +* 0.5a9: 0 5a9. +* 0.5a8: 0 5a8. +* 0.5a7: 0 5a7. +* 0.5a6: 0 5a6. +* 0.5a5: 0 5a5. +* 0.5a4: 0 5a4. +* 0.5a3: 0 5a3. +* 0.5a2: 0 5a2. +* 0.5a1: 0 5a1. +* 0.4a4: 0 4a4. +* 0.4a3: 0 4a3. +* 0.4a2: 0 4a2. +* 0.4a1: 0 4a1. +* 0.3a4: 0 3a4. +* 0.3a3: 0 3a3. +* 0.3a2: 0 3a2. +* 0.3a1: 0 3a1. + +v50.3.2 + +* Documentation changes:: +* Misc:: + +v50.3.1 + +* Documentation changes: Documentation changes<2>. +* Misc: Misc<2>. + +v50.3.0 + +* Changes:: + +v50.2.0 + +* Changes: Changes<2>. + +v50.1.0 + +* Changes: Changes<3>. + +v50.0.3 + +* Misc: Misc<3>. + +v50.0.2 + +* Misc: Misc<4>. + +v50.0.1 + +* Misc: Misc<5>. + +v50.0.0 + +* Breaking Changes:: +* Changes: Changes<4>. + +v49.6.0 + +* Changes: Changes<5>. + +v49.5.0 + +* Changes: Changes<6>. + +v49.4.0 + +* Changes: Changes<7>. + +v49.3.2 + +* Documentation changes: Documentation changes<3>. +* Misc: Misc<6>. + +v49.3.1 + +* Changes: Changes<8>. + +v49.3.0 + +* Changes: Changes<9>. + +v49.2.1 + +* Misc: Misc<7>. + +v49.2.0 + +* Changes: Changes<10>. + +v49.1.3 + +* Misc: Misc<8>. + +v49.1.2 + +* Changes: Changes<11>. + +v49.1.1 + +* Misc: Misc<9>. + +v49.0.1 + +* Misc: Misc<10>. + +v49.1.0 + +* Changes: Changes<12>. + +v49.0.0 + +* Breaking Changes: Breaking Changes<2>. +* Changes: Changes<13>. +* Misc: Misc<11>. + +v48.0.0 + +* Breaking Changes: Breaking Changes<3>. + +v47.3.2 + +* Misc: Misc<12>. + +v47.3.1 + +* Misc: Misc<13>. + +v47.3.0 + +* Changes: Changes<14>. +* Misc: Misc<14>. + +v47.2.0 + +* Changes: Changes<15>. + +v47.1.1 + +* Documentation changes: Documentation changes<4>. +* Incorporate changes from v44.1.1;: Incorporate changes from v44 1 1. + +v44.1.1 + +* Misc: Misc<15>. + +v47.1.0 + +* Changes: Changes<16>. + +v47.0.0 + +* Breaking Changes: Breaking Changes<4>. +* Changes: Changes<17>. + +v46.4.0 + +* Changes: Changes<18>. + +v46.3.0 + +* Changes: Changes<19>. +* Misc: Misc<16>. + +v46.2.0 + +* Changes: Changes<20>. +* Documentation changes: Documentation changes<5>. +* Misc: Misc<17>. + +v46.1.2 + +* Misc: Misc<18>. + +v46.1.0 + +* Changes: Changes<21>. +* Incorporate changes from v44.1.0;: Incorporate changes from v44 1 0. + +v44.1.0 + +* Changes: Changes<22>. + +v46.0.0 + +* Breaking Changes: Breaking Changes<5>. +* Changes: Changes<23>. +* Documentation changes: Documentation changes<6>. +* Misc: Misc<19>. + +v45.3.0 + +* Changes: Changes<24>. + +v45.2.0 + +* Changes: Changes<25>. +* Misc: Misc<20>. + +v45.1.0 + +* Changes: Changes<26>. + +v45.0.0 + +* Breaking Changes: Breaking Changes<6>. +* Changes: Changes<27>. + +v44.0.0 + +* Breaking Changes: Breaking Changes<7>. + +v43.0.0 + +* Breaking Changes: Breaking Changes<8>. +* Changes: Changes<28>. + +v42.0.2 + +* Changes: Changes<29>. + +v42.0.1 + +* Changes: Changes<30>. + +v42.0.0 + +* Breaking Changes: Breaking Changes<9>. +* Changes: Changes<31>. + +v41.6.0 + +* Changes: Changes<32>. + +v41.5.1 + +* Changes: Changes<33>. + +v41.5.0 + +* Changes: Changes<34>. +* Documentation changes: Documentation changes<7>. +* Misc: Misc<21>. + +v41.4.0 + +* Changes: Changes<35>. + +v41.3.0 + +* Changes: Changes<36>. +* Misc: Misc<22>. + +v41.2.0 + +* Changes: Changes<37>. +* Misc: Misc<23>. + +v41.1.0 + +* Misc: Misc<24>. +* Documentation changes: Documentation changes<8>. + +v41.0.1 + +* Changes: Changes<38>. + +v41.0.0 + +* Breaking Changes: Breaking Changes<10>. + +v40.9.0 + +* Changes: Changes<39>. +* Documentation changes: Documentation changes<9>. + +v40.8.0 + +* Changes: Changes<40>. + +v40.7.3 + +* Changes: Changes<41>. + +v40.7.2 + +* Changes: Changes<42>. + +v40.7.1 + +* Changes: Changes<43>. + +v40.7.0 + +* Breaking Changes: Breaking Changes<11>. +* Changes: Changes<44>. + +v40.6.3 + +* Changes: Changes<45>. + +v40.6.2 + +* Changes: Changes<46>. + +v40.6.1 + +* Changes: Changes<47>. + +v40.6.0 + +* Deprecations:: +* Changes: Changes<48>. +* Documentation changes: Documentation changes<10>. +* Misc: Misc<25>. + +v40.5.0 + +* Changes: Changes<49>. +* Documentation changes: Documentation changes<11>. + +v40.4.3 + +* Changes: Changes<50>. + +v40.4.2 + +* Misc: Misc<26>. + +v40.4.1 + +* Changes: Changes<51>. + +v40.4.0 + +* Changes: Changes<52>. + +v40.3.0 + +* Changes: Changes<53>. +* Misc: Misc<27>. + +v40.2.0 + +* Changes: Changes<54>. + +v40.1.1 + +* Changes: Changes<55>. + +v40.1.0 + +* Changes: Changes<56>. +* Misc: Misc<28>. + +v40.0.0 + +* Breaking Changes: Breaking Changes<12>. +* Changes: Changes<57>. +* Documentation changes: Documentation changes<12>. +* Misc: Misc<29>. + +v39.2.0 + +* Changes: Changes<58>. +* Documentation changes: Documentation changes<13>. +* Misc: Misc<30>. + +1.0 + +* Backward-Incompatible Changes:: + +0.6.3 + +* setuptools:: +* bootstrapping:: + +0.6.2 + +* setuptools: setuptools<2>. +* bootstrapping: bootstrapping<2>. + +0.6.1 + +* setuptools: setuptools<3>. +* bootstrapping: bootstrapping<3>. + +0.6 + +* setuptools: setuptools<4>. +* pkg_resources:: +* easy_install:: + + + +File: setuptools.info, Node: Building and Distributing Packages with Setuptools, Next: Build System Support, Prev: Top, Up: Top + +1 Building and Distributing Packages with Setuptools +**************************************************** + +‘Setuptools’ is a collection of enhancements to the Python ‘distutils’ +that allow developers to more easily build and distribute Python +packages, especially ones that have dependencies on other packages. + +Packages built and distributed using ‘setuptools’ look to the user like +ordinary Python packages based on the ‘distutils’. + +* Menu: + +* Transition to PEP517:: + + +File: setuptools.info, Node: Transition to PEP517, Up: Building and Distributing Packages with Setuptools + +1.1 Transition to PEP517 +======================== + +Since setuptools no longer serves as the default build tool, one must +explicitly opt in (by providing a ‘pyproject.toml’ file) to use this +library. The user facing part is provided by tools such as pip and +backend interface is described *note in this document: 5. The +quickstart provides an overview of the new workflow. + +* Menu: + +* setuptools Quickstart:: +* Package Discovery and Namespace Package:: +* Entry Points:: +* Dependencies Management in Setuptools:: +* Data Files Support:: +* “Development Mode”:: +* Tagging and “Daily Build” or “Snapshot” Releases:: +* Generating Source Distributions:: +* Distributing Extensions compiled with Cython:: +* Specifying Your Project’s Version:: +* Creating distutils Extensions:: +* Configuring setup() using setup.cfg files: Configuring setup using setup cfg files. +* New and Changed setup() Keywords: New and Changed setup Keywords. +* Command Reference:: +* Using setuptools to package and distribute your project:: +* Automatic Resource Extraction:: +* Defining Additional Metadata:: +* Setting the zip_safe flag:: + + +File: setuptools.info, Node: setuptools Quickstart, Next: Package Discovery and Namespace Package, Up: Transition to PEP517 + +1.1.1 ‘setuptools’ Quickstart +----------------------------- + +* Menu: + +* Installation:: +* Python packaging at a glance:: +* Basic Use:: +* Automatic package discovery:: +* Entry points and automatic script creation:: +* Dependency management:: +* Including Data Files:: +* Development mode:: +* Uploading your package to PyPI:: +* Transitioning from setup.py to setup.cfg: Transitioning from setup py to setup cfg. +* Resources on Python packaging:: + + +File: setuptools.info, Node: Installation, Next: Python packaging at a glance, Up: setuptools Quickstart + +1.1.1.1 Installation +.................... + +To install the latest version of setuptools, use: + + pip install --upgrade setuptools + + +File: setuptools.info, Node: Python packaging at a glance, Next: Basic Use, Prev: Installation, Up: setuptools Quickstart + +1.1.1.2 Python packaging at a glance +.................................... + +The landscape of Python packaging is shifting and ‘Setuptools’ has +evolved to only provide backend support, no longer being the de-facto +packaging tool in the market. All python package must provide a +‘pyproject.toml’ and specify the backend (build system) it wants to use. +The distribution can then be generated with whatever tools that provides +a ‘build sdist’-alike functionality. While this may appear cumbersome, +given the added pieces, it in fact tremendously enhances the portability +of your package. The change is driven under 517(1). To learn more +about Python packaging in general, navigate to the bottom(2) of this +page. + + ---------- Footnotes ---------- + + (1) https://www.python.org/dev/peps/pep-0517#build-requirements + + (2) Resourcesonpythonpackaging + + +File: setuptools.info, Node: Basic Use, Next: Automatic package discovery, Prev: Python packaging at a glance, Up: setuptools Quickstart + +1.1.1.3 Basic Use +................. + +For basic use of setuptools, you will need a ‘pyproject.toml’ with the +exact following info, which declares you want to use ‘setuptools’ to +package your project: + + [build-system] + requires = ["setuptools", "wheel"] + build-backend = "setuptools.build_meta" + +Then, you will need a ‘setup.cfg’ to specify your package information, +such as metadata, contents, dependencies, etc. Here we demonstrate the +minimum + + [metadata] + name = "mypackage" + version = 0.0.1 + + [options] + packages = "mypackage" + install_requires = + requests + importlib; python_version == "2.6" + +This is what your project would look like: + + ~/mypackage/ + pyproject.toml + setup.cfg + mypackage/__init__.py + +Then, you need an installer, such as pep517(1) which you can obtain via +‘pip install pep517’. After downloading it, invoke the installer: + + python -m pep517.build + +You now have your distribution ready (e.g. a ‘tar.gz’ file and a ‘.whl’ +file in the ‘dist’ directory), which you can upload to PyPI! + +Of course, before you release your project to PyPI, you’ll want to add a +bit more information to your setup script to help people find or learn +about your project. And maybe your project will have grown by then to +include a few dependencies, and perhaps some data files and scripts. In +the next few section, we will walk through those additional but +essential information you need to specify to properly package your +project. + + ---------- Footnotes ---------- + + (1) https://pypi.org/project/pep517/ + + +File: setuptools.info, Node: Automatic package discovery, Next: Entry points and automatic script creation, Prev: Basic Use, Up: setuptools Quickstart + +1.1.1.4 Automatic package discovery +................................... + +For simple projects, it’s usually easy enough to manually add packages +to the ‘packages’ keyword in ‘setup.cfg’. However, for very large +projects , it can be a big burden to keep the package list updated. +‘setuptools’ therefore provides two convenient tools to ease the burden: +‘find:’ and ‘find_namespace:’. To use it in your project: + + [options] + packages = find: + + [options.packages.find] #optional + include=pkg1, pkg2 + exclude=pk3, pk4 + +When you pass the above information, alongside other necessary ones, +‘setuptools’ walks through the directory specified in ‘where’ (omitted +here as the package reside in current directory) and filters the +packages it can find following the ‘include’ (default to none), then +remove those that match the ‘exclude’ and return a list of Python +packages. Note that each entry in the ‘[options.packages.find]’ is +optional. The above setup also allows you to adopt a ‘src/’ layout. +For more details and advanced use, go to *note Package Discovery and +Namespace Package: c. + + +File: setuptools.info, Node: Entry points and automatic script creation, Next: Dependency management, Prev: Automatic package discovery, Up: setuptools Quickstart + +1.1.1.5 Entry points and automatic script creation +.................................................. + +Setuptools support automatic creation of scripts upon installation, that +runs code within your package if you specify them with the +‘entry_points’ keyword. This is what allows you to run commands like +‘pip install’ instead of having to type ‘python -m pip install’. To +accomplish this, add the entry_points keyword in your ‘setup.cfg’: + + [options.entry_points] + console_scripts = + main = mypkg:some_func + +When this project is installed, a ‘main’ script will be installed and +will invoke the ‘some_func’ in the ‘__init__.py’ file when called by the +user. For detailed usage, including managing the additional or optional +dependencies, go to *note Entry Points: e. + + +File: setuptools.info, Node: Dependency management, Next: Including Data Files, Prev: Entry points and automatic script creation, Up: setuptools Quickstart + +1.1.1.6 Dependency management +............................. + +‘setuptools’ supports automatically installing dependencies when a +package is installed. The simplest way to include requirement +specifiers is to use the ‘install_requires’ argument to ‘setup.cfg’. It +takes a string or list of strings containing requirement specifiers (A +version specifier is one of the operators <, >, <=, >=, == or !=, +followed by a version identifier): + + [options] + install_requires = + docutils >= 0.3 + requests <= 0.4 + +When your project is installed, all of the dependencies not already +installed will be located (via PyPI), downloaded, built (if necessary), +and installed. This, of course, is a simplified scenarios. +‘setuptools’ also provide additional keywords such as ‘setup_requires’ +that allows you to install dependencies before running the script, and +‘extras_requires’ that take care of those needed by automatically +generated scripts. It also provides mechanisms to handle dependencies +that are not in PyPI. For more advanced use, see *note Dependencies +Management in Setuptools: 10. + + +File: setuptools.info, Node: Including Data Files, Next: Development mode, Prev: Dependency management, Up: setuptools Quickstart + +1.1.1.7 Including Data Files +............................ + +The distutils have traditionally allowed installation of “data files”, +which are placed in a platform-specific location. Setuptools offers +three ways to specify data files to be included in your packages. For +the simpliest use, you can simply use the ‘include_package_data’ +keyword: + + [options] + include_package_data = True + +This tells setuptools to install any data files it finds in your +packages. The data files must be specified via the distutils’ +‘MANIFEST.in’ file. For more details, see *note Data Files Support: 13. + + +File: setuptools.info, Node: Development mode, Next: Uploading your package to PyPI, Prev: Including Data Files, Up: setuptools Quickstart + +1.1.1.8 Development mode +........................ + +‘setuptools’ allows you to install a package without copying any files +to your interpretor directory (e.g. the ‘site-packages’ directory). +This allows you to modify your source code and have the changes take +effect without you having to rebuild and reinstall. This is currently +incompatible with PEP 517 and therefore it requires a ‘setup.py’ script +with the following content: + + import setuptools + setuptools.setup() + +Then: + + pip install --editable . + +This creates a link file in your interpretor site package directory +which associate with your source code. For more information, see: (WIP) + + +File: setuptools.info, Node: Uploading your package to PyPI, Next: Transitioning from setup py to setup cfg, Prev: Development mode, Up: setuptools Quickstart + +1.1.1.9 Uploading your package to PyPI +...................................... + +After generating the distribution files, next step would be to upload +your distribution so others can use it. This functionality is provided +by twine(1) and we will only demonstrate the basic use here. + + ---------- Footnotes ---------- + + (1) https://pypi.org/project/twine/ + + +File: setuptools.info, Node: Transitioning from setup py to setup cfg, Next: Resources on Python packaging, Prev: Uploading your package to PyPI, Up: setuptools Quickstart + +1.1.1.10 Transitioning from ‘setup.py’ to ‘setup.cfg’ +..................................................... + +To avoid executing arbitary scripts and boilerplate code, we are +transitioning into a full-fledged ‘setup.cfg’ to declare your package +information instead of running ‘setup()’. This inevitably brings +challenges due to a different syntax. Here we provide a quick guide to +understanding how ‘setup.cfg’ is parsed by ‘setuptool’ to ease the pain +of transition. + + +File: setuptools.info, Node: Resources on Python packaging, Prev: Transitioning from setup py to setup cfg, Up: setuptools Quickstart + +1.1.1.11 Resources on Python packaging +...................................... + +Packaging in Python is hard. Here we provide a list of links for those +that want to learn more. + + +File: setuptools.info, Node: Package Discovery and Namespace Package, Next: Entry Points, Prev: setuptools Quickstart, Up: Transition to PEP517 + +1.1.2 Package Discovery and Namespace Package +--------------------------------------------- + + Note: a full specification for the keyword supplied to ‘setup.cfg’ + or ‘setup.py’ can be found at *note keywords reference: 1a. + + Note: the examples provided here are only to demonstrate the + functionality introduced. More metadata and options arguments need + to be supplied if you want to replicate them on your system. If + you are completely new to setuptools, the *note quickstart section: + 6. is a good place to start. + +‘Setuptools’ provide powerful tools to handle package discovery, +including support for namespace package. Normally, you would specify +the package to be included manually in the following manner: + + [options] + #... + packages = + mypkg1 + mypkg2 + + setup( + #... + packages = ['mypkg1', 'mypkg2'] + ) + +This can get tiresome reallly quickly. To speed things up, we introduce +two functions provided by setuptools: + + [options] + packages = find: + #or + packages = find_namespace: + + from setuptools import find_packages + #or + from setuptools import find_namespace_packages + +* Menu: + +* Using find; or find_packages: Using find or find_packages. +* Using find_namespace; or find_namespace_packages: Using find_namespace or find_namespace_packages. +* Legacy Namespace Packages:: + + +File: setuptools.info, Node: Using find or find_packages, Next: Using find_namespace or find_namespace_packages, Up: Package Discovery and Namespace Package + +1.1.2.1 Using ‘find:’ or ‘find_packages’ +........................................ + +Let’s start with the first tool. ‘find:’ (‘find_packages’) takes a +source directory and two lists of package name patterns to exclude and +include, and then return a list of ‘str’ representing the packages it +could find. To use it, consider the following directory + + mypkg/ + src/ + pkg1/__init__.py + pkg2/__init__.py + additional/__init__.py + + setup.cfg #or setup.py + +To have your setup.cfg or setup.py to automatically include packages +found in ‘src’ that starts with the name ‘pkg’ and not ‘additional’: + + [options] + packages = find: + package_dir = + =src + + [options.packages.find] + where = src + include = pkg* + exclude = additional + + setup( + #... + packages = find_packages( + where = 'src', + include = ['pkg*',], + exclude = ['additional',] + ), + package_dir = {"":"src"} + #... + ) + + +File: setuptools.info, Node: Using find_namespace or find_namespace_packages, Next: Legacy Namespace Packages, Prev: Using find or find_packages, Up: Package Discovery and Namespace Package + +1.1.2.2 Using ‘find_namespace:’ or ‘find_namespace_packages’ +............................................................ + +‘setuptools’ provides the ‘find_namespace:’ (‘find_namespace_packages’) +which behaves similarly to ‘find:’ but works with namespace package. +Before diving in, it is important to have a good understanding of what +namespace packages are. Here is a quick recap: + +Suppose you have two packages named as follows: + + /Users/Desktop/timmins/foo/__init__.py + /Library/timmins/bar/__init__.py + +If both ‘Desktop’ and ‘Library’ are on your ‘PYTHONPATH’, then a +namespace package called ‘timmins’ will be created automatically for you +when you invoke the import mechanism, allowing you to accomplish the +following + + >>> import timmins.foo + >>> import timmins.bar + +as if there is only one ‘timmins’ on your system. The two packages can +then be distributed separately and installed individually without +affecting the other one. Suppose you are packaging the ‘foo’ part: + + foo/ + src/ + timmins/foo/__init__.py + setup.cfg # or setup.py + +and you want the ‘foo’ to be automatically included, ‘find:’ won’t work +because timmins doesn’t contain ‘__init__.py’ directly, instead, you +have to use ‘find_namespace:’: + + [options] + package_dir = + =src + packages = find_namespace: + + [options.packages.find_namespace] + where = src + +When you install the zipped distribution, ‘timmins.foo’ would become +available to your interpreter. + +You can think of ‘find_namespace:’ as identical to ‘find:’ except it +would count a directory as a package even if it doesn’t contain +‘__init__.py’ file directly. As a result, this creates an interesting +side effect. If you organize your package like this: + + foo/ + timmins/ + foo/__init__.py + setup.cfg # or setup.py + tests/ + test_foo/__init__.py + +a naive ‘find_namespace:’ would include tests as part of your package to +be installed. A simple way to fix it is to adopt the aforementioned +‘src’ layout. + + +File: setuptools.info, Node: Legacy Namespace Packages, Prev: Using find_namespace or find_namespace_packages, Up: Package Discovery and Namespace Package + +1.1.2.3 Legacy Namespace Packages +................................. + +The fact you can create namespace package so effortlessly above is +credited to PEP 420(1). It use to be more cumbersome to accomplish the +same result. Historically, there were two methods to create namespace +packages. One is the ‘pkg_resources’ style supported by ‘setuptools’ +and the other one being ‘pkgutils’ style offered by ‘pkgutils’ module in +Python. Both are now considered deprecated despite the fact they still +linger in many existing packages. These two differ in many subtle yet +significant aspects and you can find out more on Python packaging user +guide(2) + +* Menu: + +* pkg_resource style namespace package:: +* pkgutil style namespace package:: + + ---------- Footnotes ---------- + + (1) https://www.python.org/dev/peps/pep-0420/ + + (2) https://packaging.python.org/guides/packaging-namespace-packages/ + + +File: setuptools.info, Node: pkg_resource style namespace package, Next: pkgutil style namespace package, Up: Legacy Namespace Packages + +1.1.2.4 ‘pkg_resource’ style namespace package +.............................................. + +This is the method ‘setuptools’ directly supports. Starting with the +same layout, there are two pieces you need to add to it. First, an +‘__init__.py’ file directly under your namespace package directory that +contains the following: + + __import__("pkg_resources").declare_namespace(__name__) + +And the ‘namespace_packages’ keyword in your ‘setup.cfg’ or ‘setup.py’: + + [options] + namespace_packages = timmins + + setup( + # ... + namespace_packages = ['timmins'] + ) + +And your directory should look like this + + /foo/ + src/ + timmins/ + __init__.py + foo/__init__.py + setup.cfg #or setup.py + +Repeat the same for other packages and you can achieve the same result +as the previous section. + + +File: setuptools.info, Node: pkgutil style namespace package, Prev: pkg_resource style namespace package, Up: Legacy Namespace Packages + +1.1.2.5 ‘pkgutil’ style namespace package +......................................... + +This method is almost identical to the ‘pkg_resource’ except that the +‘namespace_packages’ declaration is omitted and the ‘__init__.py’ file +contains the following: + + __path__ = __import__('pkgutil').extend_path(__path__, __name__) + +The project layout remains the same and ‘setup.cfg’ remains the same. + + +File: setuptools.info, Node: Entry Points, Next: Dependencies Management in Setuptools, Prev: Package Discovery and Namespace Package, Up: Transition to PEP517 + +1.1.3 Entry Points +------------------ + +Packages may provide commands to be run at the console (console +scripts), such as the ‘pip’ command. These commands are defined for a +package as a specific kind of entry point in the ‘setup.cfg’ or +‘setup.py’. + +* Menu: + +* Console Scripts:: +* Advertising Behavior:: +* Dependency Management:: + + +File: setuptools.info, Node: Console Scripts, Next: Advertising Behavior, Up: Entry Points + +1.1.3.1 Console Scripts +....................... + +First consider an example without entry points. Imagine a package +defined thus: + + timmins/ + timmins/__init__.py + timmins/__main__.py + setup.cfg # or setup.py + #other necessary files + +with ‘__init__.py’ as: + + def helloworld(): + print("Hello world") + +and ‘__main__.py’ providing a hook: + + from . import hello_world + if __name__ == '__main__': + hello_world() + +After installing the package, the function may be invoked through the +runpy(1) module: + + python -m timmins + +Adding a console script entry point allows the package to define a +user-friendly name for installers of the package to execute. Installers +like pip will create wrapper scripts to execute a function. In the +above example, to create a command ‘hello-world’ that invokes +‘timmins.hello_world’, add a console script entry point to ‘setup.cfg’: + + [options.entry_points] + console_scripts = + hello-world = timmins:hello_world + +After installing the package, a user may invoke that function by simply +calling ‘hello-world’ on the command line. + +The syntax for entry points is specified as follows: + + <name> = [<package>.[<subpackage>.]]<module>[:<object>.<object>] + +where ‘name’ is the name for the script you want to create, the left +hand side of ‘:’ is the module that contains your function and the right +hand side is the object you want to invoke (e.g. a function). + +In addition to ‘console_scripts’, Setuptools supports ‘gui_scripts’, +which will launch a GUI application without running in a terminal +window. + + ---------- Footnotes ---------- + + (1) https://docs.python.org/3/library/runpy.html + + +File: setuptools.info, Node: Advertising Behavior, Next: Dependency Management, Prev: Console Scripts, Up: Entry Points + +1.1.3.2 Advertising Behavior +............................ + +Console scripts are one use of the more general concept of entry points. +Entry points more generally allow a packager to advertise behavior for +discovery by other libraries and applications. This feature enables +“plug-in”-like functionality, where one library solicits entry points +and any number of other libraries provide those entry points. + +A good example of this plug-in behavior can be seen in pytest +plugins(1), where pytest is a test framework that allows other libraries +to extend or modify its functionality through the ‘pytest11’ entry +point. + +The console scripts work similarly, where libraries advertise their +commands and tools like ‘pip’ create wrapper scripts that invoke those +commands. + +For a project wishing to solicit entry points, Setuptools recommends the +importlib.metadata(2) module (part of stdlib since Python 3.8) or its +backport, importlib_metadata(3). + +For example, to find the console script entry points from the example +above: + + >>> from importlib import metadata + >>> eps = metadata.entry_points()['console_scripts'] + +‘eps’ is now a list of ‘EntryPoint’ objects, one of which corresponds to +the ‘hello-world = timmins:hello_world’ defined above. Each +‘EntryPoint’ contains the ‘name’, ‘group’, and ‘value’. It also +supplies a ‘.load()’ method to import and load that entry point (module +or object). + + [options.entry_points] + my.plugins = + hello-world = timmins:hello_world + +Then, a different project wishing to load ‘my.plugins’ plugins could run +the following routine to load (and invoke) such plugins: + + >>> from importlib import metadata + >>> eps = metadata.entry_points()['my.plugins'] + >>> for ep in eps: + ... plugin = ep.load() + ... plugin() + +The project soliciting the entry points needs not to have any dependency +or prior knowledge about the libraries implementing the entry points, +and downstream users are able to compose functionality by pulling +together libraries implementing the entry points. + + ---------- Footnotes ---------- + + (1) https://docs.pytest.org/en/latest/writing_plugins.html + + (2) https://docs.python.org/3/library/importlib.metadata.html + + (3) https://pypi.org/project/importlib_metadata + + +File: setuptools.info, Node: Dependency Management, Prev: Advertising Behavior, Up: Entry Points + +1.1.3.3 Dependency Management +............................. + +Some entry points may require additional dependencies to properly +function. For such an entry point, declare in square brakets any number +of dependency ‘extras’ following the entry point definition. Such entry +points will only be viable if their extras were declared and installed. +See the *note guide on dependencies management: 10. for more information +on defining extra requirements. Consider from the above example: + + [options.entry_points] + console_scripts = + hello-world = timmins:hello_world [pretty-printer] + +In this case, the ‘hello-world’ script is only viable if the +‘pretty-printer’ extra is indicated, and so a plugin host might exclude +that entry point (i.e. not install a console script) if the relevant +extra dependencies are not installed. + + +File: setuptools.info, Node: Dependencies Management in Setuptools, Next: Data Files Support, Prev: Entry Points, Up: Transition to PEP517 + +1.1.4 Dependencies Management in Setuptools +------------------------------------------- + +There are three types of dependency styles offered by setuptools: 1) +build system requirement, required dependency and 3) optional +dependency. + + Note: Packages that are added to dependency can be optionally + specified with the version by following PEP 440(1) + +* Menu: + +* Build system requirement:: +* Declaring required dependency:: +* Optional dependencies:: +* Python requirement:: + + ---------- Footnotes ---------- + + (1) https://www.python.org/dev/peps/pep-0440/ + + +File: setuptools.info, Node: Build system requirement, Next: Declaring required dependency, Up: Dependencies Management in Setuptools + +1.1.4.1 Build system requirement +................................ + +* Menu: + +* Package requirement:: + + +File: setuptools.info, Node: Package requirement, Up: Build system requirement + +1.1.4.2 Package requirement +........................... + +After organizing all the scripts and files and getting ready for +packaging, there needs to be a way to tell Python what programs it need +to actually do the packgaging (in our case, ‘setuptools’ of course). +Usually, you also need the ‘wheel’ package as well since it is +recommended that you upload a ‘.whl’ file to PyPI alongside your +‘.tar.gz’ file. Unlike the other two types of dependency keyword, this +one is specified in your ‘pyproject.toml’ file (if you have forgot what +this is, go to *note setuptools Quickstart: 6. or (WIP)): + + [build-system] + requires = ["setuptools", "wheel"] + #... + + Note: This used to be accomplished with the ‘setup_requires’ + keyword but is now considered deprecated in favor of the PEP 517 + style described above. To peek into how this legacy keyword is + used, consult our *note guide on deprecated practice (WIP): 2a. + + +File: setuptools.info, Node: Declaring required dependency, Next: Optional dependencies, Prev: Build system requirement, Up: Dependencies Management in Setuptools + +1.1.4.3 Declaring required dependency +..................................... + +This is where a package declares its core dependencies, without which it +won’t be able to run. ‘setuptools’ support automatically download and +install these dependencies when the package is installed. Although +there is more finess to it, let’s start with a simple example. + + [options] + #... + install_requires = + docutils + BazSpam ==1.1 + + setup( + #..., + install_requires = [ + 'docutils', + 'BazSpam ==1.1' + ] + ) + +When your project is installed (e.g. using pip), all of the +dependencies not already installed will be located (via PyPI), +downloaded, built (if necessary), and installed and 2) Any scripts in +your project will be installed with wrappers that verify the +availability of the specified dependencies at runtime. + +* Menu: + +* Platform specific dependencies:: +* Dependencies that aren’t in PyPI:: + + +File: setuptools.info, Node: Platform specific dependencies, Next: Dependencies that aren’t in PyPI, Up: Declaring required dependency + +1.1.4.4 Platform specific dependencies +...................................... + +Setuptools offer the capability to evaluate certain conditions before +blindly installing everything listed in ‘install_requires’. This is +great for platform specific dependencies. For example, the ‘enum’ +package was added in Python 3.4, therefore, package that depends on it +can elect to install it only when the Python version is older than 3.4. +To accomplish this + + [options] + #... + install_requires = + enum34;python_version<'3.4' + + setup( + #... + install_requires=[ + "enum34;python_version<'3.4'",] + ) + +Similarly, if you also wish to declare ‘pywin32’ with a minimal version +of 1.0 and only install it if the user is using a Windows operating +system: + + [options] + #... + install_requires = + enum34;python_version<'3.4' + pywin32 >= 1.0;platform_system=='Windows' + + setup( + #... + install_requires=[ + "enum34;python_version<'3.4'", + "pywin32 >= 1.0;platform_system=='Windows'" + ] + ) + +The environmental markers that may be used for testing platform types +are detailed in PEP 508(1). + + ---------- Footnotes ---------- + + (1) https://www.python.org/dev/peps/pep-0508/ + + +File: setuptools.info, Node: Dependencies that aren’t in PyPI, Prev: Platform specific dependencies, Up: Declaring required dependency + +1.1.4.5 Dependencies that aren’t in PyPI +........................................ + + Warning: Dependency links support has been dropped by pip starting + with version 19.0 (released 2019-01-22). + +If your project depends on packages that don’t exist on PyPI, you may +still be able to depend on them, as long as they are available for +download as: + + - an egg, in the standard distutils ‘sdist’ format, + + - a single ‘.py’ file, or + + - a VCS repository (Subversion, Mercurial, or Git). + +You just need to add some URLs to the ‘dependency_links’ argument to +‘setup()’. + +The URLs must be either: + + 1. direct download URLs, + + 2. the URLs of web pages that contain direct download links, or + + 3. the repository’s URL + +In general, it’s better to link to web pages, because it is usually less +complex to update a web page than to release a new version of your +project. You can also use a SourceForge ‘showfiles.php’ link in the +case where a package you depend on is distributed via SourceForge. + +If you depend on a package that’s distributed as a single ‘.py’ file, +you must include an ‘"#egg=project-version"’ suffix to the URL, to give +a project name and version number. (Be sure to escape any dashes in the +name or version by replacing them with underscores.) EasyInstall will +recognize this suffix and automatically create a trivial ‘setup.py’ to +wrap the single ‘.py’ file as an egg. + +In the case of a VCS checkout, you should also append +‘#egg=project-version’ in order to identify for what package that +checkout should be used. You can append ‘@REV’ to the URL’s path +(before the fragment) to specify a revision. Additionally, you can also +force the VCS being used by prepending the URL with a certain prefix. +Currently available are: + + - ‘svn+URL’ for Subversion, + + - ‘git+URL’ for Git, and + + - ‘hg+URL’ for Mercurial + +A more complete example would be: + + ‘vcs+proto://host/path@revision#egg=project-version’ + +Be careful with the version. It should match the one inside the project +files. If you want to disregard the version, you have to omit it both +in the ‘requires’ and in the URL’s fragment. + +This will do a checkout (or a clone, in Git and Mercurial parlance) to a +temporary folder and run ‘setup.py bdist_egg’. + +The ‘dependency_links’ option takes the form of a list of URL strings. +For example, this will cause a search of the specified page for eggs or +source distributions, if the package’s dependencies aren’t already +installed: + + [options] + #... + dependency_links = http://peak.telecommunity.com/snapshots/ + + setup( + #... + dependency_links=[ + "http://peak.telecommunity.com/snapshots/" + ], + ) + + +File: setuptools.info, Node: Optional dependencies, Next: Python requirement, Prev: Declaring required dependency, Up: Dependencies Management in Setuptools + +1.1.4.6 Optional dependencies +............................. + +Setuptools allows you to declare dependencies that only get installed +under specific circumstances. These dependencies are specified with +‘extras_require’ keyword and are only installed if another package +depends on it (either directly or indirectly) This makes it convenient +to declare dependencies for ancillary functions such as “tests” and +“docs”. + + Note: ‘tests_require’ is now deprecated + +For example, Package-A offers optional PDF support and requires two +other dependencies for it to work: + + [metadata] + name = Package-A + + [options.extras_require] + PDF = ReportLab>=1.2; RXP + + setup( + name="Project-A", + #... + extras_require={ + "PDF": ["ReportLab>=1.2", "RXP"], + } + ) + +The name ‘PDF’ is an arbitary identifier of such a list of dependencies, +to which other components can refer and have them installed. There are +two common use cases. + +First is the console_scripts entry point: + + [metadata] + name = Project A + #... + + [options] + #... + entry_points= + [console_scripts] + rst2pdf = project_a.tools.pdfgen [PDF] + rst2html = project_a.tools.htmlgen + + setup( + name = "Project-A" + #..., + entry_points={ + "console_scripts": [ + "rst2pdf = project_a.tools.pdfgen [PDF]", + "rst2html = project_a.tools.htmlgen", + ], + } + ) + +When the script ‘rst2pdf’ is run, it will trigger the installation of +the two dependencies ‘PDF’ maps to. + +The second use case is that other package can use this “extra” for their +own dependencies. For example, if “Project-B” needs “project A” with +PDF support installed, it might declare the dependency like this: + + [metadata] + name = Project-B + #... + + [options] + #... + install_requires = + Project-A[PDF] + + setup( + name="Project-B", + install_requires=["Project-A[PDF]"], + ... + ) + +This will cause ReportLab to be installed along with project A, if +project B is installed – even if project A was already installed. In +this way, a project can encapsulate groups of optional “downstream +dependencies” under a feature name, so that packages that depend on it +don’t have to know what the downstream dependencies are. If a later +version of Project A builds in PDF support and no longer needs +ReportLab, or if it ends up needing other dependencies besides ReportLab +in order to provide PDF support, Project B’s setup information does not +need to change, but the right packages will still be installed if +needed. + + Note: Best practice: if a project ends up not needing any other + packages to support a feature, it should keep an empty requirements + list for that feature in its ‘extras_require’ argument, so that + packages depending on that feature don’t break (due to an invalid + feature name). + + +File: setuptools.info, Node: Python requirement, Prev: Optional dependencies, Up: Dependencies Management in Setuptools + +1.1.4.7 Python requirement +.......................... + +In some cases, you might need to specify the minimum required python +version. This is handled with the ‘python_requires’ keyword supplied to +‘setup.cfg’ or ‘setup.py’. + +Example WIP + + +File: setuptools.info, Node: Data Files Support, Next: “Development Mode”, Prev: Dependencies Management in Setuptools, Up: Transition to PEP517 + +1.1.5 Data Files Support +------------------------ + +The distutils have traditionally allowed installation of “data files”, +which are placed in a platform-specific location. However, the most +common use case for data files distributed with a package is for use +`by' the package, usually by including the data files in the package +directory. + +Setuptools offers three ways to specify data files to be included in +your packages. First, you can simply use the ‘include_package_data’ +keyword, e.g.: + + from setuptools import setup, find_packages + setup( + ... + include_package_data=True + ) + +This tells setuptools to install any data files it finds in your +packages. The data files must be specified via the distutils’ +‘MANIFEST.in’ file. (They can also be tracked by a revision control +system, using an appropriate plugin. See the section below on *note +Adding Support for Revision Control Systems: 32. for information on how +to write such plugins.) + +If you want finer-grained control over what files are included (for +example, if you have documentation files in your package directories and +want to exclude them from installation), then you can also use the +‘package_data’ keyword, e.g.: + + from setuptools import setup, find_packages + setup( + ... + package_data={ + # If any package contains *.txt or *.rst files, include them: + "": ["*.txt", "*.rst"], + # And include any *.msg files found in the "hello" package, too: + "hello": ["*.msg"], + } + ) + +The ‘package_data’ argument is a dictionary that maps from package names +to lists of glob patterns. The globs may include subdirectory names, if +the data files are contained in a subdirectory of the package. For +example, if the package tree looks like this: + + setup.py + src/ + mypkg/ + __init__.py + mypkg.txt + data/ + somefile.dat + otherdata.dat + +The setuptools setup file might look like this: + + from setuptools import setup, find_packages + setup( + ... + packages=find_packages("src"), # include all packages under src + package_dir={"": "src"}, # tell distutils packages are under src + + package_data={ + # If any package contains *.txt files, include them: + "": ["*.txt"], + # And include any *.dat files found in the "data" subdirectory + # of the "mypkg" package, also: + "mypkg": ["data/*.dat"], + } + ) + +Notice that if you list patterns in ‘package_data’ under the empty +string, these patterns are used to find files in every package, even +ones that also have their own patterns listed. Thus, in the above +example, the ‘mypkg.txt’ file gets included even though it’s not listed +in the patterns for ‘mypkg’. + +Also notice that if you use paths, you `must' use a forward slash (‘/’) +as the path separator, even if you are on Windows. Setuptools +automatically converts slashes to appropriate platform-specific +separators at build time. + +If datafiles are contained in a subdirectory of a package that isn’t a +package itself (no ‘__init__.py’), then the subdirectory names (or ‘*’) +are required in the ‘package_data’ argument (as shown above with +‘"data/*.dat"’). + +When building an ‘sdist’, the datafiles are also drawn from the +‘package_name.egg-info/SOURCES.txt’ file, so make sure that this is +removed if the ‘setup.py’ ‘package_data’ list is updated before calling +‘setup.py’. + +(Note: although the ‘package_data’ argument was previously only +available in ‘setuptools’, it was also added to the Python ‘distutils’ +package as of Python 2.4; there is some documentation for the feature(1) +available on the python.org website. If using the setuptools-specific +‘include_package_data’ argument, files specified by ‘package_data’ will +`not' be automatically added to the manifest unless they are listed in +the MANIFEST.in file.) + +Sometimes, the ‘include_package_data’ or ‘package_data’ options alone +aren’t sufficient to precisely define what files you want included. For +example, you may want to include package README files in your revision +control system and source distributions, but exclude them from being +installed. So, setuptools offers an ‘exclude_package_data’ option as +well, that allows you to do things like this: + + from setuptools import setup, find_packages + setup( + ... + packages=find_packages("src"), # include all packages under src + package_dir={"": "src"}, # tell distutils packages are under src + + include_package_data=True, # include everything in source control + + # ...but exclude README.txt from all packages + exclude_package_data={"": ["README.txt"]}, + ) + +The ‘exclude_package_data’ option is a dictionary mapping package names +to lists of wildcard patterns, just like the ‘package_data’ option. +And, just as with that option, a key of ‘""’ will apply the given +pattern(s) to all packages. However, any files that match these +patterns will be `excluded' from installation, even if they were listed +in ‘package_data’ or were included as a result of using +‘include_package_data’. + +In summary, the three options allow you to: + +‘include_package_data’ + + Accept all data files and directories matched by ‘MANIFEST.in’. + +‘package_data’ + + Specify additional patterns to match files that may or may not be + matched by ‘MANIFEST.in’ or found in source control. + +‘exclude_package_data’ + + Specify patterns for data files and directories that should `not' + be included when a package is installed, even if they would + otherwise have been included due to the use of the preceding + options. + +NOTE: Due to the way the distutils build process works, a data file that +you include in your project and then stop including may be “orphaned” in +your project’s build directories, requiring you to run ‘setup.py clean +--all’ to fully remove them. This may also be important for your users +and contributors if they track intermediate revisions of your project +using Subversion; be sure to let them know when you make changes that +remove files from inclusion so they can run ‘setup.py clean --all’. + +* Menu: + +* Accessing Data Files at Runtime:: +* Non-Package Data Files:: + + ---------- Footnotes ---------- + + (1) +https://docs.python.org/3/distutils/setupscript.html#installing-package-data + + +File: setuptools.info, Node: Accessing Data Files at Runtime, Next: Non-Package Data Files, Up: Data Files Support + +1.1.5.1 Accessing Data Files at Runtime +....................................... + +Typically, existing programs manipulate a package’s ‘__file__’ attribute +in order to find the location of data files. However, this manipulation +isn’t compatible with PEP 302-based import hooks, including importing +from zip files and Python Eggs. It is strongly recommended that, if you +are using data files, you should use the *note ResourceManager API: 35. +of ‘pkg_resources’ to access them. The ‘pkg_resources’ module is +distributed as part of setuptools, so if you’re using setuptools to +distribute your package, there is no reason not to use its resource +management API. See also Importlib Resources(1) for a quick example of +converting code that uses ‘__file__’ to use ‘pkg_resources’ instead. + + ---------- Footnotes ---------- + + (1) +https://docs.python.org/3/library/importlib.html#module-importlib.resources + + +File: setuptools.info, Node: Non-Package Data Files, Prev: Accessing Data Files at Runtime, Up: Data Files Support + +1.1.5.2 Non-Package Data Files +.............................. + +Historically, ‘setuptools’ by way of ‘easy_install’ would encapsulate +data files from the distribution into the egg (see the old docs(1)). As +eggs are deprecated and pip-based installs fall back to the +platform-specific location for installing data files, there is no +supported facility to reliably retrieve these resources. + +Instead, the PyPA recommends that any data files you wish to be +accessible at run time be included in the package. + + ---------- Footnotes ---------- + + (1) +https://github.com/pypa/setuptools/blob/52aacd5b276fedd6849c3a648a0014f5da563e93/docs/setuptools.txt#L970-L1001 + + +File: setuptools.info, Node: “Development Mode”, Next: Tagging and “Daily Build” or “Snapshot” Releases, Prev: Data Files Support, Up: Transition to PEP517 + +1.1.6 “Development Mode” +------------------------ + +Under normal circumstances, the ‘distutils’ assume that you are going to +build a distribution of your project, not use it in its “raw” or +“unbuilt” form. If you were to use the ‘distutils’ that way, you would +have to rebuild and reinstall your project every time you made a change +to it during development. + +Another problem that sometimes comes up with the ‘distutils’ is that you +may need to do development on two related projects at the same time. +You may need to put both projects’ packages in the same directory to run +them, but need to keep them separate for revision control purposes. How +can you do this? + +Setuptools allows you to deploy your projects for use in a common +directory or staging area, but without copying any files. Thus, you can +edit each project’s code in its checkout directory, and only need to run +build commands when you change a project’s C extensions or similarly +compiled files. You can even deploy a project into another project’s +checkout directory, if that’s your preferred way of working (as opposed +to using a common independent staging area or the site-packages +directory). + +To do this, use the ‘setup.py develop’ command. It works very similarly +to ‘setup.py install’, except that it doesn’t actually install anything. +Instead, it creates a special ‘.egg-link’ file in the deployment +directory, that links to your project’s source code. And, if your +deployment directory is Python’s ‘site-packages’ directory, it will also +update the ‘easy-install.pth’ file to include your project’s source +code, thereby making it available on ‘sys.path’ for all programs using +that Python installation. + +If you have enabled the ‘use_2to3’ flag, then of course the ‘.egg-link’ +will not link directly to your source code when run under Python 3, +since that source code would be made for Python 2 and not work under +Python 3. Instead the ‘setup.py develop’ will build Python 3 code under +the ‘build’ directory, and link there. This means that after doing code +changes you will have to run ‘setup.py build’ before these changes are +picked up by your Python 3 installation. + +In addition, the ‘develop’ command creates wrapper scripts in the target +script directory that will run your in-development scripts after +ensuring that all your ‘install_requires’ packages are available on +‘sys.path’. + +You can deploy the same project to multiple staging areas, e.g. if you +have multiple projects on the same machine that are sharing the same +project you’re doing development work. + +When you’re done with a given development task, you can remove the +project source from a staging area using ‘setup.py develop --uninstall’, +specifying the desired staging area if it’s not the default. + +There are several options to control the precise behavior of the +‘develop’ command; see the section on the *note develop: 3a. command +below for more details. + +Note that you can also apply setuptools commands to non-setuptools +projects, using commands like this: + + python -c "import setuptools; with open('setup.py') as f: exec(compile(f.read(), 'setup.py', 'exec'))" develop + +That is, you can simply list the normal setup commands and options +following the quoted part. + + +File: setuptools.info, Node: Tagging and “Daily Build” or “Snapshot” Releases, Next: Generating Source Distributions, Prev: “Development Mode”, Up: Transition to PEP517 + +1.1.7 Tagging and “Daily Build” or “Snapshot” Releases +------------------------------------------------------ + +When a set of related projects are under development, it may be +important to track finer-grained version increments than you would +normally use for e.g. “stable” releases. While stable releases might +be measured in dotted numbers with alpha/beta/etc. status codes, +development versions of a project often need to be tracked by revision +or build number or even build date. This is especially true when +projects in development need to refer to one another, and therefore may +literally need an up-to-the-minute version of something! + +To support these scenarios, ‘setuptools’ allows you to “tag” your source +and egg distributions by adding one or more of the following to the +project’s “official” version identifier: + + * A manually-specified pre-release tag, such as “build” or “dev”, or + a manually-specified post-release tag, such as a build or revision + number (‘--tag-build=STRING, -bSTRING’) + + * An 8-character representation of the build date (‘--tag-date, -d’), + as a postrelease tag + +You can add these tags by adding ‘egg_info’ and the desired options to +the command line ahead of the ‘sdist’ or ‘bdist’ commands that you want +to generate a daily build or snapshot for. See the section below on the +*note egg_info: 3d. command for more details. + +(Also, before you release your project, be sure to see the section above +on *note Specifying Your Project’s Version: 3e. for more information +about how pre- and post-release tags affect how version numbers are +interpreted. This is important in order to make sure that dependency +processing tools will know which versions of your project are newer than +others.) + +Finally, if you are creating builds frequently, and either building them +in a downloadable location or are copying them to a distribution server, +you should probably also check out the *note rotate: 3f. command, which +lets you automatically delete all but the N most-recently-modified +distributions matching a glob pattern. So, you can use a command line +like: + + setup.py egg_info -rbDEV bdist_egg rotate -m.egg -k3 + +to build an egg whose version info includes “DEV-rNNNN” (where NNNN is +the most recent Subversion revision that affected the source tree), and +then delete any egg files from the distribution directory except for the +three that were built most recently. + +If you have to manage automated builds for multiple packages, each with +different tagging and rotation policies, you may also want to check out +the *note alias: 40. command, which would let each package define an +alias like ‘daily’ that would perform the necessary tag, build, and +rotate commands. Then, a simpler script or cron job could just run +‘setup.py daily’ in each project directory. (And, you could also define +sitewide or per-user default versions of the ‘daily’ alias, so that +projects that didn’t define their own would use the appropriate +defaults.) + + +File: setuptools.info, Node: Generating Source Distributions, Next: Distributing Extensions compiled with Cython, Prev: Tagging and “Daily Build” or “Snapshot” Releases, Up: Transition to PEP517 + +1.1.8 Generating Source Distributions +------------------------------------- + +‘setuptools’ enhances the distutils’ default algorithm for source file +selection with pluggable endpoints for looking up files to include. If +you are using a revision control system, and your source distributions +only need to include files that you’re tracking in revision control, use +a corresponding plugin instead of writing a ‘MANIFEST.in’ file. See the +section below on *note Adding Support for Revision Control Systems: 32. +for information on plugins. + +If you need to include automatically generated files, or files that are +kept in an unsupported revision control system, you’ll need to create a +‘MANIFEST.in’ file to specify any files that the default file location +algorithm doesn’t catch. See the distutils documentation for more +information on the format of the ‘MANIFEST.in’ file. + +But, be sure to ignore any part of the distutils documentation that +deals with ‘MANIFEST’ or how it’s generated from ‘MANIFEST.in’; +setuptools shields you from these issues and doesn’t work the same way +in any case. Unlike the distutils, setuptools regenerates the source +distribution manifest file every time you build a source distribution, +and it builds it inside the project’s ‘.egg-info’ directory, out of the +way of your main project directory. You therefore need not worry about +whether it is up-to-date or not. + +Indeed, because setuptools’ approach to determining the contents of a +source distribution is so much simpler, its ‘sdist’ command omits nearly +all of the options that the distutils’ more complex ‘sdist’ process +requires. For all practical purposes, you’ll probably use only the +‘--formats’ option, if you use any option at all. + +* Menu: + +* Making “Official” (Non-Snapshot) Releases: Making “Official” Non-Snapshot Releases. + + +File: setuptools.info, Node: Making “Official” Non-Snapshot Releases, Up: Generating Source Distributions + +1.1.8.1 Making “Official” (Non-Snapshot) Releases +................................................. + +When you make an official release, creating source or binary +distributions, you will need to override the tag settings from +‘setup.cfg’, so that you don’t end up registering versions like +‘foobar-0.7a1.dev-r34832’. This is easy to do if you are developing on +the trunk and using tags or branches for your releases - just make the +change to ‘setup.cfg’ after branching or tagging the release, so the +trunk will still produce development snapshots. + +Alternately, if you are not branching for releases, you can override the +default version options on the command line, using something like: + + setup.py egg_info -Db "" sdist bdist_egg + +The first part of this command (‘egg_info -Db ""’) will override the +configured tag information, before creating source and binary eggs. +Thus, these commands will use the plain version from your ‘setup.py’, +without adding the build designation string. + +Of course, if you will be doing this a lot, you may wish to create a +personal alias for this operation, e.g.: + + setup.py alias -u release egg_info -Db "" + +You can then use it like this: + + setup.py release sdist bdist_egg + +Or of course you can create more elaborate aliases that do all of the +above. See the sections below on the *note egg_info: 3d. and *note +alias: 40. commands for more ideas. + + +File: setuptools.info, Node: Distributing Extensions compiled with Cython, Next: Specifying Your Project’s Version, Prev: Generating Source Distributions, Up: Transition to PEP517 + +1.1.9 Distributing Extensions compiled with Cython +-------------------------------------------------- + +‘setuptools’ will detect at build time whether Cython is installed or +not. If Cython is not found ‘setuptools’ will ignore pyx files. + +To ensure Cython is available, include Cython in the build-requires +section of your pyproject.toml: + + [build-system] + requires=[..., "cython"] + +Built with pip 10 or later, that declaration is sufficient to include +Cython in the build. For broader compatibility, declare the dependency +in your setup-requires of setup.cfg: + + [options] + setup_requires = + ... + cython + +As long as Cython is present in the build environment, ‘setuptools’ +includes transparent support for building Cython extensions, as long as +extensions are defined using ‘setuptools.Extension’. + +If you follow these rules, you can safely list ‘.pyx’ files as the +source of your ‘Extension’ objects in the setup script. If it is, then +‘setuptools’ will use it. + +Of course, for this to work, your source distributions must include the +C code generated by Cython, as well as your original ‘.pyx’ files. This +means that you will probably want to include current ‘.c’ files in your +revision control system, rebuilding them whenever you check changes in +for the ‘.pyx’ source files. This will ensure that people tracking your +project in a revision control system will be able to build it even if +they don’t have Cython installed, and that your source releases will be +similarly usable with or without Cython. + + +File: setuptools.info, Node: Specifying Your Project’s Version, Next: Creating distutils Extensions, Prev: Distributing Extensions compiled with Cython, Up: Transition to PEP517 + +1.1.10 Specifying Your Project’s Version +---------------------------------------- + +Setuptools can work well with most versioning schemes; there are, +however, a few special things to watch out for, in order to ensure that +setuptools and other tools can always tell what version of your package +is newer than another version. Knowing these things will also help you +correctly specify what versions of other projects your project depends +on. + +A version consists of an alternating series of release numbers and +pre-release or post-release tags. A release number is a series of +digits punctuated by dots, such as ‘2.4’ or ‘0.5’. Each series of +digits is treated numerically, so releases ‘2.1’ and ‘2.1.0’ are +different ways to spell the same release number, denoting the first +subrelease of release 2. But ‘2.10’ is the `tenth' subrelease of +release 2, and so is a different and newer release from ‘2.1’ or +‘2.1.0’. Leading zeros within a series of digits are also ignored, so +‘2.01’ is the same as ‘2.1’, and different from ‘2.0.1’. + +Following a release number, you can have either a pre-release or +post-release tag. Pre-release tags make a version be considered `older' +than the version they are appended to. So, revision ‘2.4’ is `newer' +than revision ‘2.4c1’, which in turn is newer than ‘2.4b1’ or ‘2.4a1’. +Postrelease tags make a version be considered `newer' than the version +they are appended to. So, revisions like ‘2.4-1’ and ‘2.4pl3’ are newer +than ‘2.4’, but are `older' than ‘2.4.1’ (which has a higher release +number). + +A pre-release tag is a series of letters that are alphabetically before +“final”. Some examples of prerelease tags would include ‘alpha’, +‘beta’, ‘a’, ‘c’, ‘dev’, and so on. You do not have to place a dot or +dash before the prerelease tag if it’s immediately after a number, but +it’s okay to do so if you prefer. Thus, ‘2.4c1’ and ‘2.4.c1’ and +‘2.4-c1’ all represent release candidate 1 of version ‘2.4’, and are +treated as identical by setuptools. + +In addition, there are three special prerelease tags that are treated as +if they were the letter ‘c’: ‘pre’, ‘preview’, and ‘rc’. So, version +‘2.4rc1’, ‘2.4pre1’ and ‘2.4preview1’ are all the exact same version as +‘2.4c1’, and are treated as identical by setuptools. + +A post-release tag is either a series of letters that are alphabetically +greater than or equal to “final”, or a dash (‘-’). Post-release tags +are generally used to separate patch numbers, port numbers, build +numbers, revision numbers, or date stamps from the release number. For +example, the version ‘2.4-r1263’ might denote Subversion revision 1263 +of a post-release patch of version ‘2.4’. Or you might use +‘2.4-20051127’ to denote a date-stamped post-release. + +Notice that after each pre or post-release tag, you are free to place +another release number, followed again by more pre- or post-release +tags. For example, ‘0.6a9.dev-r41475’ could denote Subversion revision +41475 of the in- development version of the ninth alpha of release 0.6. +Notice that ‘dev’ is a pre-release tag, so this version is a `lower' +version number than ‘0.6a9’, which would be the actual ninth alpha of +release 0.6. But the ‘-r41475’ is a post-release tag, so this version +is `newer' than ‘0.6a9.dev’. + +For the most part, setuptools’ interpretation of version numbers is +intuitive, but here are a few tips that will keep you out of trouble in +the corner cases: + + * Don’t stick adjoining pre-release tags together without a dot or + number between them. Version ‘1.9adev’ is the ‘adev’ prerelease of + ‘1.9’, `not' a development pre-release of ‘1.9a’. Use ‘.dev’ + instead, as in ‘1.9a.dev’, or separate the prerelease tags with a + number, as in ‘1.9a0dev’. ‘1.9a.dev’, ‘1.9a0dev’, and even + ‘1.9.a.dev’ are identical versions from setuptools’ point of view, + so you can use whatever scheme you prefer. + + * If you want to be certain that your chosen numbering scheme works + the way you think it will, you can use the + ‘pkg_resources.parse_version()’ function to compare different + version numbers: + + >>> from pkg_resources import parse_version + >>> parse_version("1.9.a.dev") == parse_version("1.9a0dev") + True + >>> parse_version("2.1-rc2") < parse_version("2.1") + True + >>> parse_version("0.6a9dev-r41475") < parse_version("0.6a9") + True + +Once you’ve decided on a version numbering scheme for your project, you +can have setuptools automatically tag your in-development releases with +various pre- or post-release tags. See the following sections for more +details: + + * *note Tagging and "Daily Build" or "Snapshot" Releases: 3c. + + * The *note egg_info: 3d. command + + +File: setuptools.info, Node: Creating distutils Extensions, Next: Configuring setup using setup cfg files, Prev: Specifying Your Project’s Version, Up: Transition to PEP517 + +1.1.11 Creating ‘distutils’ Extensions +-------------------------------------- + +It can be hard to add new commands or setup arguments to the distutils. +But the ‘setuptools’ package makes it a bit easier, by allowing you to +distribute a distutils extension as a separate project, and then have +projects that need the extension just refer to it in their +‘setup_requires’ argument. + +With ‘setuptools’, your distutils extension projects can hook in new +commands and ‘setup()’ arguments just by defining “entry points”. These +are mappings from command or argument names to a specification of where +to import a handler from. (See the section on *note Advertising +Behavior: 25. above for some more background on entry points.) + +* Menu: + +* Adding Commands:: +* Adding setup() Arguments: Adding setup Arguments. +* Customizing Distribution Options:: +* Adding new EGG-INFO Files:: +* Adding Support for Revision Control Systems:: + + +File: setuptools.info, Node: Adding Commands, Next: Adding setup Arguments, Up: Creating distutils Extensions + +1.1.11.1 Adding Commands +........................ + +You can add new ‘setup’ commands by defining entry points in the +‘distutils.commands’ group. For example, if you wanted to add a ‘foo’ +command, you might add something like this to your distutils extension +project’s setup script: + + setup( + # ... + entry_points={ + "distutils.commands": [ + "foo = mypackage.some_module:foo", + ], + }, + ) + +(Assuming, of course, that the ‘foo’ class in ‘mypackage.some_module’ is +a ‘setuptools.Command’ subclass.) + +Once a project containing such entry points has been activated on +‘sys.path’, (e.g. by running “install” or “develop” with a +site-packages installation directory) the command(s) will be available +to any ‘setuptools’-based setup scripts. It is not necessary to use the +‘--command-packages’ option or to monkeypatch the ‘distutils.command’ +package to install your commands; ‘setuptools’ automatically adds a +wrapper to the distutils to search for entry points in the active +distributions on ‘sys.path’. In fact, this is how setuptools’ own +commands are installed: the setuptools project’s setup script defines +entry points for them! + + +File: setuptools.info, Node: Adding setup Arguments, Next: Customizing Distribution Options, Prev: Adding Commands, Up: Creating distutils Extensions + +1.1.11.2 Adding ‘setup()’ Arguments +................................... + + Warning: Adding arguments to setup is discouraged as such arguments + are only supported through imperative execution and not supported + through declarative config. + +Sometimes, your commands may need additional arguments to the ‘setup()’ +call. You can enable this by defining entry points in the +‘distutils.setup_keywords’ group. For example, if you wanted a +‘setup()’ argument called ‘bar_baz’, you might add something like this +to your distutils extension project’s setup script: + + setup( + # ... + entry_points={ + "distutils.commands": [ + "foo = mypackage.some_module:foo", + ], + "distutils.setup_keywords": [ + "bar_baz = mypackage.some_module:validate_bar_baz", + ], + }, + ) + +The idea here is that the entry point defines a function that will be +called to validate the ‘setup()’ argument, if it’s supplied. The +‘Distribution’ object will have the initial value of the attribute set +to ‘None’, and the validation function will only be called if the +‘setup()’ call sets it to a non-None value. Here’s an example +validation function: + + def assert_bool(dist, attr, value): + """Verify that value is True, False, 0, or 1""" + if bool(value) != value: + raise DistutilsSetupError( + "%r must be a boolean value (got %r)" % (attr,value) + ) + +Your function should accept three arguments: the ‘Distribution’ object, +the attribute name, and the attribute value. It should raise a +‘DistutilsSetupError’ (from the ‘distutils.errors’ module) if the +argument is invalid. Remember, your function will only be called with +non-None values, and the default value of arguments defined this way is +always None. So, your commands should always be prepared for the +possibility that the attribute will be ‘None’ when they access it later. + +If more than one active distribution defines an entry point for the same +‘setup()’ argument, `all' of them will be called. This allows multiple +distutils extensions to define a common argument, as long as they agree +on what values of that argument are valid. + +Also note that as with commands, it is not necessary to subclass or +monkeypatch the distutils ‘Distribution’ class in order to add your +arguments; it is sufficient to define the entry points in your +extension, as long as any setup script using your extension lists your +project in its ‘setup_requires’ argument. + + +File: setuptools.info, Node: Customizing Distribution Options, Next: Adding new EGG-INFO Files, Prev: Adding setup Arguments, Up: Creating distutils Extensions + +1.1.11.3 Customizing Distribution Options +......................................... + +Plugins may wish to extend or alter the options on a Distribution object +to suit the purposes of that project. For example, a tool that infers +the ‘Distribution.version’ from SCM-metadata may need to hook into the +option finalization. To enable this feature, Setuptools offers an entry +point “setuptools.finalize_distribution_options”. That entry point must +be a callable taking one argument (the Distribution instance). + +If the callable has an ‘.order’ property, that value will be used to +determine the order in which the hook is called. Lower numbers are +called first and the default is zero (0). + +Plugins may read, alter, and set properties on the distribution, but +each plugin is encouraged to load the configuration/settings for their +behavior independently. + + +File: setuptools.info, Node: Adding new EGG-INFO Files, Next: Adding Support for Revision Control Systems, Prev: Customizing Distribution Options, Up: Creating distutils Extensions + +1.1.11.4 Adding new EGG-INFO Files +.................................. + +Some extensible applications or frameworks may want to allow third +parties to develop plugins with application or framework-specific +metadata included in the plugins’ EGG-INFO directory, for easy access +via the ‘pkg_resources’ metadata API. The easiest way to allow this is +to create a distutils extension to be used from the plugin projects’ +setup scripts (via ‘setup_requires’) that defines a new setup keyword, +and then uses that data to write an EGG-INFO file when the ‘egg_info’ +command is run. + +The ‘egg_info’ command looks for extension points in an +‘egg_info.writers’ group, and calls them to write the files. Here’s a +simple example of a distutils extension defining a setup argument +‘foo_bar’, which is a list of lines that will be written to +‘foo_bar.txt’ in the EGG-INFO directory of any project that uses the +argument: + + setup( + # ... + entry_points={ + "distutils.setup_keywords": [ + "foo_bar = setuptools.dist:assert_string_list", + ], + "egg_info.writers": [ + "foo_bar.txt = setuptools.command.egg_info:write_arg", + ], + }, + ) + +This simple example makes use of two utility functions defined by +setuptools for its own use: a routine to validate that a setup keyword +is a sequence of strings, and another one that looks up a setup argument +and writes it to a file. Here’s what the writer utility looks like: + + def write_arg(cmd, basename, filename): + argname = os.path.splitext(basename)[0] + value = getattr(cmd.distribution, argname, None) + if value is not None: + value = "\n".join(value) + "\n" + cmd.write_or_delete_file(argname, filename, value) + +As you can see, ‘egg_info.writers’ entry points must be a function +taking three arguments: a ‘egg_info’ command instance, the basename of +the file to write (e.g. ‘foo_bar.txt’), and the actual full filename +that should be written to. + +In general, writer functions should honor the command object’s ‘dry_run’ +setting when writing files, and use the ‘distutils.log’ object to do any +console output. The easiest way to conform to this requirement is to +use the ‘cmd’ object’s ‘write_file()’, ‘delete_file()’, and +‘write_or_delete_file()’ methods exclusively for your file operations. +See those methods’ docstrings for more details. + + +File: setuptools.info, Node: Adding Support for Revision Control Systems, Prev: Adding new EGG-INFO Files, Up: Creating distutils Extensions + +1.1.11.5 Adding Support for Revision Control Systems +.................................................... + +If the files you want to include in the source distribution are tracked +using Git, Mercurial or SVN, you can use the following packages to +achieve that: + + - Git and Mercurial: setuptools_scm(1) + + - SVN: setuptools_svn(2) + +If you would like to create a plugin for ‘setuptools’ to find files +tracked by another revision control system, you can do so by adding an +entry point to the ‘setuptools.file_finders’ group. The entry point +should be a function accepting a single directory name, and should yield +all the filenames within that directory (and any subdirectories thereof) +that are under revision control. + +For example, if you were going to create a plugin for a revision control +system called “foobar”, you would write a function something like this: + + def find_files_for_foobar(dirname): + # loop to yield paths that start with `dirname` + +And you would register it in a setup script using something like this: + + entry_points={ + "setuptools.file_finders": [ + "foobar = my_foobar_module:find_files_for_foobar", + ] + } + +Then, anyone who wants to use your plugin can simply install it, and +their local setuptools installation will be able to find the necessary +files. + +It is not necessary to distribute source control plugins with projects +that simply use the other source control system, or to specify the +plugins in ‘setup_requires’. When you create a source distribution with +the ‘sdist’ command, setuptools automatically records what files were +found in the ‘SOURCES.txt’ file. That way, recipients of source +distributions don’t need to have revision control at all. However, if +someone is working on a package by checking out with that system, they +will need the same plugin(s) that the original author is using. + +A few important points for writing revision control file finders: + + * Your finder function MUST return relative paths, created by + appending to the passed-in directory name. Absolute paths are NOT + allowed, nor are relative paths that reference a parent directory + of the passed-in directory. + + * Your finder function MUST accept an empty string as the directory + name, meaning the current directory. You MUST NOT convert this to + a dot; just yield relative paths. So, yielding a subdirectory + named ‘some/dir’ under the current directory should NOT be rendered + as ‘./some/dir’ or ‘/somewhere/some/dir’, but `always' as simply + ‘some/dir’ + + * Your finder function SHOULD NOT raise any errors, and SHOULD deal + gracefully with the absence of needed programs (i.e., ones + belonging to the revision control system itself. It `may', + however, use ‘distutils.log.warn()’ to inform the user of the + missing program(s). + + ---------- Footnotes ---------- + + (1) https://pypi.org/project/setuptools_scm/ + + (2) https://pypi.org/project/setuptools_svn/ + + +File: setuptools.info, Node: Configuring setup using setup cfg files, Next: New and Changed setup Keywords, Prev: Creating distutils Extensions, Up: Transition to PEP517 + +1.1.12 Configuring setup() using setup.cfg files +------------------------------------------------ + + Note: New in 30.3.0 (8 Dec 2016). + + Important: If compatibility with legacy builds (i.e. those not + using the PEP 517(1) build API) is desired, a ‘setup.py’ file + containing a ‘setup()’ function call is still required even if your + configuration resides in ‘setup.cfg’. + +‘Setuptools’ allows using configuration files (usually ‘setup.cfg’) to +define a package’s metadata and other options that are normally supplied +to the ‘setup()’ function (declarative config). + +This approach not only allows automation scenarios but also reduces +boilerplate code in some cases. + + Note: This implementation has limited compatibility with the + distutils2-like ‘setup.cfg’ sections used by the ‘pbr’ and ‘d2to1’ + packages. + + Namely: only metadata-related keys from ‘metadata’ section are + supported (except for ‘description-file’); keys from ‘files’, + ‘entry_points’ and ‘backwards_compat’ are not supported. + + [metadata] + name = my_package + version = attr: src.VERSION + description = My package description + long_description = file: README.rst, CHANGELOG.rst, LICENSE.rst + keywords = one, two + license = BSD 3-Clause License + classifiers = + Framework :: Django + License :: OSI Approved :: BSD License + Programming Language :: Python :: 3 + Programming Language :: Python :: 3.5 + + [options] + zip_safe = False + include_package_data = True + packages = find: + scripts = + bin/first.py + bin/second.py + install_requires = + requests + importlib; python_version == "2.6" + + [options.package_data] + * = *.txt, *.rst + hello = *.msg + + [options.extras_require] + pdf = ReportLab>=1.2; RXP + rest = docutils>=0.3; pack ==1.1, ==1.3 + + [options.packages.find] + exclude = + src.subpackage1 + src.subpackage2 + + [options.data_files] + /etc/my_package = + site.d/00_default.conf + host.d/00_default.conf + data = data/img/logo.png, data/svg/icon.svg + +Metadata and options are set in the config sections of the same name. + + * Keys are the same as the keyword arguments one provides to the + ‘setup()’ function. + + * Complex values can be written comma-separated or placed one per + line in `dangling' config values. The following are equivalent: + + [metadata] + keywords = one, two + + [metadata] + keywords = + one + two + + * In some cases, complex values can be provided in dedicated + subsections for clarity. + + * Some keys allow ‘file:’, ‘attr:’, ‘find:’, and ‘find_namespace:’ + directives in order to cover common usecases. + + * Unknown keys are ignored. + +* Menu: + +* Using a src/ layout:: +* Specifying values:: + + ---------- Footnotes ---------- + + (1) https://www.python.org/dev/peps/pep-0517 + + +File: setuptools.info, Node: Using a src/ layout, Next: Specifying values, Up: Configuring setup using setup cfg files + +1.1.12.1 Using a ‘src/’ layout +.............................. + +One commonly used package configuration has all the module source code +in a subdirectory (often called the ‘src/’ layout), like this: + + ├── src + │ └── mypackage + │ ├── __init__.py + │ └── mod1.py + ├── setup.py + └── setup.cfg + +You can set up your ‘setup.cfg’ to automatically find all your packages +in the subdirectory like this: + + # This example contains just the necessary options for a src-layout, set up + # the rest of the file as described above. + + [options] + package_dir= + =src + packages=find: + + [options.packages.find] + where=src + + +File: setuptools.info, Node: Specifying values, Prev: Using a src/ layout, Up: Configuring setup using setup cfg files + +1.1.12.2 Specifying values +.......................... + +Some values are treated as simple strings, some allow more logic. + +Type names used below: + + * ‘str’ - simple string + + * ‘list-comma’ - dangling list or string of comma-separated values + + * ‘list-semi’ - dangling list or string of semicolon-separated values + + * ‘bool’ - ‘True’ is 1, yes, true + + * ‘dict’ - list-comma where keys are separated from values by ‘=’ + + * ‘section’ - values are read from a dedicated (sub)section + +Special directives: + + * ‘attr:’ - Value is read from a module attribute. ‘attr:’ supports + callables and iterables; unsupported types are cast using ‘str()’. + + In order to support the common case of a literal value assigned to + a variable in a module containing (directly or indirectly) + third-party imports, ‘attr:’ first tries to read the value from the + module by examining the module’s AST. If that fails, ‘attr:’ falls + back to importing the module. + + * ‘file:’ - Value is read from a list of files and then concatenated + + Note: The ‘file:’ directive is sandboxed and won’t reach anything + outside the directory containing ‘setup.py’. + +* Menu: + +* Metadata:: +* Options:: + + +File: setuptools.info, Node: Metadata, Next: Options, Up: Specifying values + +1.1.12.3 Metadata +................. + + Note: The aliases given below are supported for compatibility + reasons, but their use is not advised. + +Key Aliases Type Minimum Version Notes + +------------------------------------------------------------------------------------------------------------- + +name str + + +version attr:, file:, str 39.2.0 1. + + +url home-page str + + +download_url download-url str + + +project_urls dict 38.3.0 + + +author str + + +author_email author-email str + + +maintainer str + + +maintainer_email maintainer-email str + + +classifiers classifier file:, list-comma + + +license str + + +license_file str + + +license_files list-comma + + +description summary file:, str + + +long_description long-description file:, str + + +long_description_content_type str 38.6.0 + + +keywords list-comma + + +platforms platform list-comma + + +provides list-comma + + +requires list-comma + + +obsoletes list-comma + + + Note: A version loaded using the ‘file:’ directive must comply with + PEP 440. It is easy to accidentally put something other than a + valid version string in such a file, so validation is stricter in + this case. + +Notes: 1. The ‘version’ file attribute has only been supported since +39.2.0. + + +File: setuptools.info, Node: Options, Prev: Metadata, Up: Specifying values + +1.1.12.4 Options +................ + +Key Type Minimum Version Notes + +-------------------------------------------------------------------------------------------------- + +zip_safe bool + + +setup_requires list-semi + + +install_requires list-semi + + +extras_require section + + +python_requires str + + +entry_points file:, section + + +use_2to3 bool + + +use_2to3_fixers list-comma + + +use_2to3_exclude_fixers list-comma + + +convert_2to3_doctests list-comma + + +scripts list-comma + + +eager_resources list-comma + + +dependency_links list-comma + + +tests_require list-semi + + +include_package_data bool + + +packages find:, find_namespace:, list-comma + + +package_dir dict + + +package_data section 1. + + +exclude_package_data section + + +namespace_packages list-comma + + +py_modules list-comma + + +data_files dict 40.6.0 + + + Note: `packages' - The ‘find:’ and ‘find_namespace:’ directive can + be further configured in a dedicated subsection + ‘options.packages.find’. This subsection accepts the same keys as + the ‘setuptools.find_packages’ and the + ‘setuptools.find_namespace_packages’ function: ‘where’, ‘include’, + and ‘exclude’. + + `find_namespace directive' - The ‘find_namespace:’ directive is + supported since Python >=3.3. + +Notes: 1. In the ‘package_data’ section, a key named with a single +asterisk (‘*’) refers to all packages, in lieu of the empty string used +in ‘setup.py’. + + +File: setuptools.info, Node: New and Changed setup Keywords, Next: Command Reference, Prev: Configuring setup using setup cfg files, Up: Transition to PEP517 + +1.1.13 New and Changed ‘setup()’ Keywords +----------------------------------------- + +The following keyword arguments to ‘setup()’ are added or changed by +‘setuptools’. All of them are optional; you do not have to supply them +unless you need the associated ‘setuptools’ feature. + +‘include_package_data’ + + If set to ‘True’, this tells ‘setuptools’ to automatically include + any data files it finds inside your package directories that are + specified by your ‘MANIFEST.in’ file. For more information, see + the section on *note Including Data Files: 12. + +‘exclude_package_data’ + + A dictionary mapping package names to lists of glob patterns that + should be `excluded' from your package directories. You can use + this to trim back any excess files included by + ‘include_package_data’. For a complete description and examples, + see the section on *note Including Data Files: 12. + +‘package_data’ + + A dictionary mapping package names to lists of glob patterns. For + a complete description and examples, see the section on *note + Including Data Files: 12. You do not need to use this option if + you are using ‘include_package_data’, unless you need to add e.g. + files that are generated by your setup script and build process. + (And are therefore not in source control or are files that you + don’t want to include in your source distribution.) + +‘zip_safe’ + + A boolean (True or False) flag specifying whether the project can + be safely installed and run from a zip file. If this argument is + not supplied, the ‘bdist_egg’ command will have to analyze all of + your project’s contents for possible problems each time it builds + an egg. + +‘install_requires’ + + A string or list of strings specifying what other distributions + need to be installed when this one is. See the section on *note + Declaring required dependency: 2b. for details and examples of the + format of this argument. + +‘entry_points’ + + A dictionary mapping entry point group names to strings or lists of + strings defining the entry points. Entry points are used to + support dynamic discovery of services or plugins provided by a + project. See *note Advertising Behavior: 25. for details and + examples of the format of this argument. In addition, this keyword + is used to support *note Automatic Script Creation: 21. + +‘extras_require’ + + A dictionary mapping names of “extras” (optional features of your + project) to strings or lists of strings specifying what other + distributions must be installed to support those features. See the + section on *note Declaring required dependency: 2b. for details and + examples of the format of this argument. + +‘python_requires’ + + A string corresponding to a version specifier (as defined in PEP + 440) for the Python version, used to specify the Requires-Python + defined in PEP 345. + +‘setup_requires’ + + A string or list of strings specifying what other distributions + need to be present in order for the `setup script' to run. + ‘setuptools’ will attempt to obtain these (using pip if available) + before processing the rest of the setup script or commands. This + argument is needed if you are using distutils extensions as part of + your build process; for example, extensions that process setup() + arguments and turn them into EGG-INFO metadata files. + + (Note: projects listed in ‘setup_requires’ will NOT be + automatically installed on the system where the setup script is + being run. They are simply downloaded to the ./.eggs directory if + they’re not locally available already. If you want them to be + installed, as well as being available when the setup script is run, + you should add them to ‘install_requires’ `and' ‘setup_requires’.) + +‘dependency_links’ + + A list of strings naming URLs to be searched when satisfying + dependencies. These links will be used if needed to install + packages specified by ‘setup_requires’ or ‘tests_require’. They + will also be written into the egg’s metadata for use during install + by tools that support them. + +‘namespace_packages’ + + A list of strings naming the project’s “namespace packages”. A + namespace package is a package that may be split across multiple + project distributions. For example, Zope 3’s ‘zope’ package is a + namespace package, because subpackages like ‘zope.interface’ and + ‘zope.publisher’ may be distributed separately. The egg runtime + system can automatically merge such subpackages into a single + parent package at runtime, as long as you declare them in each + project that contains any subpackages of the namespace package, and + as long as the namespace package’s ‘__init__.py’ does not contain + any code other than a namespace declaration. See the section below + on *note Using find_namespace; or find_namespace_packages: 1c. for + more information. + +‘test_suite’ + + A string naming a ‘unittest.TestCase’ subclass (or a package or + module containing one or more of them, or a method of such a + subclass), or naming a function that can be called with no + arguments and returns a ‘unittest.TestSuite’. If the named suite + is a module, and the module has an ‘additional_tests()’ function, + it is called and the results are added to the tests to be run. If + the named suite is a package, any submodules and subpackages are + recursively added to the overall test suite. + + Specifying this argument enables use of the *note test: 56. command + to run the specified test suite, e.g. via ‘setup.py test’. See + the section on the *note test: 56. command below for more details. + + New in 41.5.0: Deprecated the test command. + +‘tests_require’ + + If your project’s tests need one or more additional packages + besides those needed to install it, you can use this option to + specify them. It should be a string or list of strings specifying + what other distributions need to be present for the package’s tests + to run. When you run the ‘test’ command, ‘setuptools’ will attempt + to obtain these (using pip if available). Note that these required + projects will `not' be installed on the system where the tests are + run, but only downloaded to the project’s setup directory if + they’re not already installed locally. + + New in 41.5.0: Deprecated the test command. + +‘test_loader’ + + If you would like to use a different way of finding tests to run + than what setuptools normally uses, you can specify a module name + and class name in this argument. The named class must be + instantiable with no arguments, and its instances must support the + ‘loadTestsFromNames()’ method as defined in the Python ‘unittest’ + module’s ‘TestLoader’ class. Setuptools will pass only one test + “name” in the ‘names’ argument: the value supplied for the + ‘test_suite’ argument. The loader you specify may interpret this + string in any way it likes, as there are no restrictions on what + may be contained in a ‘test_suite’ string. + + The module name and class name must be separated by a ‘:’. The + default value of this argument is + ‘"setuptools.command.test:ScanningLoader"’. If you want to use the + default ‘unittest’ behavior, you can specify + ‘"unittest:TestLoader"’ as your ‘test_loader’ argument instead. + This will prevent automatic scanning of submodules and subpackages. + + The module and class you specify here may be contained in another + package, as long as you use the ‘tests_require’ option to ensure + that the package containing the loader class is available when the + ‘test’ command is run. + + New in 41.5.0: Deprecated the test command. + +‘eager_resources’ + + A list of strings naming resources that should be extracted + together, if any of them is needed, or if any C extensions included + in the project are imported. This argument is only useful if the + project will be installed as a zipfile, and there is a need to have + all of the listed resources be extracted to the filesystem `as a + unit'. Resources listed here should be “/”-separated paths, + relative to the source root, so to list a resource ‘foo.png’ in + package ‘bar.baz’, you would include the string ‘bar/baz/foo.png’ + in this argument. + + If you only need to obtain resources one at a time, or you don’t + have any C extensions that access other files in the project (such + as data files or shared libraries), you probably do NOT need this + argument and shouldn’t mess with it. For more details on how this + argument works, see the section below on *note Automatic Resource + Extraction: 58. + +‘use_2to3’ + + Convert the source code from Python 2 to Python 3 with 2to3 during + the build process. See *note Supporting both Python 2 and Python 3 + with Setuptools: 59. for more details. + +‘convert_2to3_doctests’ + + List of doctest source files that need to be converted with 2to3. + See *note Supporting both Python 2 and Python 3 with Setuptools: + 59. for more details. + +‘use_2to3_fixers’ + + A list of modules to search for additional fixers to be used during + the 2to3 conversion. See *note Supporting both Python 2 and Python + 3 with Setuptools: 59. for more details. + +‘project_urls’ + + An arbitrary map of URL names to hyperlinks, allowing more + extensible documentation of where various resources can be found + than the simple ‘url’ and ‘download_url’ options provide. + + +File: setuptools.info, Node: Command Reference, Next: Using setuptools to package and distribute your project, Prev: New and Changed setup Keywords, Up: Transition to PEP517 + +1.1.14 Command Reference +------------------------ + +* Menu: + +* alias - Define shortcuts for commonly used commands:: +* bdist_egg - Create a Python Egg for the project:: +* develop - Deploy the project source in “Development Mode”:: +* egg_info - Create egg metadata and set build tags:: +* rotate - Delete outdated distribution files:: +* saveopts - Save used options to a configuration file:: +* setopt - Set a distutils or setuptools option in a config file:: +* test - Build package and run a unittest suite:: +* upload - Upload source and/or egg distributions to PyPI:: + + +File: setuptools.info, Node: alias - Define shortcuts for commonly used commands, Next: bdist_egg - Create a Python Egg for the project, Up: Command Reference + +1.1.14.1 ‘alias’ - Define shortcuts for commonly used commands +.............................................................. + +Sometimes, you need to use the same commands over and over, but you +can’t necessarily set them as defaults. For example, if you produce +both development snapshot releases and “stable” releases of a project, +you may want to put the distributions in different places, or use +different ‘egg_info’ tagging options, etc. In these cases, it doesn’t +make sense to set the options in a distutils configuration file, because +the values of the options changed based on what you’re trying to do. + +Setuptools therefore allows you to define “aliases” - shortcut names for +an arbitrary string of commands and options, using ‘setup.py alias +aliasname expansion’, where aliasname is the name of the new alias, and +the remainder of the command line supplies its expansion. For example, +this command defines a sitewide alias called “daily”, that sets various +‘egg_info’ tagging options: + + setup.py alias --global-config daily egg_info --tag-build=development + +Once the alias is defined, it can then be used with other setup +commands, e.g.: + + setup.py daily bdist_egg # generate a daily-build .egg file + setup.py daily sdist # generate a daily-build source distro + setup.py daily sdist bdist_egg # generate both + +The above commands are interpreted as if the word ‘daily’ were replaced +with ‘egg_info --tag-build=development’. + +Note that setuptools will expand each alias `at most once' in a given +command line. This serves two purposes. First, if you accidentally +create an alias loop, it will have no effect; you’ll instead get an +error message about an unknown command. Second, it allows you to define +an alias for a command, that uses that command. For example, this +(project-local) alias: + + setup.py alias bdist_egg bdist_egg rotate -k1 -m.egg + +redefines the ‘bdist_egg’ command so that it always runs the ‘rotate’ +command afterwards to delete all but the newest egg file. It doesn’t +loop indefinitely on ‘bdist_egg’ because the alias is only expanded once +when used. + +You can remove a defined alias with the ‘--remove’ (or ‘-r’) option, +e.g.: + + setup.py alias --global-config --remove daily + +would delete the “daily” alias we defined above. + +Aliases can be defined on a project-specific, per-user, or sitewide +basis. The default is to define or remove a project-specific alias, but +you can use any of the *note configuration file options: 5d. (listed +under the *note saveopts: 5e. command, below) to determine which +distutils configuration file an aliases will be added to (or removed +from). + +Note that if you omit the “expansion” argument to the ‘alias’ command, +you’ll get output showing that alias’ current definition (and what +configuration file it’s defined in). If you omit the alias name as +well, you’ll get a listing of all current aliases along with their +configuration file locations. + + +File: setuptools.info, Node: bdist_egg - Create a Python Egg for the project, Next: develop - Deploy the project source in “Development Mode”, Prev: alias - Define shortcuts for commonly used commands, Up: Command Reference + +1.1.14.2 ‘bdist_egg’ - Create a Python Egg for the project +.......................................................... + + Warning: `eggs' are deprecated in favor of wheels, and not + supported by pip. + +This command generates a Python Egg (‘.egg’ file) for the project. +Python Eggs are the preferred binary distribution format for +EasyInstall, because they are cross-platform (for “pure” packages), +directly importable, and contain project metadata including scripts and +information about the project’s dependencies. They can be simply +downloaded and added to ‘sys.path’ directly, or they can be placed in a +directory on ‘sys.path’ and then automatically discovered by the egg +runtime system. + +This command runs the *note egg_info: 3d. command (if it hasn’t already +run) to update the project’s metadata (‘.egg-info’) directory. If you +have added any extra metadata files to the ‘.egg-info’ directory, those +files will be included in the new egg file’s metadata directory, for use +by the egg runtime system or by any applications or frameworks that use +that metadata. + +You won’t usually need to specify any special options for this command; +just use ‘bdist_egg’ and you’re done. But there are a few options that +may be occasionally useful: + +‘--dist-dir=DIR, -d DIR’ + + Set the directory where the ‘.egg’ file will be placed. If you + don’t supply this, then the ‘--dist-dir’ setting of the ‘bdist’ + command will be used, which is usually a directory named ‘dist’ in + the project directory. + +‘--plat-name=PLATFORM, -p PLATFORM’ + + Set the platform name string that will be embedded in the egg’s + filename (assuming the egg contains C extensions). This can be + used to override the distutils default platform name with something + more meaningful. Keep in mind, however, that the egg runtime + system expects to see eggs with distutils platform names, so it may + ignore or reject eggs with non-standard platform names. Similarly, + the EasyInstall program may ignore them when searching web pages + for download links. However, if you are cross-compiling or doing + some other unusual things, you might find a use for this option. + +‘--exclude-source-files’ + + Don’t include any modules’ ‘.py’ files in the egg, just compiled + Python, C, and data files. (Note that this doesn’t affect any + ‘.py’ files in the EGG-INFO directory or its subdirectories, since + for example there may be scripts with a ‘.py’ extension which must + still be retained.) We don’t recommend that you use this option + except for packages that are being bundled for proprietary end-user + applications, or for “embedded” scenarios where space is at an + absolute premium. On the other hand, if your package is going to + be installed and used in compressed form, you might as well exclude + the source because Python’s ‘traceback’ module doesn’t currently + understand how to display zipped source code anyway, or how to deal + with files that are in a different place from where their code was + compiled. + +There are also some options you will probably never need, but which are +there because they were copied from similar ‘bdist’ commands used as an +example for creating this one. They may be useful for testing and +debugging, however, which is why we kept them: + +‘--keep-temp, -k’ + + Keep the contents of the ‘--bdist-dir’ tree around after creating + the ‘.egg’ file. + +‘--bdist-dir=DIR, -b DIR’ + + Set the temporary directory for creating the distribution. The + entire contents of this directory are zipped to create the ‘.egg’ + file, after running various installation commands to copy the + package’s modules, data, and extensions here. + +‘--skip-build’ + + Skip doing any “build” commands; just go straight to the + install-and-compress phases. + + +File: setuptools.info, Node: develop - Deploy the project source in “Development Mode”, Next: egg_info - Create egg metadata and set build tags, Prev: bdist_egg - Create a Python Egg for the project, Up: Command Reference + +1.1.14.3 ‘develop’ - Deploy the project source in “Development Mode” +.................................................................... + +This command allows you to deploy your project’s source for use in one +or more “staging areas” where it will be available for importing. This +deployment is done in such a way that changes to the project source are +immediately available in the staging area(s), without needing to run a +build or install step after each change. + +The ‘develop’ command works by creating an ‘.egg-link’ file (named for +the project) in the given staging area. If the staging area is Python’s +‘site-packages’ directory, it also updates an ‘easy-install.pth’ file so +that the project is on ‘sys.path’ by default for all programs run using +that Python installation. + +The ‘develop’ command also installs wrapper scripts in the staging area +(or a separate directory, as specified) that will ensure the project’s +dependencies are available on ‘sys.path’ before running the project’s +source scripts. And, it ensures that any missing project dependencies +are available in the staging area, by downloading and installing them if +necessary. + +Last, but not least, the ‘develop’ command invokes the ‘build_ext -i’ +command to ensure any C extensions in the project have been built and +are up-to-date, and the ‘egg_info’ command to ensure the project’s +metadata is updated (so that the runtime and wrappers know what the +project’s dependencies are). If you make any changes to the project’s +setup script or C extensions, you should rerun the ‘develop’ command +against all relevant staging areas to keep the project’s scripts, +metadata and extensions up-to-date. Most other kinds of changes to your +project should not require any build operations or rerunning ‘develop’, +but keep in mind that even minor changes to the setup script (e.g. +changing an entry point definition) require you to re-run the ‘develop’ +or ‘test’ commands to keep the distribution updated. + +Here are some of the options that the ‘develop’ command accepts. Note +that they affect the project’s dependencies as well as the project +itself, so if you have dependencies that need to be installed and you +use ‘--exclude-scripts’ (for example), the dependencies’ scripts will +not be installed either! For this reason, you may want to use pip to +install the project’s dependencies before using the ‘develop’ command, +if you need finer control over the installation options for +dependencies. + +‘--uninstall, -u’ + + Un-deploy the current project. You may use the ‘--install-dir’ or + ‘-d’ option to designate the staging area. The created ‘.egg-link’ + file will be removed, if present and it is still pointing to the + project directory. The project directory will be removed from + ‘easy-install.pth’ if the staging area is Python’s ‘site-packages’ + directory. + + Note that this option currently does `not' uninstall script + wrappers! You must uninstall them yourself, or overwrite them by + using pip to install a different version of the package. You can + also avoid installing script wrappers in the first place, if you + use the ‘--exclude-scripts’ (aka ‘-x’) option when you run + ‘develop’ to deploy the project. + +‘--multi-version, -m’ + + “Multi-version” mode. Specifying this option prevents ‘develop’ + from adding an ‘easy-install.pth’ entry for the project(s) being + deployed, and if an entry for any version of a project already + exists, the entry will be removed upon successful deployment. In + multi-version mode, no specific version of the package is available + for importing, unless you use ‘pkg_resources.require()’ to put it + on ‘sys.path’, or you are running a wrapper script generated by + ‘setuptools’. (In which case the wrapper script calls ‘require()’ + for you.) + + Note that if you install to a directory other than ‘site-packages’, + this option is automatically in effect, because ‘.pth’ files can + only be used in ‘site-packages’ (at least in Python 2.3 and 2.4). + So, if you use the ‘--install-dir’ or ‘-d’ option (or they are set + via configuration file(s)) your project and its dependencies will + be deployed in multi- version mode. + +‘--install-dir=DIR, -d DIR’ + + Set the installation directory (staging area). If this option is + not directly specified on the command line or in a distutils + configuration file, the distutils default installation location is + used. Normally, this will be the ‘site-packages’ directory, but if + you are using distutils configuration files, setting things like + ‘prefix’ or ‘install_lib’, then those settings are taken into + account when computing the default staging area. + +‘--script-dir=DIR, -s DIR’ + + Set the script installation directory. If you don’t supply this + option (via the command line or a configuration file), but you + `have' supplied an ‘--install-dir’ (via command line or config + file), then this option defaults to the same directory, so that the + scripts will be able to find their associated package installation. + Otherwise, this setting defaults to the location where the + distutils would normally install scripts, taking any distutils + configuration file settings into account. + +‘--exclude-scripts, -x’ + + Don’t deploy script wrappers. This is useful if you don’t want to + disturb existing versions of the scripts in the staging area. + +‘--always-copy, -a’ + + Copy all needed distributions to the staging area, even if they are + already present in another directory on ‘sys.path’. By default, if + a requirement can be met using a distribution that is already + available in a directory on ‘sys.path’, it will not be copied to + the staging area. + +‘--egg-path=DIR’ + + Force the generated ‘.egg-link’ file to use a specified relative + path to the source directory. This can be useful in circumstances + where your installation directory is being shared by code running + under multiple platforms (e.g. Mac and Windows) which have + different absolute locations for the code under development, but + the same `relative' locations with respect to the installation + directory. If you use this option when installing, you must supply + the same relative path when uninstalling. + +In addition to the above options, the ‘develop’ command also accepts all +of the same options accepted by ‘easy_install’. If you’ve configured +any ‘easy_install’ settings in your ‘setup.cfg’ (or other distutils +config files), the ‘develop’ command will use them as defaults, unless +you override them in a ‘[develop]’ section or on the command line. + + +File: setuptools.info, Node: egg_info - Create egg metadata and set build tags, Next: rotate - Delete outdated distribution files, Prev: develop - Deploy the project source in “Development Mode”, Up: Command Reference + +1.1.14.4 ‘egg_info’ - Create egg metadata and set build tags +............................................................ + +This command performs two operations: it updates a project’s ‘.egg-info’ +metadata directory (used by the ‘bdist_egg’, ‘develop’, and ‘test’ +commands), and it allows you to temporarily change a project’s version +string, to support “daily builds” or “snapshot” releases. It is run +automatically by the ‘sdist’, ‘bdist_egg’, ‘develop’, and ‘test’ +commands in order to update the project’s metadata, but you can also +specify it explicitly in order to temporarily change the project’s +version string while executing other commands. (It also generates the +‘.egg-info/SOURCES.txt’ manifest file, which is used when you are +building source distributions.) + +In addition to writing the core egg metadata defined by ‘setuptools’ and +required by ‘pkg_resources’, this command can be extended to write other +metadata files as well, by defining entry points in the +‘egg_info.writers’ group. See the section on *note Adding new EGG-INFO +Files: 4b. below for more details. Note that using additional metadata +writers may require you to include a ‘setup_requires’ argument to +‘setup()’ in order to ensure that the desired writers are available on +‘sys.path’. + +* Menu: + +* Release Tagging Options:: +* Other egg_info Options:: +* egg_info Examples:: + + +File: setuptools.info, Node: Release Tagging Options, Next: Other egg_info Options, Up: egg_info - Create egg metadata and set build tags + +1.1.14.5 Release Tagging Options +................................ + +The following options can be used to modify the project’s version string +for all remaining commands on the setup command line. The options are +processed in the order shown, so if you use more than one, the requested +tags will be added in the following order: + +‘--tag-build=NAME, -b NAME’ + + Append NAME to the project’s version string. Due to the way + setuptools processes “pre-release” version suffixes beginning with + the letters “a” through “e” (like “alpha”, “beta”, and + “candidate”), you will usually want to use a tag like “.build” or + “.dev”, as this will cause the version number to be considered + `lower' than the project’s default version. (If you want to make + the version number `higher' than the default version, you can + always leave off –tag-build and then use one or both of the + following options.) + + If you have a default build tag set in your ‘setup.cfg’, you can + suppress it on the command line using ‘-b ""’ or ‘--tag-build=""’ + as an argument to the ‘egg_info’ command. + +‘--tag-date, -d’ + + Add a date stamp of the form “-YYYYMMDD” (e.g. “-20050528”) to the + project’s version number. + +‘--no-date, -D’ + + Don’t include a date stamp in the version number. This option is + included so you can override a default setting in ‘setup.cfg’. + +(Note: Because these options modify the version number used for source +and binary distributions of your project, you should first make sure +that you know how the resulting version numbers will be interpreted by +automated tools like pip. See the section above on *note Specifying +Your Project’s Version: 3e. for an explanation of pre- and post-release +tags, as well as tips on how to choose and verify a versioning scheme +for your project.) + +For advanced uses, there is one other option that can be set, to change +the location of the project’s ‘.egg-info’ directory. Commands that need +to find the project’s source directory or metadata should get it from +this setting: + + +File: setuptools.info, Node: Other egg_info Options, Next: egg_info Examples, Prev: Release Tagging Options, Up: egg_info - Create egg metadata and set build tags + +1.1.14.6 Other ‘egg_info’ Options +................................. + +‘--egg-base=SOURCEDIR, -e SOURCEDIR’ + + Specify the directory that should contain the .egg-info directory. + This should normally be the root of your project’s source tree + (which is not necessarily the same as your project directory; some + projects use a ‘src’ or ‘lib’ subdirectory as the source root). + You should not normally need to specify this directory, as it is + normally determined from the ‘package_dir’ argument to the + ‘setup()’ function, if any. If there is no ‘package_dir’ set, this + option defaults to the current directory. + + +File: setuptools.info, Node: egg_info Examples, Prev: Other egg_info Options, Up: egg_info - Create egg metadata and set build tags + +1.1.14.7 ‘egg_info’ Examples +............................ + +Creating a dated “nightly build” snapshot egg: + + setup.py egg_info --tag-date --tag-build=DEV bdist_egg + +Creating a release with no version tags, even if some default tags are +specified in ‘setup.cfg’: + + setup.py egg_info -RDb "" sdist bdist_egg + +(Notice that ‘egg_info’ must always appear on the command line `before' +any commands that you want the version changes to apply to.) + + +File: setuptools.info, Node: rotate - Delete outdated distribution files, Next: saveopts - Save used options to a configuration file, Prev: egg_info - Create egg metadata and set build tags, Up: Command Reference + +1.1.14.8 ‘rotate’ - Delete outdated distribution files +...................................................... + +As you develop new versions of your project, your distribution (‘dist’) +directory will gradually fill up with older source and/or binary +distribution files. The ‘rotate’ command lets you automatically clean +these up, keeping only the N most-recently modified files matching a +given pattern. + +‘--match=PATTERNLIST, -m PATTERNLIST’ + + Comma-separated list of glob patterns to match. This option is + `required'. The project name and ‘-*’ is prepended to the supplied + patterns, in order to match only distributions belonging to the + current project (in case you have a shared distribution directory + for multiple projects). Typically, you will use a glob pattern + like ‘.zip’ or ‘.egg’ to match files of the specified type. Note + that each supplied pattern is treated as a distinct group of files + for purposes of selecting files to delete. + +‘--keep=COUNT, -k COUNT’ + + Number of matching distributions to keep. For each group of files + identified by a pattern specified with the ‘--match’ option, delete + all but the COUNT most-recently-modified files in that group. This + option is `required'. + +‘--dist-dir=DIR, -d DIR’ + + Directory where the distributions are. This defaults to the value + of the ‘bdist’ command’s ‘--dist-dir’ option, which will usually be + the project’s ‘dist’ subdirectory. + +`Example 1': Delete all .tar.gz files from the distribution directory, +except for the 3 most recently modified ones: + + setup.py rotate --match=.tar.gz --keep=3 + +`Example 2': Delete all Python 2.3 or Python 2.4 eggs from the +distribution directory, except the most recently modified one for each +Python version: + + setup.py rotate --match=-py2.3*.egg,-py2.4*.egg --keep=1 + + +File: setuptools.info, Node: saveopts - Save used options to a configuration file, Next: setopt - Set a distutils or setuptools option in a config file, Prev: rotate - Delete outdated distribution files, Up: Command Reference + +1.1.14.9 ‘saveopts’ - Save used options to a configuration file +............................................................... + +Finding and editing ‘distutils’ configuration files can be a pain, +especially since you also have to translate the configuration options +from command-line form to the proper configuration file format. You can +avoid these hassles by using the ‘saveopts’ command. Just add it to the +command line to save the options you used. For example, this command +builds the project using the ‘mingw32’ C compiler, then saves the +–compiler setting as the default for future builds (even those run +implicitly by the ‘install’ command): + + setup.py build --compiler=mingw32 saveopts + +The ‘saveopts’ command saves all options for every command specified on +the command line to the project’s local ‘setup.cfg’ file, unless you use +one of the *note configuration file options: 5d. to change where the +options are saved. For example, this command does the same as above, +but saves the compiler setting to the site-wide (global) distutils +configuration: + + setup.py build --compiler=mingw32 saveopts -g + +Note that it doesn’t matter where you place the ‘saveopts’ command on +the command line; it will still save all the options specified for all +commands. For example, this is another valid way to spell the last +example: + + setup.py saveopts -g build --compiler=mingw32 + +Note, however, that all of the commands specified are always run, +regardless of where ‘saveopts’ is placed on the command line. + +* Menu: + +* Configuration File Options:: + + +File: setuptools.info, Node: Configuration File Options, Up: saveopts - Save used options to a configuration file + +1.1.14.10 Configuration File Options +.................................... + +Normally, settings such as options and aliases are saved to the +project’s local ‘setup.cfg’ file. But you can override this and save +them to the global or per-user configuration files, or to a +manually-specified filename. + +‘--global-config, -g’ + + Save settings to the global ‘distutils.cfg’ file inside the + ‘distutils’ package directory. You must have write access to that + directory to use this option. You also can’t combine this option + with ‘-u’ or ‘-f’. + +‘--user-config, -u’ + + Save settings to the current user’s ‘~/.pydistutils.cfg’ (POSIX) or + ‘$HOME/pydistutils.cfg’ (Windows) file. You can’t combine this + option with ‘-g’ or ‘-f’. + +‘--filename=FILENAME, -f FILENAME’ + + Save settings to the specified configuration file to use. You + can’t combine this option with ‘-g’ or ‘-u’. Note that if you + specify a non-standard filename, the ‘distutils’ and ‘setuptools’ + will not use the file’s contents. This option is mainly included + for use in testing. + +These options are used by other ‘setuptools’ commands that modify +configuration files, such as the *note alias: 40. and *note setopt: 67. +commands. + + +File: setuptools.info, Node: setopt - Set a distutils or setuptools option in a config file, Next: test - Build package and run a unittest suite, Prev: saveopts - Save used options to a configuration file, Up: Command Reference + +1.1.14.11 ‘setopt’ - Set a distutils or setuptools option in a config file +.......................................................................... + +This command is mainly for use by scripts, but it can also be used as a +quick and dirty way to change a distutils configuration option without +having to remember what file the options are in and then open an editor. + +`Example 1'. Set the default C compiler to ‘mingw32’ (using long option +names): + + setup.py setopt --command=build --option=compiler --set-value=mingw32 + +`Example 2'. Remove any setting for the distutils default package +installation directory (short option names): + + setup.py setopt -c install -o install_lib -r + +Options for the ‘setopt’ command: + +‘--command=COMMAND, -c COMMAND’ + + Command to set the option for. This option is required. + +‘--option=OPTION, -o OPTION’ + + The name of the option to set. This option is required. + +‘--set-value=VALUE, -s VALUE’ + + The value to set the option to. Not needed if ‘-r’ or ‘--remove’ + is set. + +‘--remove, -r’ + + Remove (unset) the option, instead of setting it. + +In addition to the above options, you may use any of the *note +configuration file options: 5d. (listed under the *note saveopts: 5e. +command, above) to determine which distutils configuration file the +option will be added to (or removed from). + + +File: setuptools.info, Node: test - Build package and run a unittest suite, Next: upload - Upload source and/or egg distributions to PyPI, Prev: setopt - Set a distutils or setuptools option in a config file, Up: Command Reference + +1.1.14.12 ‘test’ - Build package and run a unittest suite +......................................................... + + Warning: ‘test’ is deprecated and will be removed in a future + version. Users looking for a generic test entry point independent + of test runner are encouraged to use tox(1). + +When doing test-driven development, or running automated builds that +need testing before they are deployed for downloading or use, it’s often +useful to be able to run a project’s unit tests without actually +deploying the project anywhere, even using the ‘develop’ command. The +‘test’ command runs a project’s unit tests without actually deploying +it, by temporarily putting the project’s source on ‘sys.path’, after +first running ‘build_ext -i’ and ‘egg_info’ to ensure that any C +extensions and project metadata are up-to-date. + +To use this command, your project’s tests must be wrapped in a +‘unittest’ test suite by either a function, a ‘TestCase’ class or +method, or a module or package containing ‘TestCase’ classes. If the +named suite is a module, and the module has an ‘additional_tests()’ +function, it is called and the result (which must be a +‘unittest.TestSuite’) is added to the tests to be run. If the named +suite is a package, any submodules and subpackages are recursively added +to the overall test suite. (Note: if your project specifies a +‘test_loader’, the rules for processing the chosen ‘test_suite’ may +differ; see the *note test_loader: 57. documentation for more details.) + +Note that many test systems including ‘doctest’ support wrapping their +non-‘unittest’ tests in ‘TestSuite’ objects. So, if you are using a +test package that does not support this, we suggest you encourage its +developers to implement test suite support, as this is a convenient and +standard way to aggregate a collection of tests to be run under a common +test harness. + +By default, tests will be run in the “verbose” mode of the ‘unittest’ +package’s text test runner, but you can get the “quiet” mode (just dots) +if you supply the ‘-q’ or ‘--quiet’ option, either as a global option to +the setup script (e.g. ‘setup.py -q test’) or as an option for the +‘test’ command itself (e.g. ‘setup.py test -q’). There is one other +option available: + +‘--test-suite=NAME, -s NAME’ + + Specify the test suite (or module, class, or method) to be run + (e.g. ‘some_module.test_suite’). The default for this option can + be set by giving a ‘test_suite’ argument to the ‘setup()’ function, + e.g.: + + setup( + # ... + test_suite="my_package.tests.test_all" + ) + + If you did not set a ‘test_suite’ in your ‘setup()’ call, and do + not provide a ‘--test-suite’ option, an error will occur. + +New in 41.5.0: Deprecated the test command. + + ---------- Footnotes ---------- + + (1) https://tox.readthedocs.io + + +File: setuptools.info, Node: upload - Upload source and/or egg distributions to PyPI, Prev: test - Build package and run a unittest suite, Up: Command Reference + +1.1.14.13 ‘upload’ - Upload source and/or egg distributions to PyPI +................................................................... + +The ‘upload’ command was deprecated in version 40.0 and removed in +version 42.0. Use twine(1) instead. + +For more information on the current best practices in uploading your +packages to PyPI, see the Python Packaging User Guide’s “Packaging +Python Projects” tutorial specifically the section on uploading the +distribution archives(2). + + ---------- Footnotes ---------- + + (1) https://pypi.org/p/twine + + (2) +https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives + + +File: setuptools.info, Node: Using setuptools to package and distribute your project, Next: Automatic Resource Extraction, Prev: Command Reference, Up: Transition to PEP517 + +1.1.15 Using setuptools to package and distribute your project +-------------------------------------------------------------- + +‘setuptools’ offers a variety of functionalities that make it easy to +build and distribute your python package. Here we provide an overview +on the commonly used ones. + + +File: setuptools.info, Node: Automatic Resource Extraction, Next: Defining Additional Metadata, Prev: Using setuptools to package and distribute your project, Up: Transition to PEP517 + +1.1.16 Automatic Resource Extraction +------------------------------------ + +If you are using tools that expect your resources to be “real” files, or +your project includes non-extension native libraries or other files that +your C extensions expect to be able to access, you may need to list +those files in the ‘eager_resources’ argument to ‘setup()’, so that the +files will be extracted together, whenever a C extension in the project +is imported. + +This is especially important if your project includes shared libraries +`other' than distutils-built C extensions, and those shared libraries +use file extensions other than ‘.dll’, ‘.so’, or ‘.dylib’, which are the +extensions that setuptools 0.6a8 and higher automatically detects as +shared libraries and adds to the ‘native_libs.txt’ file for you. Any +shared libraries whose names do not end with one of those extensions +should be listed as ‘eager_resources’, because they need to be present +in the filesystem when he C extensions that link to them are used. + +The ‘pkg_resources’ runtime for compressed packages will automatically +extract `all' C extensions and ‘eager_resources’ at the same time, +whenever `any' C extension or eager resource is requested via the +‘resource_filename()’ API. (C extensions are imported using +‘resource_filename()’ internally.) This ensures that C extensions will +see all of the “real” files that they expect to see. + +Note also that you can list directory resource names in +‘eager_resources’ as well, in which case the directory’s contents +(including subdirectories) will be extracted whenever any C extension or +eager resource is requested. + +Please note that if you’re not sure whether you need to use this +argument, you don’t! It’s really intended to support projects with lots +of non-Python dependencies and as a last resort for crufty projects that +can’t otherwise handle being compressed. If your package is pure +Python, Python plus data files, or Python plus C, you really don’t need +this. You’ve got to be using either C or an external program that needs +“real” files in your project before there’s any possibility of +‘eager_resources’ being relevant to your project. + + +File: setuptools.info, Node: Defining Additional Metadata, Next: Setting the zip_safe flag, Prev: Automatic Resource Extraction, Up: Transition to PEP517 + +1.1.17 Defining Additional Metadata +----------------------------------- + +Some extensible applications and frameworks may need to define their own +kinds of metadata to include in eggs, which they can then access using +the ‘pkg_resources’ metadata APIs. Ordinarily, this is done by having +plugin developers include additional files in their +‘ProjectName.egg-info’ directory. However, since it can be tedious to +create such files by hand, you may want to create a distutils extension +that will create the necessary files from arguments to ‘setup()’, in +much the same way that ‘setuptools’ does for many of the ‘setup()’ +arguments it adds. See the section below on *note Creating distutils +Extensions: 46. for more details, especially the subsection on *note +Adding new EGG-INFO Files: 4b. + + +File: setuptools.info, Node: Setting the zip_safe flag, Prev: Defining Additional Metadata, Up: Transition to PEP517 + +1.1.18 Setting the ‘zip_safe’ flag +---------------------------------- + +For some use cases (such as bundling as part of a larger application), +Python packages may be run directly from a zip file. Not all packages, +however, are capable of running in compressed form, because they may +expect to be able to access either source code or data files as normal +operating system files. So, ‘setuptools’ can install your project as a +zipfile or a directory, and its default choice is determined by the +project’s ‘zip_safe’ flag. + +You can pass a True or False value for the ‘zip_safe’ argument to the +‘setup()’ function, or you can omit it. If you omit it, the ‘bdist_egg’ +command will analyze your project’s contents to see if it can detect any +conditions that would prevent it from working in a zipfile. It will +output notices to the console about any such conditions that it finds. + +Currently, this analysis is extremely conservative: it will consider the +project unsafe if it contains any C extensions or datafiles whatsoever. +This does `not' mean that the project can’t or won’t work as a zipfile! +It just means that the ‘bdist_egg’ authors aren’t yet comfortable +asserting that the project `will' work. If the project contains no C or +data files, and does no ‘__file__’ or ‘__path__’ introspection or source +code manipulation, then there is an extremely solid chance the project +will work when installed as a zipfile. (And if the project uses +‘pkg_resources’ for all its data file access, then C extensions and +other data files shouldn’t be a problem at all. See the *note Accessing +Data Files at Runtime: 33. section above for more information.) + +However, if ‘bdist_egg’ can’t be `sure' that your package will work, but +you’ve checked over all the warnings it issued, and you are either +satisfied it `will' work (or if you want to try it for yourself), then +you should set ‘zip_safe’ to ‘True’ in your ‘setup()’ call. If it turns +out that it doesn’t work, you can always change it to ‘False’, which +will force ‘setuptools’ to install your project as a directory rather +than as a zipfile. + +In the future, as we gain more experience with different packages and +become more satisfied with the robustness of the ‘pkg_resources’ +runtime, the “zip safety” analysis may become less conservative. +However, we strongly recommend that you determine for yourself whether +your project functions correctly when installed as a zipfile, correct +any problems if you can, and then make an explicit declaration of ‘True’ +or ‘False’ for the ‘zip_safe’ flag, so that it will not be necessary for +‘bdist_egg’ to try to guess whether your project can work as a zipfile. + + +File: setuptools.info, Node: Build System Support, Next: Package Discovery and Resource Access using pkg_resources, Prev: Building and Distributing Packages with Setuptools, Up: Top + +2 Build System Support +********************** + +* Menu: + +* What is it?:: +* How to use it?:: + + +File: setuptools.info, Node: What is it?, Next: How to use it?, Up: Build System Support + +2.1 What is it? +=============== + +Python packaging has come a long way(1). + +The traditional ‘setuptools’ way of packgaging Python modules uses a +‘setup()’ function within the ‘setup.py’ script. Commands such as +‘python setup.py bdist’ or ‘python setup.py bdist_wheel’ generate a +distribution bundle and ‘python setup.py install’ installs the +distribution. This interface makes it difficult to choose other +packaging tools without an overhaul. Because ‘setup.py’ scripts allowed +for arbitrary execution, it proved difficult to provide a reliable user +experience across environments and history. + +PEP 517(2) therefore came to rescue and specified a new standard to +package and distribute Python modules. Under PEP 517: + + a ‘pyproject.toml’ file is used to specify what program to use for + generating distribution. + + Then, two functions provided by the program, + ‘build_wheel(directory: str)’ and ‘build_sdist(directory: str)’ + create the distribution bundle at the specified ‘directory’. The + program is free to use its own configuration script or extend the + ‘.toml’ file. + + Lastly, ‘pip install *.whl’ or ‘pip install *.tar.gz’ does the + actual installation. If ‘*.whl’ is available, ‘pip’ will go ahead + and copy the files into ‘site-packages’ directory. If not, ‘pip’ + will look at ‘pyproject.toml’ and decide what program to use to + ‘build from source’ (the default is ‘setuptools’) + +With this standard, switching between packaging tools becomes a lot +easier. ‘build_meta’ implements ‘setuptools’’ build system support. + + ---------- Footnotes ---------- + + (1) https://www.bernat.tech/pep-517-518/ + + (2) https://www.python.org/dev/peps/pep-0517/ + + +File: setuptools.info, Node: How to use it?, Prev: What is it?, Up: Build System Support + +2.2 How to use it? +================== + +Starting with a package that you want to distribute. You will need your +source scripts, a ‘pyproject.toml’ file and a ‘setup.cfg’ file: + + ~/meowpkg/ + pyproject.toml + setup.cfg + meowpkg/__init__.py + +The pyproject.toml file is required to specify the build system (i.e. +what is being used to package your scripts and install from source). To +use it with setuptools, the content would be: + + [build-system] + requires = ["setuptools", "wheel"] + build-backend = "setuptools.build_meta" + +Use ‘setuptools’’ *note declarative config: 50. to specify the package +information: + + [metadata] + name = meowpkg + version = 0.0.1 + description = a package that meows + + [options] + packages = find: + +Now generate the distribution. Although the PyPA is still working to +provide a recommended tool(1) to build packages, the pep517 package(2) +provides this functionality. To build the package: + + $ pip install -q pep517 + $ mkdir dist + $ python -m pep517.build . + +And now it’s done! The ‘.whl’ file and ‘.tar.gz’ can then be +distributed and installed: + + dist/ + meowpkg-0.0.1.whl + meowpkg-0.0.1.tar.gz + + $ pip install dist/meowpkg-0.0.1.whl + +or: + + $ pip install dist/meowpkg-0.0.1.tar.gz + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/packaging-problems/issues/219 + + (2) https://pypi.org/project/pep517 + + +File: setuptools.info, Node: Package Discovery and Resource Access using pkg_resources, Next: Keywords, Prev: Build System Support, Up: Top + +3 Package Discovery and Resource Access using ‘pkg_resources’ +************************************************************* + +The ‘pkg_resources’ module distributed with ‘setuptools’ provides an API +for Python libraries to access their resource files, and for extensible +applications and frameworks to automatically discover plugins. It also +provides runtime support for using C extensions that are inside +zipfile-format eggs, support for merging packages that have +separately-distributed modules or subpackages, and APIs for managing +Python’s current “working set” of active packages. + +* Menu: + +* Overview:: +* API Reference:: + + +File: setuptools.info, Node: Overview, Next: API Reference, Up: Package Discovery and Resource Access using pkg_resources + +3.1 Overview +============ + +The ‘pkg_resources’ module provides runtime facilities for finding, +introspecting, activating and using installed Python distributions. +Some of the more advanced features (notably the support for parallel +installation of multiple versions) rely specifically on the “egg” format +(either as a zip archive or subdirectory), while others (such as plugin +discovery) will work correctly so long as “egg-info” metadata +directories are available for relevant distributions. + +Eggs are a distribution format for Python modules, similar in concept to +Java’s “jars” or Ruby’s “gems”, or the “wheel” format defined in PEP +427. However, unlike a pure distribution format, eggs can also be +installed and added directly to ‘sys.path’ as an import location. When +installed in this way, eggs are `discoverable', meaning that they carry +metadata that unambiguously identifies their contents and dependencies. +This means that an installed egg can be `automatically' found and added +to ‘sys.path’ in response to simple requests of the form, “get me +everything I need to use docutils’ PDF support”. This feature allows +mutually conflicting versions of a distribution to co-exist in the same +Python installation, with individual applications activating the desired +version at runtime by manipulating the contents of ‘sys.path’ (this +differs from the virtual environment approach, which involves creating +isolated environments for each application). + +The following terms are needed in order to explain the capabilities +offered by this module: + +project + + A library, framework, script, plugin, application, or collection of + data or other resources, or some combination thereof. Projects are + assumed to have “relatively unique” names, e.g. names registered + with PyPI. + +release + + A snapshot of a project at a particular point in time, denoted by a + version identifier. + +distribution + + A file or files that represent a particular release. + +importable distribution + + A file or directory that, if placed on ‘sys.path’, allows Python to + import any modules contained within it. + +pluggable distribution + + An importable distribution whose filename unambiguously identifies + its release (i.e. project and version), and whose contents + unambiguously specify what releases of other projects will satisfy + its runtime requirements. + +extra + + An “extra” is an optional feature of a release, that may impose + additional runtime requirements. For example, if docutils PDF + support required a PDF support library to be present, docutils + could define its PDF support as an “extra”, and list what other + project releases need to be available in order to provide it. + +environment + + A collection of distributions potentially available for importing, + but not necessarily active. More than one distribution (i.e. + release version) for a given project may be present in an + environment. + +working set + + A collection of distributions actually available for importing, as + on ‘sys.path’. At most one distribution (release version) of a + given project may be present in a working set, as otherwise there + would be ambiguity as to what to import. + +eggs + + Eggs are pluggable distributions in one of the three formats + currently supported by ‘pkg_resources’. There are built eggs, + development eggs, and egg links. Built eggs are directories or + zipfiles whose name ends with ‘.egg’ and follows the egg naming + conventions, and contain an ‘EGG-INFO’ subdirectory (zipped or + otherwise). Development eggs are normal directories of Python code + with one or more ‘ProjectName.egg-info’ subdirectories. The + development egg format is also used to provide a default version of + a distribution that is available to software that doesn’t use + ‘pkg_resources’ to request specific versions. Egg links are + ‘*.egg-link’ files that contain the name of a built or development + egg, to support symbolic linking on platforms that do not have + native symbolic links (or where the symbolic link support is + limited). + +(For more information about these terms and concepts, see also this +architectural overview(1) of ‘pkg_resources’ and Python Eggs in +general.) + + ---------- Footnotes ---------- + + (1) +http://mail.python.org/pipermail/distutils-sig/2005-June/004652.html + + +File: setuptools.info, Node: API Reference, Prev: Overview, Up: Package Discovery and Resource Access using pkg_resources + +3.2 API Reference +================= + +* Menu: + +* Namespace Package Support:: +* WorkingSet Objects:: +* Environment Objects:: +* Requirement Objects:: +* Entry Points: Entry Points<2>. +* Distribution Objects:: +* ResourceManager API:: +* Metadata API:: +* Exceptions:: +* Supporting Custom Importers:: +* Utility Functions:: + + +File: setuptools.info, Node: Namespace Package Support, Next: WorkingSet Objects, Up: API Reference + +3.2.1 Namespace Package Support +------------------------------- + +A namespace package is a package that only contains other packages and +modules, with no direct contents of its own. Such packages can be split +across multiple, separately-packaged distributions. They are normally +used to split up large packages produced by a single organization, such +as in the ‘zope’ namespace package for Zope Corporation packages, and +the ‘peak’ namespace package for the Python Enterprise Application Kit. + +To create a namespace package, you list it in the ‘namespace_packages’ +argument to ‘setup()’, in your project’s ‘setup.py’. (See the *note +setuptools documentation on namespace packages: 1c. for more information +on this.) Also, you must add a ‘declare_namespace()’ call in the +package’s ‘__init__.py’ file(s): + +‘declare_namespace(name)’ + + Declare that the dotted package name ‘name’ is a “namespace + package” whose contained packages and modules may be spread across + multiple distributions. The named package’s ‘__path__’ will be + extended to include the corresponding package in all distributions + on ‘sys.path’ that contain a package of that name. (More + precisely, if an importer’s ‘find_module(name)’ returns a loader, + then it will also be searched for the package’s contents.) + Whenever a Distribution’s ‘activate()’ method is invoked, it checks + for the presence of namespace packages and updates their ‘__path__’ + contents accordingly. + +Applications that manipulate namespace packages or directly alter +‘sys.path’ at runtime may also need to use this API function: + +‘fixup_namespace_packages(path_item)’ + + Declare that ‘path_item’ is a newly added item on ‘sys.path’ that + may need to be used to update existing namespace packages. + Ordinarily, this is called for you when an egg is automatically + added to ‘sys.path’, but if your application modifies ‘sys.path’ to + include locations that may contain portions of a namespace package, + you will need to call this function to ensure they are added to the + existing namespace packages. + +Although by default ‘pkg_resources’ only supports namespace packages for +filesystem and zip importers, you can extend its support to other +“importers” compatible with PEP 302 using the +‘register_namespace_handler()’ function. See the section below on *note +Supporting Custom Importers: 7a. for details. + + +File: setuptools.info, Node: WorkingSet Objects, Next: Environment Objects, Prev: Namespace Package Support, Up: API Reference + +3.2.2 ‘WorkingSet’ Objects +-------------------------- + +The ‘WorkingSet’ class provides access to a collection of “active” +distributions. In general, there is only one meaningful ‘WorkingSet’ +instance: the one that represents the distributions that are currently +active on ‘sys.path’. This global instance is available under the name +‘working_set’ in the ‘pkg_resources’ module. However, specialized tools +may wish to manipulate working sets that don’t correspond to ‘sys.path’, +and therefore may wish to create other ‘WorkingSet’ instances. + +It’s important to note that the global ‘working_set’ object is +initialized from ‘sys.path’ when ‘pkg_resources’ is first imported, but +is only updated if you do all future ‘sys.path’ manipulation via +‘pkg_resources’ APIs. If you manually modify ‘sys.path’, you must +invoke the appropriate methods on the ‘working_set’ instance to keep it +in sync. Unfortunately, Python does not provide any way to detect +arbitrary changes to a list object like ‘sys.path’, so ‘pkg_resources’ +cannot automatically update the ‘working_set’ based on changes to +‘sys.path’. + +‘WorkingSet(entries=None)’ + + Create a ‘WorkingSet’ from an iterable of path entries. If + ‘entries’ is not supplied, it defaults to the value of ‘sys.path’ + at the time the constructor is called. + + Note that you will not normally construct ‘WorkingSet’ instances + yourself, but instead you will implicitly or explicitly use the + global ‘working_set’ instance. For the most part, the + ‘pkg_resources’ API is designed so that the ‘working_set’ is used + by default, such that you don’t have to explicitly refer to it most + of the time. + +All distributions available directly on ‘sys.path’ will be activated +automatically when ‘pkg_resources’ is imported. This behaviour can +cause version conflicts for applications which require non-default +versions of those distributions. To handle this situation, +‘pkg_resources’ checks for a ‘__requires__’ attribute in the ‘__main__’ +module when initializing the default working set, and uses this to +ensure a suitable version of each affected distribution is activated. +For example: + + __requires__ = ["CherryPy < 3"] # Must be set before pkg_resources import + import pkg_resources + +* Menu: + +* Basic WorkingSet Methods:: +* WorkingSet Methods and Attributes:: +* Receiving Change Notifications:: +* Locating Plugins:: + + +File: setuptools.info, Node: Basic WorkingSet Methods, Next: WorkingSet Methods and Attributes, Up: WorkingSet Objects + +3.2.2.1 Basic ‘WorkingSet’ Methods +.................................. + +The following methods of ‘WorkingSet’ objects are also available as +module- level functions in ‘pkg_resources’ that apply to the default +‘working_set’ instance. Thus, you can use e.g. +‘pkg_resources.require()’ as an abbreviation for +‘pkg_resources.working_set.require()’: + +‘require(*requirements)’ + + Ensure that distributions matching ‘requirements’ are activated + + ‘requirements’ must be a string or a (possibly-nested) sequence + thereof, specifying the distributions and versions required. The + return value is a sequence of the distributions that needed to be + activated to fulfill the requirements; all relevant distributions + are included, even if they were already activated in this working + set. + + For the syntax of requirement specifiers, see the section below on + *note Requirements Parsing: 7d. + + In general, it should not be necessary for you to call this method + directly. It’s intended more for use in quick-and-dirty scripting + and interactive interpreter hacking than for production use. If + you’re creating an actual library or application, it’s strongly + recommended that you create a “setup.py” script using ‘setuptools’, + and declare all your requirements there. That way, tools like pip + can automatically detect what requirements your package has, and + deal with them accordingly. + + Note that calling ‘require('SomePackage')’ will not install + ‘SomePackage’ if it isn’t already present. If you need to do this, + you should use the ‘resolve()’ method instead, which allows you to + pass an ‘installer’ callback that will be invoked when a needed + distribution can’t be found on the local machine. You can then + have this callback display a dialog, automatically download the + needed distribution, or whatever else is appropriate for your + application. See the documentation below on the ‘resolve()’ method + for more information, and also on the ‘obtain()’ method of + ‘Environment’ objects. + +‘run_script(requires, script_name)’ + + Locate distribution specified by ‘requires’ and run its + ‘script_name’ script. ‘requires’ must be a string containing a + requirement specifier. (See *note Requirements Parsing: 7d. below + for the syntax.) + + The script, if found, will be executed in `the caller’s globals'. + That’s because this method is intended to be called from wrapper + scripts that act as a proxy for the “real” scripts in a + distribution. A wrapper script usually doesn’t need to do anything + but invoke this function with the correct arguments. + + If you need more control over the script execution environment, you + probably want to use the ‘run_script()’ method of a ‘Distribution’ + object’s *note Metadata API: 7e. instead. + +‘iter_entry_points(group, name=None)’ + + Yield entry point objects from ‘group’ matching ‘name’ + + If ‘name’ is None, yields all entry points in ‘group’ from all + distributions in the working set, otherwise only ones matching both + ‘group’ and ‘name’ are yielded. Entry points are yielded from the + active distributions in the order that the distributions appear in + the working set. (For the global ‘working_set’, this should be the + same as the order that they are listed in ‘sys.path’.) Note that + within the entry points advertised by an individual distribution, + there is no particular ordering. + + Please see the section below on *note Entry Points: 7f. for more + information. + + +File: setuptools.info, Node: WorkingSet Methods and Attributes, Next: Receiving Change Notifications, Prev: Basic WorkingSet Methods, Up: WorkingSet Objects + +3.2.2.2 ‘WorkingSet’ Methods and Attributes +........................................... + +These methods are used to query or manipulate the contents of a specific +working set, so they must be explicitly invoked on a particular +‘WorkingSet’ instance: + +‘add_entry(entry)’ + + Add a path item to the ‘entries’, finding any distributions on it. + You should use this when you add additional items to ‘sys.path’ and + you want the global ‘working_set’ to reflect the change. This + method is also called by the ‘WorkingSet()’ constructor during + initialization. + + This method uses ‘find_distributions(entry,True)’ to find + distributions corresponding to the path entry, and then ‘add()’ + them. ‘entry’ is always appended to the ‘entries’ attribute, even + if it is already present, however. (This is because ‘sys.path’ can + contain the same value more than once, and the ‘entries’ attribute + should be able to reflect this.) + +‘__contains__(dist)’ + + True if ‘dist’ is active in this ‘WorkingSet’. Note that only one + distribution for a given project can be active in a given + ‘WorkingSet’. + +‘__iter__()’ + + Yield distributions for non-duplicate projects in the working set. + The yield order is the order in which the items’ path entries were + added to the working set. + +‘find(req)’ + + Find a distribution matching ‘req’ (a ‘Requirement’ instance). If + there is an active distribution for the requested project, this + returns it, as long as it meets the version requirement specified + by ‘req’. But, if there is an active distribution for the project + and it does `not' meet the ‘req’ requirement, ‘VersionConflict’ is + raised. If there is no active distribution for the requested + project, ‘None’ is returned. + +‘resolve(requirements, env=None, installer=None)’ + + List all distributions needed to (recursively) meet ‘requirements’ + + ‘requirements’ must be a sequence of ‘Requirement’ objects. ‘env’, + if supplied, should be an ‘Environment’ instance. If not supplied, + an ‘Environment’ is created from the working set’s ‘entries’. + ‘installer’, if supplied, will be invoked with each requirement + that cannot be met by an already-installed distribution; it should + return a ‘Distribution’ or ‘None’. (See the ‘obtain()’ method of + *note Environment Objects: 81, below, for more information on the + ‘installer’ argument.) + +‘add(dist, entry=None)’ + + Add ‘dist’ to working set, associated with ‘entry’ + + If ‘entry’ is unspecified, it defaults to ‘dist.location’. On exit + from this routine, ‘entry’ is added to the end of the working set’s + ‘.entries’ (if it wasn’t already present). + + ‘dist’ is only added to the working set if it’s for a project that + doesn’t already have a distribution active in the set. If it’s + successfully added, any callbacks registered with the ‘subscribe()’ + method will be called. (See *note Receiving Change Notifications: + 82, below.) + + Note: ‘add()’ is automatically called for you by the ‘require()’ + method, so you don’t normally need to use this method directly. + +‘entries’ + + This attribute represents a “shadow” ‘sys.path’, primarily useful + for debugging. If you are experiencing import problems, you should + check the global ‘working_set’ object’s ‘entries’ against + ‘sys.path’, to ensure that they match. If they do not, then some + part of your program is manipulating ‘sys.path’ without updating + the ‘working_set’ accordingly. IMPORTANT NOTE: do not directly + manipulate this attribute! Setting it equal to ‘sys.path’ will not + fix your problem, any more than putting black tape over an “engine + warning” light will fix your car! If this attribute is out of sync + with ‘sys.path’, it’s merely an `indicator' of the problem, not the + cause of it. + + +File: setuptools.info, Node: Receiving Change Notifications, Next: Locating Plugins, Prev: WorkingSet Methods and Attributes, Up: WorkingSet Objects + +3.2.2.3 Receiving Change Notifications +...................................... + +Extensible applications and frameworks may need to receive notification +when a new distribution (such as a plug-in component) has been added to +a working set. This is what the ‘subscribe()’ method and +‘add_activation_listener()’ function are for. + +‘subscribe(callback)’ + + Invoke ‘callback(distribution)’ once for each active distribution + that is in the set now, or gets added later. Because the callback + is invoked for already-active distributions, you do not need to + loop over the working set yourself to deal with the existing items; + just register the callback and be prepared for the fact that it + will be called immediately by this method. + + Note that callbacks `must not' allow exceptions to propagate, or + they will interfere with the operation of other callbacks and + possibly result in an inconsistent working set state. Callbacks + should use a try/except block to ignore, log, or otherwise process + any errors, especially since the code that caused the callback to + be invoked is unlikely to be able to handle the errors any better + than the callback itself. + +‘pkg_resources.add_activation_listener()’ is an alternate spelling of +‘pkg_resources.working_set.subscribe()’. + + +File: setuptools.info, Node: Locating Plugins, Prev: Receiving Change Notifications, Up: WorkingSet Objects + +3.2.2.4 Locating Plugins +........................ + +Extensible applications will sometimes have a “plugin directory” or a +set of plugin directories, from which they want to load entry points or +other metadata. The ‘find_plugins()’ method allows you to do this, by +scanning an environment for the newest version of each project that can +be safely loaded without conflicts or missing requirements. + +‘find_plugins(plugin_env, full_env=None, fallback=True)’ + + Scan ‘plugin_env’ and identify which distributions could be added + to this working set without version conflicts or missing + requirements. + + Example usage: + + distributions, errors = working_set.find_plugins( + Environment(plugin_dirlist) + ) + map(working_set.add, distributions) # add plugins+libs to sys.path + print "Couldn't load", errors # display errors + + The ‘plugin_env’ should be an ‘Environment’ instance that contains + only distributions that are in the project’s “plugin directory” or + directories. The ‘full_env’, if supplied, should be an + ‘Environment’ instance that contains all currently-available + distributions. + + If ‘full_env’ is not supplied, one is created automatically from + the ‘WorkingSet’ this method is called on, which will typically + mean that every directory on ‘sys.path’ will be scanned for + distributions. + + This method returns a 2-tuple: (‘distributions’, ‘error_info’), + where ‘distributions’ is a list of the distributions found in + ‘plugin_env’ that were loadable, along with any other distributions + that are needed to resolve their dependencies. ‘error_info’ is a + dictionary mapping unloadable plugin distributions to an exception + instance describing the error that occurred. Usually this will be + a ‘DistributionNotFound’ or ‘VersionConflict’ instance. + + Most applications will use this method mainly on the master + ‘working_set’ instance in ‘pkg_resources’, and then immediately add + the returned distributions to the working set so that they are + available on sys.path. This will make it possible to find any + entry points, and allow any other metadata tracking and hooks to be + activated. + + The resolution algorithm used by ‘find_plugins()’ is as follows. + First, the project names of the distributions present in + ‘plugin_env’ are sorted. Then, each project’s eggs are tried in + descending version order (i.e., newest version first). + + An attempt is made to resolve each egg’s dependencies. If the + attempt is successful, the egg and its dependencies are added to + the output list and to a temporary copy of the working set. The + resolution process continues with the next project name, and no + older eggs for that project are tried. + + If the resolution attempt fails, however, the error is added to the + error dictionary. If the ‘fallback’ flag is true, the next older + version of the plugin is tried, until a working version is found. + If false, the resolution process continues with the next plugin + project name. + + Some applications may have stricter fallback requirements than + others. For example, an application that has a database schema or + persistent objects may not be able to safely downgrade a version of + a package. Others may want to ensure that a new plugin + configuration is either 100% good or else revert to a known-good + configuration. (That is, they may wish to revert to a known + configuration if the ‘error_info’ return value is non-empty.) + + Note that this algorithm gives precedence to satisfying the + dependencies of alphabetically prior project names in case of + version conflicts. If two projects named “AaronsPlugin” and + “ZekesPlugin” both need different versions of “TomsLibrary”, then + “AaronsPlugin” will win and “ZekesPlugin” will be disabled due to + version conflict. + + +File: setuptools.info, Node: Environment Objects, Next: Requirement Objects, Prev: WorkingSet Objects, Up: API Reference + +3.2.3 ‘Environment’ Objects +--------------------------- + +An “environment” is a collection of ‘Distribution’ objects, usually ones +that are present and potentially importable on the current platform. +‘Environment’ objects are used by ‘pkg_resources’ to index available +distributions during dependency resolution. + +‘Environment(search_path=None, platform=get_supported_platform(), python=PY_MAJOR)’ + + Create an environment snapshot by scanning ‘search_path’ for + distributions compatible with ‘platform’ and ‘python’. + ‘search_path’ should be a sequence of strings such as might be used + on ‘sys.path’. If a ‘search_path’ isn’t supplied, ‘sys.path’ is + used. + + ‘platform’ is an optional string specifying the name of the + platform that platform-specific distributions must be compatible + with. If unspecified, it defaults to the current platform. + ‘python’ is an optional string naming the desired version of Python + (e.g. ‘'2.4'’); it defaults to the currently-running version. + + You may explicitly set ‘platform’ (and/or ‘python’) to ‘None’ if + you wish to include `all' distributions, not just those compatible + with the running platform or Python version. + + Note that ‘search_path’ is scanned immediately for distributions, + and the resulting ‘Environment’ is a snapshot of the found + distributions. It is not automatically updated if the system’s + state changes due to e.g. installation or removal of + distributions. + +‘__getitem__(project_name)’ + + Returns a list of distributions for the given project name, ordered + from newest to oldest version. (And highest to lowest format + precedence for distributions that contain the same version of the + project.) If there are no distributions for the project, returns + an empty list. + +‘__iter__()’ + + Yield the unique project names of the distributions in this + environment. The yielded names are always in lower case. + +‘add(dist)’ + + Add ‘dist’ to the environment if it matches the platform and python + version specified at creation time, and only if the distribution + hasn’t already been added. (i.e., adding the same distribution + more than once is a no-op.) + +‘remove(dist)’ + + Remove ‘dist’ from the environment. + +‘can_add(dist)’ + + Is distribution ‘dist’ acceptable for this environment? If it’s + not compatible with the ‘platform’ and ‘python’ version values + specified when the environment was created, a false value is + returned. + +‘__add__(dist_or_env)’ (‘+’ operator) + + Add a distribution or environment to an ‘Environment’ instance, + returning a `new' environment object that contains all the + distributions previously contained by both. The new environment + will have a ‘platform’ and ‘python’ of ‘None’, meaning that it will + not reject any distributions from being added to it; it will simply + accept whatever is added. If you want the added items to be + filtered for platform and Python version, or you want to add them + to the `same' environment instance, you should use in-place + addition (‘+=’) instead. + +‘__iadd__(dist_or_env)’ (‘+=’ operator) + + Add a distribution or environment to an ‘Environment’ instance + `in-place', updating the existing instance and returning it. The + ‘platform’ and ‘python’ filter attributes take effect, so + distributions in the source that do not have a suitable platform + string or Python version are silently ignored. + +‘best_match(req, working_set, installer=None)’ + + Find distribution best matching ‘req’ and usable on ‘working_set’ + + This calls the ‘find(req)’ method of the ‘working_set’ to see if a + suitable distribution is already active. (This may raise + ‘VersionConflict’ if an unsuitable version of the project is + already active in the specified ‘working_set’.) If a suitable + distribution isn’t active, this method returns the newest + distribution in the environment that meets the ‘Requirement’ in + ‘req’. If no suitable distribution is found, and ‘installer’ is + supplied, then the result of calling the environment’s ‘obtain(req, + installer)’ method will be returned. + +‘obtain(requirement, installer=None)’ + + Obtain a distro that matches requirement (e.g. via download). In + the base ‘Environment’ class, this routine just returns + ‘installer(requirement)’, unless ‘installer’ is None, in which case + None is returned instead. This method is a hook that allows + subclasses to attempt other ways of obtaining a distribution before + falling back to the ‘installer’ argument. + +‘scan(search_path=None)’ + + Scan ‘search_path’ for distributions usable on ‘platform’ + + Any distributions found are added to the environment. + ‘search_path’ should be a sequence of strings such as might be used + on ‘sys.path’. If not supplied, ‘sys.path’ is used. Only + distributions conforming to the platform/python version defined at + initialization are added. This method is a shortcut for using the + ‘find_distributions()’ function to find the distributions from each + item in ‘search_path’, and then calling ‘add()’ to add each one to + the environment. + + +File: setuptools.info, Node: Requirement Objects, Next: Entry Points<2>, Prev: Environment Objects, Up: API Reference + +3.2.4 ‘Requirement’ Objects +--------------------------- + +‘Requirement’ objects express what versions of a project are suitable +for some purpose. These objects (or their string form) are used by +various ‘pkg_resources’ APIs in order to find distributions that a +script or distribution needs. + +* Menu: + +* Requirements Parsing:: +* Requirement Methods and Attributes:: + + +File: setuptools.info, Node: Requirements Parsing, Next: Requirement Methods and Attributes, Up: Requirement Objects + +3.2.4.1 Requirements Parsing +............................ + +‘parse_requirements(s)’ + + Yield ‘Requirement’ objects for a string or iterable of lines. + Each requirement must start on a new line. See below for syntax. + +‘Requirement.parse(s)’ + + Create a ‘Requirement’ object from a string or iterable of lines. + A ‘ValueError’ is raised if the string or lines do not contain a + valid requirement specifier, or if they contain more than one + specifier. (To parse multiple specifiers from a string or iterable + of strings, use ‘parse_requirements()’ instead.) + + The syntax of a requirement specifier is defined in full in PEP + 508. + + Some examples of valid requirement specifiers: + + FooProject >= 1.2 + Fizzy [foo, bar] + PickyThing>1.6,<=1.9,!=1.8.6 + SomethingWhoseVersionIDontCareAbout + SomethingWithMarker[foo]>1.0;python_version<"2.7" + + The project name is the only required portion of a requirement + string, and if it’s the only thing supplied, the requirement will + accept any version of that project. + + The “extras” in a requirement are used to request optional features + of a project, that may require additional project distributions in + order to function. For example, if the hypothetical + “Report-O-Rama” project offered optional PDF support, it might + require an additional library in order to provide that support. + Thus, a project needing Report-O-Rama’s PDF features could use a + requirement of ‘Report-O-Rama[PDF]’ to request installation or + activation of both Report-O-Rama and any libraries it needs in + order to provide PDF support. For example, you could use: + + pip install Report-O-Rama[PDF] + + To install the necessary packages using pip, or call + ‘pkg_resources.require('Report-O-Rama[PDF]')’ to add the necessary + distributions to sys.path at runtime. + + The “markers” in a requirement are used to specify when a + requirement should be installed – the requirement will be installed + if the marker evaluates as true in the current environment. For + example, specifying ‘argparse;python_version<"3.0"’ will not + install in an Python 3 environment, but will in a Python 2 + environment. + + +File: setuptools.info, Node: Requirement Methods and Attributes, Prev: Requirements Parsing, Up: Requirement Objects + +3.2.4.2 ‘Requirement’ Methods and Attributes +............................................ + +‘__contains__(dist_or_version)’ + + Return true if ‘dist_or_version’ fits the criteria for this + requirement. If ‘dist_or_version’ is a ‘Distribution’ object, its + project name must match the requirement’s project name, and its + version must meet the requirement’s version criteria. If + ‘dist_or_version’ is a string, it is parsed using the + ‘parse_version()’ utility function. Otherwise, it is assumed to be + an already-parsed version. + + The ‘Requirement’ object’s version specifiers (‘.specs’) are + internally sorted into ascending version order, and used to + establish what ranges of versions are acceptable. Adjacent + redundant conditions are effectively consolidated (e.g. ‘">1, >2"’ + produces the same results as ‘">2"’, and ‘"<2,<3"’ produces the + same results as ‘"<2"’). ‘"!="’ versions are excised from the + ranges they fall within. The version being tested for + acceptability is then checked for membership in the resulting + ranges. + +‘__eq__(other_requirement)’ + + A requirement compares equal to another requirement if they have + case-insensitively equal project names, version specifiers, and + “extras”. (The order that extras and version specifiers are in is + also ignored.) Equal requirements also have equal hashes, so that + requirements can be used in sets or as dictionary keys. + +‘__str__()’ + + The string form of a ‘Requirement’ is a string that, if passed to + ‘Requirement.parse()’, would return an equal ‘Requirement’ object. + +‘project_name’ + + The name of the required project + +‘key’ + + An all-lowercase version of the ‘project_name’, useful for + comparison or indexing. + +‘extras’ + + A tuple of names of “extras” that this requirement calls for. + (These will be all-lowercase and normalized using the + ‘safe_extra()’ parsing utility function, so they may not exactly + equal the extras the requirement was created with.) + +‘specs’ + + A list of ‘(op,version)’ tuples, sorted in ascending parsed-version + order. The ‘op’ in each tuple is a comparison operator, + represented as a string. The ‘version’ is the (unparsed) version + number. + +‘marker’ + + An instance of ‘packaging.markers.Marker’ that allows evaluation + against the current environment. May be None if no marker + specified. + +‘url’ + + The location to download the requirement from if specified. + + +File: setuptools.info, Node: Entry Points<2>, Next: Distribution Objects, Prev: Requirement Objects, Up: API Reference + +3.2.5 Entry Points +------------------ + +Entry points are a simple way for distributions to “advertise” Python +objects (such as functions or classes) for use by other distributions. +Extensible applications and frameworks can search for entry points with +a particular name or group, either from a specific distribution or from +all active distributions on sys.path, and then inspect or load the +advertised objects at will. + +Entry points belong to “groups” which are named with a dotted name +similar to a Python package or module name. For example, the +‘setuptools’ package uses an entry point named ‘distutils.commands’ in +order to find commands defined by distutils extensions. ‘setuptools’ +treats the names of entry points defined in that group as the acceptable +commands for a setup script. + +In a similar way, other packages can define their own entry point +groups, either using dynamic names within the group (like +‘distutils.commands’), or possibly using predefined names within the +group. For example, a blogging framework that offers various pre- or +post-publishing hooks might define an entry point group and look for +entry points named “pre_process” and “post_process” within that group. + +To advertise an entry point, a project needs to use ‘setuptools’ and +provide an ‘entry_points’ argument to ‘setup()’ in its setup script, so +that the entry points will be included in the distribution’s metadata. +For more details, see the [‘setuptools’ +documentation](‘https://setuptools.readthedocs.io/en/latest/setuptools.html#dynamic-discovery-of-services-and-plugins’). + +Each project distribution can advertise at most one entry point of a +given name within the same entry point group. For example, a distutils +extension could advertise two different ‘distutils.commands’ entry +points, as long as they had different names. However, there is nothing +that prevents `different' projects from advertising entry points of the +same name in the same group. In some cases, this is a desirable thing, +since the application or framework that uses the entry points may be +calling them as hooks, or in some other way combining them. It is up to +the application or framework to decide what to do if multiple +distributions advertise an entry point; some possibilities include using +both entry points, displaying an error message, using the first one +found in sys.path order, etc. + +* Menu: + +* Convenience API:: +* Creating and Parsing:: +* EntryPoint Objects:: + + +File: setuptools.info, Node: Convenience API, Next: Creating and Parsing, Up: Entry Points<2> + +3.2.5.1 Convenience API +....................... + +In the following functions, the ‘dist’ argument can be a ‘Distribution’ +instance, a ‘Requirement’ instance, or a string specifying a requirement +(i.e. project name, version, etc.). If the argument is a string or +‘Requirement’, the specified distribution is located (and added to +sys.path if not already present). An error will be raised if a matching +distribution is not available. + +The ‘group’ argument should be a string containing a dotted identifier, +identifying an entry point group. If you are defining an entry point +group, you should include some portion of your package’s name in the +group name so as to avoid collision with other packages’ entry point +groups. + +‘load_entry_point(dist, group, name)’ + + Load the named entry point from the specified distribution, or + raise ‘ImportError’. + +‘get_entry_info(dist, group, name)’ + + Return an ‘EntryPoint’ object for the given ‘group’ and ‘name’ from + the specified distribution. Returns ‘None’ if the distribution has + not advertised a matching entry point. + +‘get_entry_map(dist, group=None)’ + + Return the distribution’s entry point map for ‘group’, or the full + entry map for the distribution. This function always returns a + dictionary, even if the distribution advertises no entry points. + If ‘group’ is given, the dictionary maps entry point names to the + corresponding ‘EntryPoint’ object. If ‘group’ is None, the + dictionary maps group names to dictionaries that then map entry + point names to the corresponding ‘EntryPoint’ instance in that + group. + +‘iter_entry_points(group, name=None)’ + + Yield entry point objects from ‘group’ matching ‘name’. + + If ‘name’ is None, yields all entry points in ‘group’ from all + distributions in the working set on sys.path, otherwise only ones + matching both ‘group’ and ‘name’ are yielded. Entry points are + yielded from the active distributions in the order that the + distributions appear on sys.path. (Within entry points for a + particular distribution, however, there is no particular ordering.) + + (This API is actually a method of the global ‘working_set’ object; + see the section above on *note Basic WorkingSet Methods: 7c. for + more information.) + + +File: setuptools.info, Node: Creating and Parsing, Next: EntryPoint Objects, Prev: Convenience API, Up: Entry Points<2> + +3.2.5.2 Creating and Parsing +............................ + +‘EntryPoint(name, module_name, attrs=(), extras=(), dist=None)’ + + Create an ‘EntryPoint’ instance. ‘name’ is the entry point name. + The ‘module_name’ is the (dotted) name of the module containing the + advertised object. ‘attrs’ is an optional tuple of names to look + up from the module to obtain the advertised object. For example, + an ‘attrs’ of ‘("foo","bar")’ and a ‘module_name’ of ‘"baz"’ would + mean that the advertised object could be obtained by the following + code: + + import baz + advertised_object = baz.foo.bar + + The ‘extras’ are an optional tuple of “extra feature” names that + the distribution needs in order to provide this entry point. When + the entry point is loaded, these extra features are looked up in + the ‘dist’ argument to find out what other distributions may need + to be activated on sys.path; see the ‘load()’ method for more + details. The ‘extras’ argument is only meaningful if ‘dist’ is + specified. ‘dist’ must be a ‘Distribution’ instance. + +‘EntryPoint.parse(src, dist=None)’ (classmethod) + + Parse a single entry point from string ‘src’ + + Entry point syntax follows the form: + + name = some.module:some.attr [extra1,extra2] + + The entry name and module name are required, but the ‘:attrs’ and + ‘[extras]’ parts are optional, as is the whitespace shown between + some of the items. The ‘dist’ argument is passed through to the + ‘EntryPoint()’ constructor, along with the other values parsed from + ‘src’. + +‘EntryPoint.parse_group(group, lines, dist=None)’ (classmethod) + + Parse ‘lines’ (a string or sequence of lines) to create a + dictionary mapping entry point names to ‘EntryPoint’ objects. + ‘ValueError’ is raised if entry point names are duplicated, if + ‘group’ is not a valid entry point group name, or if there are any + syntax errors. (Note: the ‘group’ parameter is used only for + validation and to create more informative error messages.) If + ‘dist’ is provided, it will be used to set the ‘dist’ attribute of + the created ‘EntryPoint’ objects. + +‘EntryPoint.parse_map(data, dist=None)’ (classmethod) + + Parse ‘data’ into a dictionary mapping group names to dictionaries + mapping entry point names to ‘EntryPoint’ objects. If ‘data’ is a + dictionary, then the keys are used as group names and the values + are passed to ‘parse_group()’ as the ‘lines’ argument. If ‘data’ + is a string or sequence of lines, it is first split into .ini-style + sections (using the ‘split_sections()’ utility function) and the + section names are used as group names. In either case, the ‘dist’ + argument is passed through to ‘parse_group()’ so that the entry + points will be linked to the specified distribution. + + +File: setuptools.info, Node: EntryPoint Objects, Prev: Creating and Parsing, Up: Entry Points<2> + +3.2.5.3 ‘EntryPoint’ Objects +............................ + +For simple introspection, ‘EntryPoint’ objects have attributes that +correspond exactly to the constructor argument names: ‘name’, +‘module_name’, ‘attrs’, ‘extras’, and ‘dist’ are all available. In +addition, the following methods are provided: + +‘load()’ + + Load the entry point, returning the advertised Python object. + Effectively calls ‘self.require()’ then returns ‘self.resolve()’. + +‘require(env=None, installer=None)’ + + Ensure that any “extras” needed by the entry point are available on + sys.path. ‘UnknownExtra’ is raised if the ‘EntryPoint’ has + ‘extras’, but no ‘dist’, or if the named extras are not defined by + the distribution. If ‘env’ is supplied, it must be an + ‘Environment’, and it will be used to search for needed + distributions if they are not already present on sys.path. If + ‘installer’ is supplied, it must be a callable taking a + ‘Requirement’ instance and returning a matching importable + ‘Distribution’ instance or None. + +‘resolve()’ + + Resolve the entry point from its module and attrs, returning the + advertised Python object. Raises ‘ImportError’ if it cannot be + obtained. + +‘__str__()’ + + The string form of an ‘EntryPoint’ is a string that could be passed + to ‘EntryPoint.parse()’ to produce an equivalent ‘EntryPoint’. + + +File: setuptools.info, Node: Distribution Objects, Next: ResourceManager API, Prev: Entry Points<2>, Up: API Reference + +3.2.6 ‘Distribution’ Objects +---------------------------- + +‘Distribution’ objects represent collections of Python code that may or +may not be importable, and may or may not have metadata and resources +associated with them. Their metadata may include information such as +what other projects the distribution depends on, what entry points the +distribution advertises, and so on. + +* Menu: + +* Getting or Creating Distributions:: +* Distribution Attributes:: +* Distribution Methods:: + + +File: setuptools.info, Node: Getting or Creating Distributions, Next: Distribution Attributes, Up: Distribution Objects + +3.2.6.1 Getting or Creating Distributions +......................................... + +Most commonly, you’ll obtain ‘Distribution’ objects from a ‘WorkingSet’ +or an ‘Environment’. (See the sections above on *note WorkingSet +Objects: 7b. and *note Environment Objects: 81, which are containers for +active distributions and available distributions, respectively.) You +can also obtain ‘Distribution’ objects from one of these high-level +APIs: + +‘find_distributions(path_item, only=False)’ + + Yield distributions accessible via ‘path_item’. If ‘only’ is true, + yield only distributions whose ‘location’ is equal to ‘path_item’. + In other words, if ‘only’ is true, this yields any distributions + that would be importable if ‘path_item’ were on ‘sys.path’. If + ‘only’ is false, this also yields distributions that are “in” or + “under” ‘path_item’, but would not be importable unless their + locations were also added to ‘sys.path’. + +‘get_distribution(dist_spec)’ + + Return a ‘Distribution’ object for a given ‘Requirement’ or string. + If ‘dist_spec’ is already a ‘Distribution’ instance, it is + returned. If it is a ‘Requirement’ object or a string that can be + parsed into one, it is used to locate and activate a matching + distribution, which is then returned. + +However, if you’re creating specialized tools for working with +distributions, or creating a new distribution format, you may also need +to create ‘Distribution’ objects directly, using one of the three +constructors below. + +These constructors all take an optional ‘metadata’ argument, which is +used to access any resources or metadata associated with the +distribution. ‘metadata’ must be an object that implements the +‘IResourceProvider’ interface, or None. If it is None, an +‘EmptyProvider’ is used instead. ‘Distribution’ objects implement both +the *note IResourceProvider: 8b. and *note IMetadataProvider Methods: +8c. by delegating them to the ‘metadata’ object. + +‘Distribution.from_location(location, basename, metadata=None, **kw)’ (classmethod) + + Create a distribution for ‘location’, which must be a string such + as a URL, filename, or other string that might be used on + ‘sys.path’. ‘basename’ is a string naming the distribution, like + ‘Foo-1.2-py2.4.egg’. If ‘basename’ ends with ‘.egg’, then the + project’s name, version, python version and platform are extracted + from the filename and used to set those properties of the created + distribution. Any additional keyword arguments are forwarded to + the ‘Distribution()’ constructor. + +‘Distribution.from_filename(filename, metadata=None**kw)’ (classmethod) + + Create a distribution by parsing a local filename. This is a + shorter way of saying + ‘Distribution.from_location(normalize_path(filename), + os.path.basename(filename), metadata)’. In other words, it creates + a distribution whose location is the normalize form of the + filename, parsing name and version information from the base + portion of the filename. Any additional keyword arguments are + forwarded to the ‘Distribution()’ constructor. + +‘Distribution(location,metadata,project_name,version,py_version,platform,precedence)’ + + Create a distribution by setting its properties. All arguments are + optional and default to None, except for ‘py_version’ (which + defaults to the current Python version) and ‘precedence’ (which + defaults to ‘EGG_DIST’; for more details see ‘precedence’ under + *note Distribution Attributes: 8d. below). Note that it’s usually + easier to use the ‘from_filename()’ or ‘from_location()’ + constructors than to specify all these arguments individually. + + +File: setuptools.info, Node: Distribution Attributes, Next: Distribution Methods, Prev: Getting or Creating Distributions, Up: Distribution Objects + +3.2.6.2 ‘Distribution’ Attributes +................................. + +location + + A string indicating the distribution’s location. For an importable + distribution, this is the string that would be added to ‘sys.path’ + to make it actively importable. For non-importable distributions, + this is simply a filename, URL, or other way of locating the + distribution. + +project_name + + A string, naming the project that this distribution is for. + Project names are defined by a project’s setup script, and they are + used to identify projects on PyPI. When a ‘Distribution’ is + constructed, the ‘project_name’ argument is passed through the + ‘safe_name()’ utility function to filter out any unacceptable + characters. + +key + + ‘dist.key’ is short for ‘dist.project_name.lower()’. It’s used for + case-insensitive comparison and indexing of distributions by + project name. + +extras + + A list of strings, giving the names of extra features defined by + the project’s dependency list (the ‘extras_require’ argument + specified in the project’s setup script). + +version + + A string denoting what release of the project this distribution + contains. When a ‘Distribution’ is constructed, the ‘version’ + argument is passed through the ‘safe_version()’ utility function to + filter out any unacceptable characters. If no ‘version’ is + specified at construction time, then attempting to access this + attribute later will cause the ‘Distribution’ to try to discover + its version by reading its ‘PKG-INFO’ metadata file. If ‘PKG-INFO’ + is unavailable or can’t be parsed, ‘ValueError’ is raised. + +parsed_version + + The ‘parsed_version’ is an object representing a “parsed” form of + the distribution’s ‘version’. ‘dist.parsed_version’ is a shortcut + for calling ‘parse_version(dist.version)’. It is used to compare + or sort distributions by version. (See the *note Parsing + Utilities: 8e. section below for more information on the + ‘parse_version()’ function.) Note that accessing ‘parsed_version’ + may result in a ‘ValueError’ if the ‘Distribution’ was constructed + without a ‘version’ and without ‘metadata’ capable of supplying the + missing version info. + +py_version + + The major/minor Python version the distribution supports, as a + string. For example, “2.7” or “3.4”. The default is the current + version of Python. + +platform + + A string representing the platform the distribution is intended + for, or ‘None’ if the distribution is “pure Python” and therefore + cross-platform. See *note Platform Utilities: 8f. below for more + information on platform strings. + +precedence + + A distribution’s ‘precedence’ is used to determine the relative + order of two distributions that have the same ‘project_name’ and + ‘parsed_version’. The default precedence is + ‘pkg_resources.EGG_DIST’, which is the highest (i.e. most + preferred) precedence. The full list of predefined precedences, + from most preferred to least preferred, is: ‘EGG_DIST’, + ‘BINARY_DIST’, ‘SOURCE_DIST’, ‘CHECKOUT_DIST’, and ‘DEVELOP_DIST’. + Normally, precedences other than ‘EGG_DIST’ are used only by the + ‘setuptools.package_index’ module, when sorting distributions found + in a package index to determine their suitability for installation. + “System” and “Development” eggs (i.e., ones that use the + ‘.egg-info’ format), however, are automatically given a precedence + of ‘DEVELOP_DIST’. + + +File: setuptools.info, Node: Distribution Methods, Prev: Distribution Attributes, Up: Distribution Objects + +3.2.6.3 ‘Distribution’ Methods +.............................. + +‘activate(path=None)’ + + Ensure distribution is importable on ‘path’. If ‘path’ is None, + ‘sys.path’ is used instead. This ensures that the distribution’s + ‘location’ is in the ‘path’ list, and it also performs any + necessary namespace package fixups or declarations. (That is, if + the distribution contains namespace packages, this method ensures + that they are declared, and that the distribution’s contents for + those namespace packages are merged with the contents provided by + any other active distributions. See the section above on *note + Namespace Package Support: 79. for more information.) + + ‘pkg_resources’ adds a notification callback to the global + ‘working_set’ that ensures this method is called whenever a + distribution is added to it. Therefore, you should not normally + need to explicitly call this method. (Note that this means that + namespace packages on ‘sys.path’ are always imported as soon as + ‘pkg_resources’ is, which is another reason why namespace packages + should not contain any code or import statements.) + +‘as_requirement()’ + + Return a ‘Requirement’ instance that matches this distribution’s + project name and version. + +‘requires(extras=())’ + + List the ‘Requirement’ objects that specify this distribution’s + dependencies. If ‘extras’ is specified, it should be a sequence of + names of “extras” defined by the distribution, and the list + returned will then include any dependencies needed to support the + named “extras”. + +‘clone(**kw)’ + + Create a copy of the distribution. Any supplied keyword arguments + override the corresponding argument to the ‘Distribution()’ + constructor, allowing you to change some of the copied + distribution’s attributes. + +‘egg_name()’ + + Return what this distribution’s standard filename should be, not + including the “.egg” extension. For example, a distribution for + project “Foo” version 1.2 that runs on Python 2.3 for Windows would + have an ‘egg_name()’ of ‘Foo-1.2-py2.3-win32’. Any dashes in the + name or version are converted to underscores. + (‘Distribution.from_location()’ will convert them back when parsing + a “.egg” file name.) + +‘__cmp__(other)’, ‘__hash__()’ + + Distribution objects are hashed and compared on the basis of their + parsed version and precedence, followed by their key (lowercase + project name), location, Python version, and platform. + +The following methods are used to access ‘EntryPoint’ objects advertised +by the distribution. See the section above on *note Entry Points: 7f. +for more detailed information about these operations: + +‘get_entry_info(group, name)’ + + Return the ‘EntryPoint’ object for ‘group’ and ‘name’, or None if + no such point is advertised by this distribution. + +‘get_entry_map(group=None)’ + + Return the entry point map for ‘group’. If ‘group’ is None, return + a dictionary mapping group names to entry point maps for all + groups. (An entry point map is a dictionary of entry point names + to ‘EntryPoint’ objects.) + +‘load_entry_point(group, name)’ + + Short for ‘get_entry_info(group, name).load()’. Returns the object + advertised by the named entry point, or raises ‘ImportError’ if the + entry point isn’t advertised by this distribution, or there is some + other import problem. + +In addition to the above methods, ‘Distribution’ objects also implement +all of the *note IResourceProvider: 8b. and *note IMetadataProvider +Methods: 8c. (which are documented in later sections): + + * ‘has_metadata(name)’ + + * ‘metadata_isdir(name)’ + + * ‘metadata_listdir(name)’ + + * ‘get_metadata(name)’ + + * ‘get_metadata_lines(name)’ + + * ‘run_script(script_name, namespace)’ + + * ‘get_resource_filename(manager, resource_name)’ + + * ‘get_resource_stream(manager, resource_name)’ + + * ‘get_resource_string(manager, resource_name)’ + + * ‘has_resource(resource_name)’ + + * ‘resource_isdir(resource_name)’ + + * ‘resource_listdir(resource_name)’ + +If the distribution was created with a ‘metadata’ argument, these +resource and metadata access methods are all delegated to that +‘metadata’ provider. Otherwise, they are delegated to an +‘EmptyProvider’, so that the distribution will appear to have no +resources or metadata. This delegation approach is used so that +supporting custom importers or new distribution formats can be done +simply by creating an appropriate *note IResourceProvider: 8b. +implementation; see the section below on *note Supporting Custom +Importers: 7a. for more details. + + +File: setuptools.info, Node: ResourceManager API, Next: Metadata API, Prev: Distribution Objects, Up: API Reference + +3.2.7 ‘ResourceManager’ API +--------------------------- + +The ‘ResourceManager’ class provides uniform access to package +resources, whether those resources exist as files and directories or are +compressed in an archive of some kind. + +Normally, you do not need to create or explicitly manage +‘ResourceManager’ instances, as the ‘pkg_resources’ module creates a +global instance for you, and makes most of its methods available as +top-level names in the ‘pkg_resources’ module namespace. So, for +example, this code actually calls the ‘resource_string()’ method of the +global ‘ResourceManager’: + + import pkg_resources + my_data = pkg_resources.resource_string(__name__, "foo.dat") + +Thus, you can use the APIs below without needing an explicit +‘ResourceManager’ instance; just import and use them as needed. + +* Menu: + +* Basic Resource Access:: +* Resource Extraction:: +* “Provider” Interface:: + + +File: setuptools.info, Node: Basic Resource Access, Next: Resource Extraction, Up: ResourceManager API + +3.2.7.1 Basic Resource Access +............................. + +In the following methods, the ‘package_or_requirement’ argument may be +either a Python package/module name (e.g. ‘foo.bar’) or a ‘Requirement’ +instance. If it is a package or module name, the named module or +package must be importable (i.e., be in a distribution or directory on +‘sys.path’), and the ‘resource_name’ argument is interpreted relative to +the named package. (Note that if a module name is used, then the +resource name is relative to the package immediately containing the +named module. Also, you should not use use a namespace package name, +because a namespace package can be spread across multiple distributions, +and is therefore ambiguous as to which distribution should be searched +for the resource.) + +If it is a ‘Requirement’, then the requirement is automatically resolved +(searching the current ‘Environment’ if necessary) and a matching +distribution is added to the ‘WorkingSet’ and ‘sys.path’ if one was not +already present. (Unless the ‘Requirement’ can’t be satisfied, in which +case an exception is raised.) The ‘resource_name’ argument is then +interpreted relative to the root of the identified distribution; i.e. +its first path segment will be treated as a peer of the top-level +modules or packages in the distribution. + +Note that resource names must be ‘/’-separated paths rooted at the +package, cannot contain relative names like ‘".."’, and cannot be +absolute. Do `not' use ‘os.path’ routines to manipulate resource paths, +as they are `not' filesystem paths. + +‘resource_exists(package_or_requirement, resource_name)’ + + Does the named resource exist? Return ‘True’ or ‘False’ + accordingly. + +‘resource_stream(package_or_requirement, resource_name)’ + + Return a readable file-like object for the specified resource; it + may be an actual file, a ‘StringIO’, or some similar object. The + stream is in “binary mode”, in the sense that whatever bytes are in + the resource will be read as-is. + +‘resource_string(package_or_requirement, resource_name)’ + + Return the specified resource as a string. The resource is read in + binary fashion, such that the returned string contains exactly the + bytes that are stored in the resource. + +‘resource_isdir(package_or_requirement, resource_name)’ + + Is the named resource a directory? Return ‘True’ or ‘False’ + accordingly. + +‘resource_listdir(package_or_requirement, resource_name)’ + + List the contents of the named resource directory, just like + ‘os.listdir’ except that it works even if the resource is in a + zipfile. + +Note that only ‘resource_exists()’ and ‘resource_isdir()’ are +insensitive as to the resource type. You cannot use +‘resource_listdir()’ on a file resource, and you can’t use +‘resource_string()’ or ‘resource_stream()’ on directory resources. +Using an inappropriate method for the resource type may result in an +exception or undefined behavior, depending on the platform and +distribution format involved. + + +File: setuptools.info, Node: Resource Extraction, Next: “Provider” Interface, Prev: Basic Resource Access, Up: ResourceManager API + +3.2.7.2 Resource Extraction +........................... + +‘resource_filename(package_or_requirement, resource_name)’ + + Sometimes, it is not sufficient to access a resource in string or + stream form, and a true filesystem filename is needed. In such + cases, you can use this method (or module-level function) to obtain + a filename for a resource. If the resource is in an archive + distribution (such as a zipped egg), it will be extracted to a + cache directory, and the filename within the cache will be + returned. If the named resource is a directory, then all resources + within that directory (including subdirectories) are also + extracted. If the named resource is a C extension or “eager + resource” (see the ‘setuptools’ documentation for details), then + all C extensions and eager resources are extracted at the same + time. + + Archived resources are extracted to a cache location that can be + managed by the following two methods: + +‘set_extraction_path(path)’ + + Set the base path where resources will be extracted to, if needed. + + If you do not call this routine before any extractions take place, + the path defaults to the return value of ‘get_default_cache()’. + (Which is based on the ‘PYTHON_EGG_CACHE’ environment variable, + with various platform-specific fallbacks. See that routine’s + documentation for more details.) + + Resources are extracted to subdirectories of this path based upon + information given by the resource provider. You may set this to a + temporary directory, but then you must call ‘cleanup_resources()’ + to delete the extracted files when done. There is no guarantee + that ‘cleanup_resources()’ will be able to remove all extracted + files. (On Windows, for example, you can’t unlink .pyd or .dll + files that are still in use.) + + Note that you may not change the extraction path for a given + resource manager once resources have been extracted, unless you + first call ‘cleanup_resources()’. + +‘cleanup_resources(force=False)’ + + Delete all extracted resource files and directories, returning a + list of the file and directory names that could not be successfully + removed. This function does not have any concurrency protection, + so it should generally only be called when the extraction path is a + temporary directory exclusive to a single process. This method is + not automatically called; you must call it explicitly or register + it as an ‘atexit’ function if you wish to ensure cleanup of a + temporary directory used for extractions. + + +File: setuptools.info, Node: “Provider” Interface, Prev: Resource Extraction, Up: ResourceManager API + +3.2.7.3 “Provider” Interface +............................ + +If you are implementing an ‘IResourceProvider’ and/or +‘IMetadataProvider’ for a new distribution archive format, you may need +to use the following ‘IResourceManager’ methods to co-ordinate +extraction of resources to the filesystem. If you’re not implementing +an archive format, however, you have no need to use these methods. +Unlike the other methods listed above, they are `not' available as +top-level functions tied to the global ‘ResourceManager’; you must +therefore have an explicit ‘ResourceManager’ instance to use them. + +‘get_cache_path(archive_name, names=())’ + + Return absolute location in cache for ‘archive_name’ and ‘names’ + + The parent directory of the resulting path will be created if it + does not already exist. ‘archive_name’ should be the base filename + of the enclosing egg (which may not be the name of the enclosing + zipfile!), including its “.egg” extension. ‘names’, if provided, + should be a sequence of path name parts “under” the egg’s + extraction location. + + This method should only be called by resource providers that need + to obtain an extraction location, and only for names they intend to + extract, as it tracks the generated names for possible cleanup + later. + +‘extraction_error()’ + + Raise an ‘ExtractionError’ describing the active exception as + interfering with the extraction process. You should call this if + you encounter any OS errors extracting the file to the cache path; + it will format the operating system exception for you, and add + other information to the ‘ExtractionError’ instance that may be + needed by programs that want to wrap or handle extraction errors + themselves. + +‘postprocess(tempname, filename)’ + + Perform any platform-specific postprocessing of ‘tempname’. + Resource providers should call this method ONLY after successfully + extracting a compressed resource. They must NOT call it on + resources that are already in the filesystem. + + ‘tempname’ is the current (temporary) name of the file, and + ‘filename’ is the name it will be renamed to by the caller after + this routine returns. + + +File: setuptools.info, Node: Metadata API, Next: Exceptions, Prev: ResourceManager API, Up: API Reference + +3.2.8 Metadata API +------------------ + +The metadata API is used to access metadata resources bundled in a +pluggable distribution. Metadata resources are virtual files or +directories containing information about the distribution, such as might +be used by an extensible application or framework to connect “plugins”. +Like other kinds of resources, metadata resource names are ‘/’-separated +and should not contain ‘..’ or begin with a ‘/’. You should not use +‘os.path’ routines to manipulate resource paths. + +The metadata API is provided by objects implementing the +‘IMetadataProvider’ or ‘IResourceProvider’ interfaces. ‘Distribution’ +objects implement this interface, as do objects returned by the +‘get_provider()’ function: + +‘get_provider(package_or_requirement)’ + + If a package name is supplied, return an ‘IResourceProvider’ for + the package. If a ‘Requirement’ is supplied, resolve it by + returning a ‘Distribution’ from the current working set (searching + the current ‘Environment’ if necessary and adding the newly found + ‘Distribution’ to the working set). If the named package can’t be + imported, or the ‘Requirement’ can’t be satisfied, an exception is + raised. + + NOTE: if you use a package name rather than a ‘Requirement’, the + object you get back may not be a pluggable distribution, depending + on the method by which the package was installed. In particular, + “development” packages and “single-version externally-managed” + packages do not have any way to map from a package name to the + corresponding project’s metadata. Do not write code that passes a + package name to ‘get_provider()’ and then tries to retrieve project + metadata from the returned object. It may appear to work when the + named package is in an ‘.egg’ file or directory, but it will fail + in other installation scenarios. If you want project metadata, you + need to ask for a `project', not a package. + +* Menu: + +* IMetadataProvider Methods:: + + +File: setuptools.info, Node: IMetadataProvider Methods, Up: Metadata API + +3.2.8.1 ‘IMetadataProvider’ Methods +................................... + +The methods provided by objects (such as ‘Distribution’ instances) that +implement the ‘IMetadataProvider’ or ‘IResourceProvider’ interfaces are: + +‘has_metadata(name)’ + + Does the named metadata resource exist? + +‘metadata_isdir(name)’ + + Is the named metadata resource a directory? + +‘metadata_listdir(name)’ + + List of metadata names in the directory (like ‘os.listdir()’) + +‘get_metadata(name)’ + + Return the named metadata resource as a string. The data is read + in binary mode; i.e., the exact bytes of the resource file are + returned. + +‘get_metadata_lines(name)’ + + Yield named metadata resource as list of non-blank non-comment + lines. This is short for calling + ‘yield_lines(provider.get_metadata(name))’. See the section on + *note yield_lines(): 95. below for more information on the syntax + it recognizes. + +‘run_script(script_name, namespace)’ + + Execute the named script in the supplied namespace dictionary. + Raises ‘ResolutionError’ if there is no script by that name in the + ‘scripts’ metadata directory. ‘namespace’ should be a Python + dictionary, usually a module dictionary if the script is being run + as a module. + + +File: setuptools.info, Node: Exceptions, Next: Supporting Custom Importers, Prev: Metadata API, Up: API Reference + +3.2.9 Exceptions +---------------- + +‘pkg_resources’ provides a simple exception hierarchy for problems that +may occur when processing requests to locate and activate packages: + + ResolutionError + DistributionNotFound + VersionConflict + UnknownExtra + + ExtractionError + +‘ResolutionError’ + + This class is used as a base class for the other three exceptions, + so that you can catch all of them with a single “except” clause. + It is also raised directly for miscellaneous requirement-resolution + problems like trying to run a script that doesn’t exist in the + distribution it was requested from. + +‘DistributionNotFound’ + + A distribution needed to fulfill a requirement could not be found. + +‘VersionConflict’ + + The requested version of a project conflicts with an + already-activated version of the same project. + +‘UnknownExtra’ + + One of the “extras” requested was not recognized by the + distribution it was requested from. + +‘ExtractionError’ + + A problem occurred extracting a resource to the Python Egg cache. + The following attributes are available on instances of this + exception: + + manager + + The resource manager that raised this exception + + cache_path + + The base directory for resource extraction + + original_error + + The exception instance that caused extraction to fail + + +File: setuptools.info, Node: Supporting Custom Importers, Next: Utility Functions, Prev: Exceptions, Up: API Reference + +3.2.10 Supporting Custom Importers +---------------------------------- + +By default, ‘pkg_resources’ supports normal filesystem imports, and +‘zipimport’ importers. If you wish to use the ‘pkg_resources’ features +with other (PEP 302-compatible) importers or module loaders, you may +need to register various handlers and support functions using these +APIs: + +‘register_finder(importer_type, distribution_finder)’ + + Register ‘distribution_finder’ to find distributions in ‘sys.path’ + items. ‘importer_type’ is the type or class of a PEP 302 + “Importer” (‘sys.path’ item handler), and ‘distribution_finder’ is + a callable that, when passed a path item, the importer instance, + and an ‘only’ flag, yields ‘Distribution’ instances found under + that path item. (The ‘only’ flag, if true, means the finder should + yield only ‘Distribution’ objects whose ‘location’ is equal to the + path item provided.) + + See the source of the ‘pkg_resources.find_on_path’ function for an + example finder function. + +‘register_loader_type(loader_type, provider_factory)’ + + Register ‘provider_factory’ to make ‘IResourceProvider’ objects for + ‘loader_type’. ‘loader_type’ is the type or class of a PEP 302 + ‘module.__loader__’, and ‘provider_factory’ is a function that, + when passed a module object, returns an *note IResourceProvider: + 8b. for that module, allowing it to be used with the *note + ResourceManager API: 35. + +‘register_namespace_handler(importer_type, namespace_handler)’ + + Register ‘namespace_handler’ to declare namespace packages for the + given ‘importer_type’. ‘importer_type’ is the type or class of a + PEP 302 “importer” (sys.path item handler), and ‘namespace_handler’ + is a callable with a signature like this: + + def namespace_handler(importer, path_entry, moduleName, module): + # return a path_entry to use for child packages + + Namespace handlers are only called if the relevant importer object + has already agreed that it can handle the relevant path item. The + handler should only return a subpath if the module ‘__path__’ does + not already contain an equivalent subpath. Otherwise, it should + return None. + + For an example namespace handler, see the source of the + ‘pkg_resources.file_ns_handler’ function, which is used for both + zipfile importing and regular importing. + +* Menu: + +* IResourceProvider:: +* Built-in Resource Providers:: + + +File: setuptools.info, Node: IResourceProvider, Next: Built-in Resource Providers, Up: Supporting Custom Importers + +3.2.10.1 IResourceProvider +.......................... + +‘IResourceProvider’ is an abstract class that documents what methods are +required of objects returned by a ‘provider_factory’ registered with +‘register_loader_type()’. ‘IResourceProvider’ is a subclass of +‘IMetadataProvider’, so objects that implement this interface must also +implement all of the *note IMetadataProvider Methods: 8c. as well as the +methods shown here. The ‘manager’ argument to the methods below must be +an object that supports the full *note ResourceManager API: 35. +documented above. + +‘get_resource_filename(manager, resource_name)’ + + Return a true filesystem path for ‘resource_name’, coordinating the + extraction with ‘manager’, if the resource must be unpacked to the + filesystem. + +‘get_resource_stream(manager, resource_name)’ + + Return a readable file-like object for ‘resource_name’. + +‘get_resource_string(manager, resource_name)’ + + Return a string containing the contents of ‘resource_name’. + +‘has_resource(resource_name)’ + + Does the package contain the named resource? + +‘resource_isdir(resource_name)’ + + Is the named resource a directory? Return a false value if the + resource does not exist or is not a directory. + +‘resource_listdir(resource_name)’ + + Return a list of the contents of the resource directory, ala + ‘os.listdir()’. Requesting the contents of a non-existent + directory may raise an exception. + +Note, by the way, that your provider classes need not (and should not) +subclass ‘IResourceProvider’ or ‘IMetadataProvider’! These classes +exist solely for documentation purposes and do not provide any useful +implementation code. You may instead wish to subclass one of the *note +built-in resource providers: 97. + + +File: setuptools.info, Node: Built-in Resource Providers, Prev: IResourceProvider, Up: Supporting Custom Importers + +3.2.10.2 Built-in Resource Providers +.................................... + +‘pkg_resources’ includes several provider classes that are automatically +used where appropriate. Their inheritance tree looks like this: + + NullProvider + EggProvider + DefaultProvider + PathMetadata + ZipProvider + EggMetadata + EmptyProvider + FileMetadata + +‘NullProvider’ + + This provider class is just an abstract base that provides for + common provider behaviors (such as running scripts), given a + definition for just a few abstract methods. + +‘EggProvider’ + + This provider class adds in some egg-specific features that are + common to zipped and unzipped eggs. + +‘DefaultProvider’ + + This provider class is used for unpacked eggs and “plain old + Python” filesystem modules. + +‘ZipProvider’ + + This provider class is used for all zipped modules, whether they + are eggs or not. + +‘EmptyProvider’ + + This provider class always returns answers consistent with a + provider that has no metadata or resources. ‘Distribution’ objects + created without a ‘metadata’ argument use an instance of this + provider class instead. Since all ‘EmptyProvider’ instances are + equivalent, there is no need to have more than one instance. + ‘pkg_resources’ therefore creates a global instance of this class + under the name ‘empty_provider’, and you may use it if you have + need of an ‘EmptyProvider’ instance. + +‘PathMetadata(path, egg_info)’ + + Create an ‘IResourceProvider’ for a filesystem-based distribution, + where ‘path’ is the filesystem location of the importable modules, + and ‘egg_info’ is the filesystem location of the distribution’s + metadata directory. ‘egg_info’ should usually be the ‘EGG-INFO’ + subdirectory of ‘path’ for an “unpacked egg”, and a + ‘ProjectName.egg-info’ subdirectory of ‘path’ for a “development + egg”. However, other uses are possible for custom purposes. + +‘EggMetadata(zipimporter)’ + + Create an ‘IResourceProvider’ for a zipfile-based distribution. + The ‘zipimporter’ should be a ‘zipimport.zipimporter’ instance, and + may represent a “basket” (a zipfile containing multiple “.egg” + subdirectories) a specific egg `within' a basket, or a zipfile egg + (where the zipfile itself is a “.egg”). It can also be a + combination, such as a zipfile egg that also contains other eggs. + +‘FileMetadata(path_to_pkg_info)’ + + Create an ‘IResourceProvider’ that provides exactly one metadata + resource: ‘PKG-INFO’. The supplied path should be a distutils + PKG-INFO file. This is basically the same as an ‘EmptyProvider’, + except that requests for ‘PKG-INFO’ will be answered using the + contents of the designated file. (This provider is used to wrap + ‘.egg-info’ files installed by vendor-supplied system packages.) + + +File: setuptools.info, Node: Utility Functions, Prev: Supporting Custom Importers, Up: API Reference + +3.2.11 Utility Functions +------------------------ + +In addition to its high-level APIs, ‘pkg_resources’ also includes +several generally-useful utility routines. These routines are used to +implement the high-level APIs, but can also be quite useful by +themselves. + +* Menu: + +* Parsing Utilities:: +* Platform Utilities:: +* PEP 302 Utilities:: +* File/Path Utilities:: +* History:: + + +File: setuptools.info, Node: Parsing Utilities, Next: Platform Utilities, Up: Utility Functions + +3.2.11.1 Parsing Utilities +.......................... + +‘parse_version(version)’ + + Parsed a project’s version string as defined by PEP 440. The + returned value will be an object that represents the version. + These objects may be compared to each other and sorted. The + sorting algorithm is as defined by PEP 440 with the addition that + any version which is not a valid PEP 440 version will be considered + less than any valid PEP 440 version and the invalid versions will + continue sorting using the original algorithm. + +‘yield_lines(strs)’ + + Yield non-empty/non-comment lines from a string/unicode or a + possibly- nested sequence thereof. If ‘strs’ is an instance of + ‘basestring’, it is split into lines, and each non-blank, + non-comment line is yielded after stripping leading and trailing + whitespace. (Lines whose first non-blank character is ‘#’ are + considered comment lines.) + + If ‘strs’ is not an instance of ‘basestring’, it is iterated over, + and each item is passed recursively to ‘yield_lines()’, so that an + arbitrarily nested sequence of strings, or sequences of sequences + of strings can be flattened out to the lines contained therein. So + for example, passing a file object or a list of strings to + ‘yield_lines’ will both work. (Note that between each string in a + sequence of strings there is assumed to be an implicit line break, + so lines cannot bridge two strings in a sequence.) + + This routine is used extensively by ‘pkg_resources’ to parse + metadata and file formats of various kinds, and most other + ‘pkg_resources’ parsing functions that yield multiple values will + use it to break up their input. However, this routine is + idempotent, so calling ‘yield_lines()’ on the output of another + call to ‘yield_lines()’ is completely harmless. + +‘split_sections(strs)’ + + Split a string (or possibly-nested iterable thereof), yielding + ‘(section, content)’ pairs found using an ‘.ini’-like syntax. Each + ‘section’ is a whitespace-stripped version of the section name + (“‘[section]’”) and each ‘content’ is a list of stripped lines + excluding blank lines and comment-only lines. If there are any + non-blank, non-comment lines before the first section header, + they’re yielded in a first ‘section’ of ‘None’. + + This routine uses ‘yield_lines()’ as its front end, so you can pass + in anything that ‘yield_lines()’ accepts, such as an open text + file, string, or sequence of strings. ‘ValueError’ is raised if a + malformed section header is found (i.e. a line starting with ‘[’ + but not ending with ‘]’). + + Note that this simplistic parser assumes that any line whose first + nonblank character is ‘[’ is a section heading, so it can’t support + .ini format variations that allow ‘[’ as the first nonblank + character on other lines. + +‘safe_name(name)’ + + Return a “safe” form of a project’s name, suitable for use in a + ‘Requirement’ string, as a distribution name, or a PyPI project + name. All non-alphanumeric runs are condensed to single “-” + characters, such that a name like “The $$$ Tree” becomes + “The-Tree”. Note that if you are generating a filename from this + value you should combine it with a call to ‘to_filename()’ so all + dashes (“-“) are replaced by underscores (“_”). See + ‘to_filename()’. + +‘safe_version(version)’ + + This will return the normalized form of any PEP 440 version. If + the version string is not PEP 440 compatible, this function behaves + similar to ‘safe_name()’ except that spaces in the input become + dots, and dots are allowed to exist in the output. As with + ‘safe_name()’, if you are generating a filename from this you + should replace any “-” characters in the output with underscores. + +‘safe_extra(extra)’ + + Return a “safe” form of an extra’s name, suitable for use in a + requirement string or a setup script’s ‘extras_require’ keyword. + This routine is similar to ‘safe_name()’ except that + non-alphanumeric runs are replaced by a single underbar (‘_’), and + the result is lowercased. + +‘to_filename(name_or_version)’ + + Escape a name or version string so it can be used in a + dash-separated filename (or ‘#egg=name-version’ tag) without + ambiguity. You should only pass in values that were returned by + ‘safe_name()’ or ‘safe_version()’. + + +File: setuptools.info, Node: Platform Utilities, Next: PEP 302 Utilities, Prev: Parsing Utilities, Up: Utility Functions + +3.2.11.2 Platform Utilities +........................... + +‘get_build_platform()’ + + Return this platform’s identifier string. For Windows, the return + value is ‘"win32"’, and for macOS it is a string of the form + ‘"macosx-10.4-ppc"’. All other platforms return the same + uname-based string that the ‘distutils.util.get_platform()’ + function returns. This string is the minimum platform version + required by distributions built on the local machine. (Backward + compatibility note: setuptools versions prior to 0.6b1 called this + function ‘get_platform()’, and the function is still available + under that name for backward compatibility reasons.) + +‘get_supported_platform()’ (New in 0.6b1) + + This is the similar to ‘get_build_platform()’, but is the maximum + platform version that the local machine supports. You will usually + want to use this value as the ‘provided’ argument to the + ‘compatible_platforms()’ function. + +‘compatible_platforms(provided, required)’ + + Return true if a distribution built on the ‘provided’ platform may + be used on the ‘required’ platform. If either platform value is + ‘None’, it is considered a wildcard, and the platforms are + therefore compatible. Likewise, if the platform strings are equal, + they’re also considered compatible, and ‘True’ is returned. + Currently, the only non-equal platform strings that are considered + compatible are macOS platform strings with the same hardware type + (e.g. ‘ppc’) and major version (e.g. ‘10’) with the ‘provided’ + platform’s minor version being less than or equal to the ‘required’ + platform’s minor version. + +‘get_default_cache()’ + + Determine the default cache location for extracting resources from + zipped eggs. This routine returns the ‘PYTHON_EGG_CACHE’ + environment variable, if set. Otherwise, on Windows, it returns a + “Python-Eggs” subdirectory of the user’s “Application Data” + directory. On all other systems, it returns + ‘os.path.expanduser("~/.python-eggs")’ if ‘PYTHON_EGG_CACHE’ is not + set. + + +File: setuptools.info, Node: PEP 302 Utilities, Next: File/Path Utilities, Prev: Platform Utilities, Up: Utility Functions + +3.2.11.3 PEP 302 Utilities +.......................... + +‘get_importer(path_item)’ + + A deprecated alias for ‘pkgutil.get_importer()’ + + +File: setuptools.info, Node: File/Path Utilities, Next: History, Prev: PEP 302 Utilities, Up: Utility Functions + +3.2.11.4 File/Path Utilities +............................ + +‘ensure_directory(path)’ + + Ensure that the parent directory (‘os.path.dirname’) of ‘path’ + actually exists, using ‘os.makedirs()’ if necessary. + +‘normalize_path(path)’ + + Return a “normalized” version of ‘path’, such that two paths + represent the same filesystem location if they have equal + ‘normalized_path()’ values. Specifically, this is a shortcut for + calling ‘os.path.realpath’ and ‘os.path.normcase’ on ‘path’. + Unfortunately, on certain platforms (notably Cygwin and macOS) the + ‘normcase’ function does not accurately reflect the platform’s + case-sensitivity, so there is always the possibility of two + apparently-different paths being equal on such platforms. + + +File: setuptools.info, Node: History, Prev: File/Path Utilities, Up: Utility Functions + +3.2.11.5 History +................ + +0.6c9 + + * Fix ‘resource_listdir('')’ always returning an empty list for + zipped eggs. + +0.6c7 + + * Fix package precedence problem where single-version eggs + installed in ‘site-packages’ would take precedence over ‘.egg’ + files (or directories) installed in ‘site-packages’. + +0.6c6 + + * Fix extracted C extensions not having executable permissions + under Cygwin. + + * Allow ‘.egg-link’ files to contain relative paths. + + * Fix cache dir defaults on Windows when multiple environment + vars are needed to construct a path. + +0.6c4 + + * Fix “dev” versions being considered newer than release + candidates. + +0.6c3 + + * Python 2.5 compatibility fixes. + +0.6c2 + + * Fix a problem with eggs specified directly on ‘PYTHONPATH’ on + case-insensitive filesystems possibly not showing up in the + default working set, due to differing normalizations of + ‘sys.path’ entries. + +0.6b3 + + * Fixed a duplicate path insertion problem on case-insensitive + filesystems. + +0.6b1 + + * Split ‘get_platform()’ into ‘get_supported_platform()’ and + ‘get_build_platform()’ to work around a Mac versioning problem + that caused the behavior of ‘compatible_platforms()’ to be + platform specific. + + * Fix entry point parsing when a standalone module name has + whitespace between it and the extras. + +0.6a11 + + * Added ‘ExtractionError’ and + ‘ResourceManager.extraction_error()’ so that cache permission + problems get a more user-friendly explanation of the problem, + and so that programs can catch and handle extraction errors if + they need to. + +0.6a10 + + * Added the ‘extras’ attribute to ‘Distribution’, the + ‘find_plugins()’ method to ‘WorkingSet’, and the ‘__add__()’ + and ‘__iadd__()’ methods to ‘Environment’. + + * ‘safe_name()’ now allows dots in project names. + + * There is a new ‘to_filename()’ function that escapes project + names and versions for safe use in constructing egg filenames + from a Distribution object’s metadata. + + * Added ‘Distribution.clone()’ method, and keyword argument + support to other ‘Distribution’ constructors. + + * Added the ‘DEVELOP_DIST’ precedence, and automatically assign + it to eggs using ‘.egg-info’ format. + +0.6a9 + + * Don’t raise an error when an invalid (unfinished) distribution + is found unless absolutely necessary. Warn about skipping + invalid/unfinished eggs when building an Environment. + + * Added support for ‘.egg-info’ files or directories with + version/platform information embedded in the filename, so that + system packagers have the option of including ‘PKG-INFO’ files + to indicate the presence of a system-installed egg, without + needing to use ‘.egg’ directories, zipfiles, or ‘.pth’ + manipulation. + + * Changed ‘parse_version()’ to remove dashes before pre-release + tags, so that ‘0.2-rc1’ is considered an `older' version than + ‘0.2’, and is equal to ‘0.2rc1’. The idea that a dash + `always' meant a post-release version was highly non-intuitive + to setuptools users and Python developers, who seem to want to + use ‘-rc’ version numbers a lot. + +0.6a8 + + * Fixed a problem with ‘WorkingSet.resolve()’ that prevented + version conflicts from being detected at runtime. + + * Improved runtime conflict warning message to identify a line + in the user’s program, rather than flagging the ‘warn()’ call + in ‘pkg_resources’. + + * Avoid giving runtime conflict warnings for namespace packages, + even if they were declared by a different package than the one + currently being activated. + + * Fix path insertion algorithm for case-insensitive filesystems. + + * Fixed a problem with nested namespace packages (e.g. + ‘peak.util’) not being set as an attribute of their parent + package. + +0.6a6 + + * Activated distributions are now inserted in ‘sys.path’ (and + the working set) just before the directory that contains them, + instead of at the end. This allows e.g. eggs in + ‘site-packages’ to override unmanaged modules in the same + location, and allows eggs found earlier on ‘sys.path’ to + override ones found later. + + * When a distribution is activated, it now checks whether any + contained non-namespace modules have already been imported and + issues a warning if a conflicting module has already been + imported. + + * Changed dependency processing so that it’s breadth-first, + allowing a depender’s preferences to override those of a + dependee, to prevent conflicts when a lower version is + acceptable to the dependee, but not the depender. + + * Fixed a problem extracting zipped files on Windows, when the + egg in question has had changed contents but still has the + same version number. + +0.6a4 + + * Fix a bug in ‘WorkingSet.resolve()’ that was introduced in + 0.6a3. + +0.6a3 + + * Added ‘safe_extra()’ parsing utility routine, and use it for + Requirement, EntryPoint, and Distribution objects’ extras + handling. + +0.6a1 + + * Enhanced performance of ‘require()’ and related operations + when all requirements are already in the working set, and + enhanced performance of directory scanning for distributions. + + * Fixed some problems using ‘pkg_resources’ w/PEP 302 loaders + other than ‘zipimport’, and the previously-broken “eager + resource” support. + + * Fixed ‘pkg_resources.resource_exists()’ not working correctly, + along with some other resource API bugs. + + * Many API changes and enhancements: + + * Added ‘EntryPoint’, ‘get_entry_map’, ‘load_entry_point’, + and ‘get_entry_info’ APIs for dynamic plugin discovery. + + * ‘list_resources’ is now ‘resource_listdir’ (and it + actually works) + + * Resource API functions like ‘resource_string()’ that + accepted a package name and resource name, will now also + accept a ‘Requirement’ object in place of the package + name (to allow access to non-package data files in an + egg). + + * ‘get_provider()’ will now accept a ‘Requirement’ instance + or a module name. If it is given a ‘Requirement’, it + will return a corresponding ‘Distribution’ (by calling + ‘require()’ if a suitable distribution isn’t already in + the working set), rather than returning a metadata and + resource provider for a specific module. (The difference + is in how resource paths are interpreted; supplying a + module name means resources path will be module-relative, + rather than relative to the distribution’s root.) + + * ‘Distribution’ objects now implement the + ‘IResourceProvider’ and ‘IMetadataProvider’ interfaces, + so you don’t need to reference the (no longer available) + ‘metadata’ attribute to get at these interfaces. + + * ‘Distribution’ and ‘Requirement’ both have a + ‘project_name’ attribute for the project name they refer + to. (Previously these were ‘name’ and ‘distname’ + attributes.) + + * The ‘path’ attribute of ‘Distribution’ objects is now + ‘location’, because it isn’t necessarily a filesystem + path (and hasn’t been for some time now). The ‘location’ + of ‘Distribution’ objects in the filesystem should always + be normalized using ‘pkg_resources.normalize_path()’; all + of the setuptools’ code that generates distributions from + the filesystem (including ‘Distribution.from_filename()’) + ensure this invariant, but if you use a more generic API + like ‘Distribution()’ or ‘Distribution.from_location()’ + you should take care that you don’t create a distribution + with an un-normalized filesystem path. + + * ‘Distribution’ objects now have an ‘as_requirement()’ + method that returns a ‘Requirement’ for the + distribution’s project name and version. + + * Distribution objects no longer have an ‘installed_on()’ + method, and the ‘install_on()’ method is now ‘activate()’ + (but may go away altogether soon). The ‘depends()’ + method has also been renamed to ‘requires()’, and + ‘InvalidOption’ is now ‘UnknownExtra’. + + * ‘find_distributions()’ now takes an additional argument + called ‘only’, that tells it to only yield distributions + whose location is the passed-in path. (It defaults to + False, so that the default behavior is unchanged.) + + * ‘AvailableDistributions’ is now called ‘Environment’, and + the ‘get()’, ‘__len__()’, and ‘__contains__()’ methods + were removed, because they weren’t particularly useful. + ‘__getitem__()’ no longer raises ‘KeyError’; it just + returns an empty list if there are no distributions for + the named project. + + * The ‘resolve()’ method of ‘Environment’ is now a method + of ‘WorkingSet’ instead, and the ‘best_match()’ method + now uses a working set instead of a path list as its + second argument. + + * There is a new ‘pkg_resources.add_activation_listener()’ + API that lets you register a callback for notifications + about distributions added to ‘sys.path’ (including the + distributions already on it). This is basically a hook + for extensible applications and frameworks to be able to + search for plugin metadata in distributions added at + runtime. + +0.5a13 + + * Fixed a bug in resource extraction from nested packages in a + zipped egg. + +0.5a12 + + * Updated extraction/cache mechanism for zipped resources to + avoid inter- process and inter-thread races during extraction. + The default cache location can now be set via the + ‘PYTHON_EGGS_CACHE’ environment variable, and the default + Windows cache is now a ‘Python-Eggs’ subdirectory of the + current user’s “Application Data” directory, if the + ‘PYTHON_EGGS_CACHE’ variable isn’t set. + +0.5a10 + + * Fix a problem with ‘pkg_resources’ being confused by + non-existent eggs on ‘sys.path’ (e.g. if a user deletes an + egg without removing it from the ‘easy-install.pth’ file). + + * Fix a problem with “basket” support in ‘pkg_resources’, where + egg-finding never actually went inside ‘.egg’ files. + + * Made ‘pkg_resources’ import the module you request resources + from, if it’s not already imported. + +0.5a4 + + * ‘pkg_resources.AvailableDistributions.resolve()’ and related + methods now accept an ‘installer’ argument: a callable taking + one argument, a ‘Requirement’ instance. The callable must + return a ‘Distribution’ object, or ‘None’ if no distribution + is found. This feature is used by EasyInstall to resolve + dependencies by recursively invoking itself. + +0.4a4 + + * Fix problems with ‘resource_listdir()’, ‘resource_isdir()’ and + resource directory extraction for zipped eggs. + +0.4a3 + + * Fixed scripts not being able to see a ‘__file__’ variable in + ‘__main__’ + + * Fixed a problem with ‘resource_isdir()’ implementation that + was introduced in 0.4a2. + +0.4a1 + + * Fixed a bug in requirements processing for exact versions + (i.e. ‘==’ and ‘!=’) when only one condition was included. + + * Added ‘safe_name()’ and ‘safe_version()’ APIs to clean up + handling of arbitrary distribution names and versions found on + PyPI. + +0.3a4 + + * ‘pkg_resources’ now supports resource directories, not just + the resources in them. In particular, there are + ‘resource_listdir()’ and ‘resource_isdir()’ APIs. + + * ‘pkg_resources’ now supports “egg baskets” – .egg zipfiles + which contain multiple distributions in subdirectories whose + names end with ‘.egg’. Having such a “basket” in a directory + on ‘sys.path’ is equivalent to having the individual eggs in + that directory, but the contained eggs can be individually + added (or not) to ‘sys.path’. Currently, however, there is no + automated way to create baskets. + + * Namespace package manipulation is now protected by the Python + import lock. + +0.3a1 + + * Initial release. + + +File: setuptools.info, Node: Keywords, Next: Roadmap, Prev: Package Discovery and Resource Access using pkg_resources, Up: Top + +4 Keywords +********** + +‘name’ + + A string specifying the name of the package. + +‘version’ + + A string specifying the version number of the package. + +‘description’ + + A string describing the package in a single line. + +‘long_description’ + + A string providing a longer description of the package. + +‘long_description_content_type’ + + A string specifying the content type is used for the + ‘long_description’ (e.g. ‘text/markdown’) + +‘author’ + + A string specifying the author of the package. + +‘author_email’ + + A string specifying the email address of the package author. + +‘maintainer’ + + A string specifying the name of the current maintainer, if + different from the author. Note that if the maintainer is + provided, setuptools will use it as the author in ‘PKG-INFO’. + +‘maintainer_email’ + + A string specifying the email address of the current maintainer, if + different from the author. + +‘url’ + + A string specifying the URL for the package homepage. + +‘download_url’ + + A string specifying the URL to download the package. + +‘packages’ + + A list of strings specifying the packages that setuptools will + manipulate. + +‘py_modules’ + + A list of strings specifying the modules that setuptools will + manipulate. + +‘scripts’ + + A list of strings specifying the standalone script files to be + built and installed. + +‘ext_package’ + + A string specifying the base package name for the extensions + provided by this package. + +‘ext_modules’ + + A list of instances of ‘setuptools.Extension’ providing the list of + Python extensions to be built. + +‘classifiers’ + + A list of strings describing the categories for the package. + +‘distclass’ + + A subclass of ‘Distribution’ to use. + +‘script_name’ + + A string specifying the name of the setup.py script – defaults to + ‘sys.argv[0]’ + +‘script_args’ + + A list of strings defining the arguments to supply to the setup + script. + +‘options’ + + A dictionary providing the default options for the setup script. + +‘license’ + + A string specifying the license of the package. + +‘keywords’ + + A list of strings or a comma-separated string providing descriptive + meta-data. See: PEP 0314(1). + +‘platforms’ + + A list of strings or comma-separated string. + +‘cmdclass’ + + A dictionary providing a mapping of command names to ‘Command’ + subclasses. + +‘data_files’ + + Warning: ‘data_files’ is deprecated. It does not work with + wheels, so it should be avoided. + + A list of strings specifying the data files to install. + +‘package_dir’ + + A dictionary providing a mapping of package to directory names. + +‘requires’ + + Warning: ‘requires’ is superseded by ‘install_requires’ and + should not be used anymore. + +‘obsoletes’ + + Warning: ‘obsoletes’ is currently ignored by ‘pip’. + + List of strings describing packages which this package renders + obsolete, meaning that the two projects should not be installed at + the same time. + + Version declarations can be supplied. Version numbers must be in + the format specified in Version specifiers (e.g. ‘foo (<3.0)’). + + This field may be followed by an environment marker after a + semicolon (e.g. ‘foo; os_name == "posix"’) + + The most common use of this field will be in case a project name + changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. + When you install Torqued Python, the Gorgon distribution should be + removed. + +‘provides’ + + Warning: ‘provides’ is currently ignored by ‘pip’. + + List of strings describing package- and virtual package names + contained within this package. + + A package may provide additional names, e.g. to indicate that + multiple projects have been bundled together. For instance, source + distributions of the ZODB project have historically included the + transaction project, which is now available as a separate + distribution. Installing such a source distribution satisfies + requirements for both ZODB and transaction. + + A package may also provide a “virtual” project name, which does not + correspond to any separately-distributed project: such a name might + be used to indicate an abstract capability which could be supplied + by one of multiple projects. E.g., multiple projects might supply + RDBMS bindings for use by a given ORM: each project might declare + that it provides ORM-bindings, allowing other projects to depend + only on having at most one of them installed. + + A version declaration may be supplied and must follow the rules + described in Version specifiers. The distribution’s version number + will be implied if none is specified (e.g. ‘foo (<3.0)’). + + Each package may be followed by an environment marker after a + semicolon (e.g. ‘foo; os_name == "posix"’). + +‘include_package_data’ + + If set to ‘True’, this tells ‘setuptools’ to automatically include + any data files it finds inside your package directories that are + specified by your ‘MANIFEST.in’ file. For more information, see + the section on *note Including Data Files: 12. + +‘exclude_package_data’ + + A dictionary mapping package names to lists of glob patterns that + should be `excluded' from your package directories. You can use + this to trim back any excess files included by + ‘include_package_data’. For a complete description and examples, + see the section on *note Including Data Files: 12. + +‘package_data’ + + A dictionary mapping package names to lists of glob patterns. For + a complete description and examples, see the section on *note + Including Data Files: 12. You do not need to use this option if + you are using ‘include_package_data’, unless you need to add e.g. + files that are generated by your setup script and build process. + (And are therefore not in source control or are files that you + don’t want to include in your source distribution.) + +‘zip_safe’ + + A boolean (True or False) flag specifying whether the project can + be safely installed and run from a zip file. If this argument is + not supplied, the ‘bdist_egg’ command will have to analyze all of + your project’s contents for possible problems each time it builds + an egg. + +‘install_requires’ + + A string or list of strings specifying what other distributions + need to be installed when this one is. See the section on *note + Declaring required dependency: 2b. for details and examples of the + format of this argument. + +‘entry_points’ + + A dictionary mapping entry point group names to strings or lists of + strings defining the entry points. Entry points are used to + support dynamic discovery of services or plugins provided by a + project. See *note Advertising Behavior: 25. for details and + examples of the format of this argument. In addition, this keyword + is used to support *note Automatic Script Creation: 21. + +‘extras_require’ + + A dictionary mapping names of “extras” (optional features of your + project) to strings or lists of strings specifying what other + distributions must be installed to support those features. See the + section on *note Declaring required dependency: 2b. for details and + examples of the format of this argument. + +‘python_requires’ + + A string corresponding to a version specifier (as defined in PEP + 440) for the Python version, used to specify the Requires-Python + defined in PEP 345. + +‘setup_requires’ + + Warning: Using ‘setup_requires’ is discouraged in favor of + PEP-518(2) + + A string or list of strings specifying what other distributions + need to be present in order for the `setup script' to run. + ‘setuptools’ will attempt to obtain these (even going so far as to + download them using ‘EasyInstall’) before processing the rest of + the setup script or commands. This argument is needed if you are + using distutils extensions as part of your build process; for + example, extensions that process setup() arguments and turn them + into EGG-INFO metadata files. + + (Note: projects listed in ‘setup_requires’ will NOT be + automatically installed on the system where the setup script is + being run. They are simply downloaded to the ./.eggs directory if + they’re not locally available already. If you want them to be + installed, as well as being available when the setup script is run, + you should add them to ‘install_requires’ `and' ‘setup_requires’.) + +‘dependency_links’ + + Warning: ‘dependency_links’ is deprecated. It is not + supported anymore by pip. + + A list of strings naming URLs to be searched when satisfying + dependencies. These links will be used if needed to install + packages specified by ‘setup_requires’ or ‘tests_require’. They + will also be written into the egg’s metadata for use by tools like + EasyInstall to use when installing an ‘.egg’ file. + +‘namespace_packages’ + + A list of strings naming the project’s “namespace packages”. A + namespace package is a package that may be split across multiple + project distributions. For example, Zope 3’s ‘zope’ package is a + namespace package, because subpackages like ‘zope.interface’ and + ‘zope.publisher’ may be distributed separately. The egg runtime + system can automatically merge such subpackages into a single + parent package at runtime, as long as you declare them in each + project that contains any subpackages of the namespace package, and + as long as the namespace package’s ‘__init__.py’ does not contain + any code other than a namespace declaration. See the section on + *note Using find_namespace; or find_namespace_packages: 1c. for + more information. + +‘test_suite’ + + A string naming a ‘unittest.TestCase’ subclass (or a package or + module containing one or more of them, or a method of such a + subclass), or naming a function that can be called with no + arguments and returns a ‘unittest.TestSuite’. If the named suite + is a module, and the module has an ‘additional_tests()’ function, + it is called and the results are added to the tests to be run. If + the named suite is a package, any submodules and subpackages are + recursively added to the overall test suite. + + Specifying this argument enables use of the *note test - Build + package and run a unittest suite: 56. command to run the specified + test suite, e.g. via ‘setup.py test’. See the section on the + *note test - Build package and run a unittest suite: 56. command + below for more details. + + New in 41.5.0: Deprecated the test command. + +‘tests_require’ + + If your project’s tests need one or more additional packages + besides those needed to install it, you can use this option to + specify them. It should be a string or list of strings specifying + what other distributions need to be present for the package’s tests + to run. When you run the ‘test’ command, ‘setuptools’ will attempt + to obtain these (even going so far as to download them using + ‘EasyInstall’). Note that these required projects will `not' be + installed on the system where the tests are run, but only + downloaded to the project’s setup directory if they’re not already + installed locally. + + New in 41.5.0: Deprecated the test command. + +‘test_loader’ + + If you would like to use a different way of finding tests to run + than what setuptools normally uses, you can specify a module name + and class name in this argument. The named class must be + instantiable with no arguments, and its instances must support the + ‘loadTestsFromNames()’ method as defined in the Python ‘unittest’ + module’s ‘TestLoader’ class. Setuptools will pass only one test + “name” in the ‘names’ argument: the value supplied for the + ‘test_suite’ argument. The loader you specify may interpret this + string in any way it likes, as there are no restrictions on what + may be contained in a ‘test_suite’ string. + + The module name and class name must be separated by a ‘:’. The + default value of this argument is + ‘"setuptools.command.test:ScanningLoader"’. If you want to use the + default ‘unittest’ behavior, you can specify + ‘"unittest:TestLoader"’ as your ‘test_loader’ argument instead. + This will prevent automatic scanning of submodules and subpackages. + + The module and class you specify here may be contained in another + package, as long as you use the ‘tests_require’ option to ensure + that the package containing the loader class is available when the + ‘test’ command is run. + + New in 41.5.0: Deprecated the test command. + +‘eager_resources’ + + A list of strings naming resources that should be extracted + together, if any of them is needed, or if any C extensions included + in the project are imported. This argument is only useful if the + project will be installed as a zipfile, and there is a need to have + all of the listed resources be extracted to the filesystem `as a + unit'. Resources listed here should be ‘/’-separated paths, + relative to the source root, so to list a resource ‘foo.png’ in + package ‘bar.baz’, you would include the string ‘bar/baz/foo.png’ + in this argument. + + If you only need to obtain resources one at a time, or you don’t + have any C extensions that access other files in the project (such + as data files or shared libraries), you probably do NOT need this + argument and shouldn’t mess with it. For more details on how this + argument works, see the section below on *note Automatic Resource + Extraction: 58. + +‘use_2to3’ + + Convert the source code from Python 2 to Python 3 with 2to3 during + the build process. See *note Supporting both Python 2 and Python 3 + with Setuptools: 59. for more details. + +‘convert_2to3_doctests’ + + List of doctest source files that need to be converted with 2to3. + See *note Supporting both Python 2 and Python 3 with Setuptools: + 59. for more details. + +‘use_2to3_fixers’ + + A list of modules to search for additional fixers to be used during + the 2to3 conversion. See *note Supporting both Python 2 and Python + 3 with Setuptools: 59. for more details. + +‘use_2to3_exclude_fixers’ + + List of fixer names to be skipped. + +‘project_urls’ + + An arbitrary map of URL names to hyperlinks, allowing more + extensible documentation of where various resources can be found + than the simple ‘url’ and ‘download_url’ options provide. + + ---------- Footnotes ---------- + + (1) https://www.python.org/dev/peps/pep-0314/ + + (2) http://www.python.org/dev/peps/pep-0518/ + + +File: setuptools.info, Node: Roadmap, Next: Building and Distributing Packages with Setuptools<2>, Prev: Keywords, Up: Top + +5 Roadmap +********* + +Setuptools maintains a series of milestones(1) to track a roadmap of +large-scale goals. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/milestones + + +File: setuptools.info, Node: Building and Distributing Packages with Setuptools<2>, Next: Development on Setuptools, Prev: Roadmap, Up: Top + +6 Building and Distributing Packages with Setuptools +**************************************************** + +‘Setuptools’ is a collection of enhancements to the Python ‘distutils’ +that allow developers to more easily build and distribute Python +packages, especially ones that have dependencies on other packages. + +Packages built and distributed using ‘setuptools’ look to the user like +ordinary Python packages based on the ‘distutils’. + +Feature Highlights: + + * Create Python Eggs(1) - a single-file importable distribution + format + + * Enhanced support for accessing data files hosted in zipped + packages. + + * Automatically include all packages in your source tree, without + listing them individually in setup.py + + * Automatically include all relevant files in your source + distributions, without needing to create a ‘MANIFEST.in’ file, and + without having to force regeneration of the ‘MANIFEST’ file when + your source tree changes. + + * Automatically generate wrapper scripts or Windows (console and GUI) + .exe files for any number of “main” functions in your project. + (Note: this is not a py2exe replacement; the .exe files rely on the + local Python installation.) + + * Transparent Cython support, so that your setup.py can list ‘.pyx’ + files and still work even when the end-user doesn’t have Cython + installed (as long as you include the Cython-generated C in your + source distribution) + + * Command aliases - create project-specific, per-user, or site-wide + shortcut names for commonly used commands and options + + * Deploy your project in “development mode”, such that it’s available + on ‘sys.path’, yet can still be edited directly from its source + checkout. + + * Easily extend the distutils with new commands or ‘setup()’ + arguments, and distribute/reuse your extensions for multiple + projects, without copying code. + + * Create extensible applications and frameworks that automatically + discover extensions, using simple “entry points” declared in a + project’s setup script. + + * Full support for PEP 420 via ‘find_namespace_packages()’, which is + also backwards compatible to the existing ‘find_packages()’ for + Python >= 3.3. + +* Menu: + +* Developer’s Guide:: + + ---------- Footnotes ---------- + + (1) http://peak.telecommunity.com/DevCenter/PythonEggs + + +File: setuptools.info, Node: Developer’s Guide, Up: Building and Distributing Packages with Setuptools<2> + +6.1 Developer’s Guide +===================== + +* Menu: + +* TRANSITIONAL NOTE:: + + +File: setuptools.info, Node: TRANSITIONAL NOTE, Up: Developer’s Guide + +6.1.1 TRANSITIONAL NOTE +----------------------- + +Setuptools automatically calls ‘declare_namespace()’ for you at runtime, +but future versions may `not'. This is because the automatic +declaration feature has some negative side effects, such as needing to +import all namespace packages during the initialization of the +‘pkg_resources’ runtime, and also the need for ‘pkg_resources’ to be +explicitly imported before any namespace packages work at all. In some +future releases, you’ll be responsible for including your own +declaration lines, and the automatic declaration feature will be dropped +to get rid of the negative side effects. + +During the remainder of the current development cycle, therefore, +setuptools will warn you about missing ‘declare_namespace()’ calls in +your ‘__init__.py’ files, and you should correct these as soon as +possible before the compatibility support is removed. Namespace +packages without declaration lines will not work correctly once a user +has upgraded to a later version, so it’s important that you make this +change now in order to avoid having your code break in the field. Our +apologies for the inconvenience, and thank you for your patience. + +* Menu: + +* setup.cfg-only projects: setup cfg-only projects. +* Configuration API:: +* Mailing List and Bug Tracker:: + + +File: setuptools.info, Node: setup cfg-only projects, Next: Configuration API, Up: TRANSITIONAL NOTE + +6.1.1.1 setup.cfg-only projects +............................... + +New in version 40.9.0. + +If ‘setup.py’ is missing from the project directory when a PEP 517(1) +build is invoked, ‘setuptools’ emulates a dummy ‘setup.py’ file +containing only a ‘setuptools.setup()’ call. + + Note: PEP 517(2) doesn’t support editable installs so this is + currently incompatible with ‘pip install -e .’, as PEP 517(3) does + not support editable installs. + +This means that you can have a Python project with all build +configuration specified in ‘setup.cfg’, without a ‘setup.py’ file, if +you `can rely on' your project always being built by a PEP 517(4)/ PEP +518(5) compatible frontend. + +To use this feature: + + * Specify build requirements and PEP 517(6) build backend in + ‘pyproject.toml’. For example: + + [build-system] + requires = [ + "setuptools >= 40.9.0", + "wheel", + ] + build-backend = "setuptools.build_meta" + + * Use a PEP 517(7) compatible build frontend, such as ‘pip >= 19’ or + ‘pep517’. + + Warning: As PEP 517(8) is new, support is not universal, and + frontends that do support it may still have bugs. For + compatibility, you may want to put a ‘setup.py’ file + containing only a ‘setuptools.setup()’ invocation. + + ---------- Footnotes ---------- + + (1) https://www.python.org/dev/peps/pep-0517 + + (2) https://www.python.org/dev/peps/pep-0517 + + (3) https://www.python.org/dev/peps/pep-0517 + + (4) https://www.python.org/dev/peps/pep-0517 + + (5) https://www.python.org/dev/peps/pep-0518 + + (6) https://www.python.org/dev/peps/pep-0517 + + (7) https://www.python.org/dev/peps/pep-0517 + + (8) https://www.python.org/dev/peps/pep-0517 + + +File: setuptools.info, Node: Configuration API, Next: Mailing List and Bug Tracker, Prev: setup cfg-only projects, Up: TRANSITIONAL NOTE + +6.1.1.2 Configuration API +......................... + +Some automation tools may wish to access data from a configuration file. + +‘Setuptools’ exposes a ‘read_configuration()’ function for parsing +‘metadata’ and ‘options’ sections into a dictionary. + + from setuptools.config import read_configuration + + conf_dict = read_configuration("/home/user/dev/package/setup.cfg") + +By default, ‘read_configuration()’ will read only the file provided in +the first argument. To include values from other configuration files +which could be in various places, set the ‘find_others’ keyword argument +to ‘True’. + +If you have only a configuration file but not the whole package, you can +still try to get data out of it with the help of the +‘ignore_option_errors’ keyword argument. When it is set to ‘True’, all +options with errors possibly produced by directives, such as ‘attr:’ and +others, will be silently ignored. As a consequence, the resulting +dictionary will include no such options. + + +File: setuptools.info, Node: Mailing List and Bug Tracker, Prev: Configuration API, Up: TRANSITIONAL NOTE + +6.1.1.3 Mailing List and Bug Tracker +.................................... + +Please use the distutils-sig mailing list(1) for questions and +discussion about setuptools, and the setuptools bug tracker(2) ONLY for +issues you have confirmed via the list are actual bugs, and which you +have reduced to a minimal set of steps to reproduce. + + ---------- Footnotes ---------- + + (1) http://mail.python.org/pipermail/distutils-sig/ + + (2) https://github.com/pypa/setuptools/ + + +File: setuptools.info, Node: Development on Setuptools, Next: Guides on backward compatibility & deprecated practice, Prev: Building and Distributing Packages with Setuptools<2>, Up: Top + +7 Development on Setuptools +*************************** + +Setuptools is maintained by the Python community under the Python +Packaging Authority (PyPA) and led by Jason R. Coombs. + +This document describes the process by which Setuptools is developed. +This document assumes the reader has some passing familiarity with +`using' setuptools, the ‘pkg_resources’ module, and pip. It does not +attempt to explain basic concepts like inter-project dependencies, nor +does it contain detailed lexical syntax for most file formats. Neither +does it explain concepts like “namespace packages” or “resources” in any +detail, as all of these subjects are covered at length in the setuptools +developer’s guide and the ‘pkg_resources’ reference manual. + +Instead, this is `internal' documentation for how those concepts and +features are `implemented' in concrete terms. It is intended for people +who are working on the setuptools code base, who want to be able to +troubleshoot setuptools problems, want to write code that reads the file +formats involved, or want to otherwise tinker with setuptools-generated +files and directories. + +Note, however, that these are all internal implementation details and +are therefore subject to change; stick to the published API if you don’t +want to be responsible for keeping your code from breaking when +setuptools changes. You have been warned. + +* Menu: + +* Developer’s Guide for Setuptools:: +* Release Process:: + + +File: setuptools.info, Node: Developer’s Guide for Setuptools, Next: Release Process, Up: Development on Setuptools + +7.1 Developer’s Guide for Setuptools +==================================== + +If you want to know more about contributing on Setuptools, this is the +place. + +* Menu: + +* Recommended Reading:: +* Project Management:: +* Authoring Tickets:: +* Making a pull request:: +* Auto-Merge Requests:: +* Testing:: +* Semantic Versioning:: +* Building Documentation:: +* Vendored Dependencies:: + + +File: setuptools.info, Node: Recommended Reading, Next: Project Management, Up: Developer’s Guide for Setuptools + +7.1.1 Recommended Reading +------------------------- + +Please read How to write the perfect pull request(1) for some tips on +contributing to open source projects. Although the article is not +authoritative, it was authored by the maintainer of Setuptools, so +reflects his opinions and will improve the likelihood of acceptance and +quality of contribution. + + ---------- Footnotes ---------- + + (1) https://blog.jaraco.com/how-to-write-perfect-pull-request/ + + +File: setuptools.info, Node: Project Management, Next: Authoring Tickets, Prev: Recommended Reading, Up: Developer’s Guide for Setuptools + +7.1.2 Project Management +------------------------ + +Setuptools is maintained primarily in GitHub at this home(1). +Setuptools is maintained under the Python Packaging Authority (PyPA) +with several core contributors. All bugs for Setuptools are filed and +the canonical source is maintained in GitHub. + +User support and discussions are done through the issue tracker (for +specific) issues, through the distutils-sig mailing list(2), or on IRC +(Freenode) at #pypa. + +Discussions about development happen on the distutils-sig mailing list +or on Gitter(3). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools + + (2) https://mail.python.org/mailman3/lists/distutils-sig.python.org/ + + (3) https://gitter.im/pypa/setuptools + + +File: setuptools.info, Node: Authoring Tickets, Next: Making a pull request, Prev: Project Management, Up: Developer’s Guide for Setuptools + +7.1.3 Authoring Tickets +----------------------- + +Before authoring any source code, it’s often prudent to file a ticket +describing the motivation behind making changes. First search to see if +a ticket already exists for your issue. If not, create one. Try to +think from the perspective of the reader. Explain what behavior you +expected, what you got instead, and what factors might have contributed +to the unexpected behavior. In GitHub, surround a block of code or +traceback with the triple backtick “‘‘‘” so that it is formatted nicely. + +Filing a ticket provides a forum for justification, discussion, and +clarification. The ticket provides a record of the purpose for the +change and any hard decisions that were made. It provides a single +place for others to reference when trying to understand why the software +operates the way it does or why certain changes were made. + +Setuptools makes extensive use of hyperlinks to tickets in the changelog +so that system integrators and other users can get a quick summary, but +then jump to the in-depth discussion about any subject referenced. + + +File: setuptools.info, Node: Making a pull request, Next: Auto-Merge Requests, Prev: Authoring Tickets, Up: Developer’s Guide for Setuptools + +7.1.4 Making a pull request +--------------------------- + +When making a pull request, please *note include a short summary of the +changes: b1. and a reference to any issue tickets that the PR is +intended to solve. All PRs with code changes should include tests. All +changes should include a changelog entry. + +* Menu: + +* Adding change notes with your PRs:: +* Alright! So how to add a news fragment?:: +* Examples for adding changelog entries to your Pull Requests:: + + +File: setuptools.info, Node: Adding change notes with your PRs, Next: Alright! So how to add a news fragment?, Up: Making a pull request + +7.1.4.1 Adding change notes with your PRs +......................................... + +It is very important to maintain a log for news of how updating to the +new version of the software will affect end-users. This is why we +enforce collection of the change fragment files in pull requests as per +Towncrier philosophy(1). + +The idea is that when somebody makes a change, they must record the bits +that would affect end-users only including information that would be +useful to them. Then, when the maintainers publish a new release, +they’ll automatically use these records to compose a change log for the +respective version. It is important to understand that including +unnecessary low-level implementation related details generates noise +that is not particularly useful to the end-users most of the time. And +so such details should be recorded in the Git history rather than a +changelog. + + ---------- Footnotes ---------- + + (1) +https://towncrier.readthedocs.io/en/actual-freaking-docs/#philosophy + + +File: setuptools.info, Node: Alright! So how to add a news fragment?, Next: Examples for adding changelog entries to your Pull Requests, Prev: Adding change notes with your PRs, Up: Making a pull request + +7.1.4.2 Alright! So how to add a news fragment? +............................................... + +‘setuptools’ uses towncrier(1) for changelog management. To submit a +change note about your PR, add a text file into the ‘changelog.d/’ +folder. It should contain an explanation of what applying this PR will +change in the way end-users interact with the project. One sentence is +usually enough but feel free to add as many details as you feel +necessary for the users to understand what it means. + +`Use the past tense' for the text in your fragment because, combined +with others, it will be a part of the “news digest” telling the readers +`what changed' in a specific version of the library `since the previous +version'. You should also use reStructuredText syntax for highlighting +code (inline or block), linking parts of the docs or external sites. If +you wish to sign your change, feel free to add ‘-- by +:user:`github-username`’ at the end (replace ‘github-username’ with your +own!). + +Finally, name your file following the convention that Towncrier +understands: it should start with the number of an issue or a PR +followed by a dot, then add a patch type, like ‘change’, ‘doc’, ‘misc’ +etc., and add ‘.rst’ as a suffix. If you need to add more than one +fragment, you may add an optional sequence number (delimited with +another period) between the type and the suffix. + +In general the name will follow ‘<pr_number>.<category>.rst’ pattern, +where the categories are: + + - ‘change’: Any backwards compatible code change + + - ‘breaking’: Any backwards-compatibility breaking change + + - ‘doc’: A change to the documentation + + - ‘misc’: Changes internal to the repo like CI, test and build + changes + + - ‘deprecation’: For deprecations of an existing feature or behavior + +A pull request may have more than one of these components, for example a +code change may introduce a new feature that deprecates an old feature, +in which case two fragments should be added. It is not necessary to +make a separate documentation fragment for documentation changes +accompanying the relevant code changes. + + ---------- Footnotes ---------- + + (1) https://pypi.org/project/towncrier/ + + +File: setuptools.info, Node: Examples for adding changelog entries to your Pull Requests, Prev: Alright! So how to add a news fragment?, Up: Making a pull request + +7.1.4.3 Examples for adding changelog entries to your Pull Requests +................................................................... + +File ‘changelog.d/2395.doc.1.rst’: + + Added a ``:user:`` role to Sphinx config -- by :user:`webknjaz` + +File ‘changelog.d/1354.misc.rst’: + + Added ``towncrier`` for changelog managment -- by :user:`pganssle` + +File ‘changelog.d/2355.change.rst’: + + When pip is imported as part of a build, leave :py:mod:`distutils` + patched -- by :user:`jaraco` + + Tip: See ‘pyproject.toml’ for all available categories + (‘tool.towncrier.type’). + + +File: setuptools.info, Node: Auto-Merge Requests, Next: Testing, Prev: Making a pull request, Up: Developer’s Guide for Setuptools + +7.1.5 Auto-Merge Requests +------------------------- + +To support running all code through CI, even lightweight contributions, +the project employs Mergify to auto-merge pull requests tagged as +auto-merge. + +Use ‘hub pull-request -l auto-merge’ to create such a pull request from +the command line after pushing a new branch. + + +File: setuptools.info, Node: Testing, Next: Semantic Versioning, Prev: Auto-Merge Requests, Up: Developer’s Guide for Setuptools + +7.1.6 Testing +------------- + +The primary tests are run using tox. Make sure you have tox installed, +and invoke it: + + $ tox + +Under continuous integration, additional tests may be run. See the +‘.travis.yml’ file for full details on the tests run under Travis-CI. + + +File: setuptools.info, Node: Semantic Versioning, Next: Building Documentation, Prev: Testing, Up: Developer’s Guide for Setuptools + +7.1.7 Semantic Versioning +------------------------- + +Setuptools follows ‘semver’. + + +File: setuptools.info, Node: Building Documentation, Next: Vendored Dependencies, Prev: Semantic Versioning, Up: Developer’s Guide for Setuptools + +7.1.8 Building Documentation +---------------------------- + +Setuptools relies on the Sphinx(1) system for building documentation. +The published documentation(2) is hosted on Read the Docs. + +To build the docs locally, use tox: + + $ tox -e docs + + ---------- Footnotes ---------- + + (1) http://www.sphinx-doc.org/en/master/ + + (2) https://setuptools.readthedocs.io/en/latest/ + + +File: setuptools.info, Node: Vendored Dependencies, Prev: Building Documentation, Up: Developer’s Guide for Setuptools + +7.1.9 Vendored Dependencies +--------------------------- + +Setuptools has some dependencies, but due to bootstrapping issues(1), +those dependencies cannot be declared as they won’t be resolved soon +enough to build setuptools from source. Eventually, this limitation may +be lifted as PEP 517/518 reach ubiquitous adoption, but for now, +Setuptools cannot declare dependencies other than through +‘setuptools/_vendor/vendored.txt’ and +‘pkg_resources/_vendor/vendored.txt’ and refreshed by way of ‘paver +update_vendored’ (pavement.py). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/980 + + +File: setuptools.info, Node: Release Process, Prev: Developer’s Guide for Setuptools, Up: Development on Setuptools + +7.2 Release Process +=================== + +In order to allow for rapid, predictable releases, Setuptools uses a +mechanical technique for releases, enacted on tagged commits by +continuous integration. + +To finalize a release, run ‘tox -e finalize’, review, then push the +changes. + +If tests pass, the release will be uploaded to PyPI. + +* Menu: + +* Release Frequency:: +* Release Managers:: + + +File: setuptools.info, Node: Release Frequency, Next: Release Managers, Up: Release Process + +7.2.1 Release Frequency +----------------------- + +Some have asked why Setuptools is released so frequently. Because +Setuptools uses a mechanical release process, it’s very easy to make +releases whenever the code is stable (tests are passing). As a result, +the philosophy is to release early and often. + +While some find the frequent releases somewhat surprising, they only +empower the user. Although releases are made frequently, users can +choose the frequency at which they use those releases. If instead +Setuptools contributions were only released in batches, the user would +be constrained to only use Setuptools when those official releases were +made. With frequent releases, the user can govern exactly how often he +wishes to update. + +Frequent releases also then obviate the need for dev or beta releases in +most cases. Because releases are made early and often, bugs are +discovered and corrected quickly, in many cases before other users have +yet to encounter them. + + +File: setuptools.info, Node: Release Managers, Prev: Release Frequency, Up: Release Process + +7.2.2 Release Managers +---------------------- + +Additionally, anyone with push access to the master branch has access to +cut releases. + + +File: setuptools.info, Node: Guides on backward compatibility & deprecated practice, Next: History<2>, Prev: Development on Setuptools, Up: Top + +8 Guides on backward compatibility & deprecated practice +******************************************************** + +‘Setuptools’ has undergone tremendous changes since its first debut. As +its development continues to roll forward, many of the practice and +mechanisms it had established are now considered deprecated. But they +still remain relevant as a plethora of libraries continue to depend on +them. Many people also find it necessary to equip themselves with the +knowledge to better support backward compatibility. This guide aims to +provide the essential information for such objectives. + +* Menu: + +* Supporting both Python 2 and Python 3 with Setuptools:: +* The Internal Structure of Python Eggs:: +* Easy Install:: +* Porting from Distutils:: +* “Eggsecutable” Scripts:: + + +File: setuptools.info, Node: Supporting both Python 2 and Python 3 with Setuptools, Next: The Internal Structure of Python Eggs, Up: Guides on backward compatibility & deprecated practice + +8.1 Supporting both Python 2 and Python 3 with Setuptools +========================================================= + +Starting with Distribute version 0.6.2 and Setuptools 0.7, the +Setuptools project supported Python 3. Installing and using setuptools +for Python 3 code works exactly the same as for Python 2 code. + +Setuptools provides a facility to invoke 2to3 on the code as a part of +the build process, by setting the keyword parameter ‘use_2to3’ to True, +but the Setuptools project strongly recommends instead developing a +unified codebase using six(1), future(2), or another compatibility +library. + +* Menu: + +* Using 2to3:: +* Distributing Python 3 modules:: +* Advanced features:: + + ---------- Footnotes ---------- + + (1) https://pypi.org/project/six/ + + (2) https://pypi.org/project/future/ + + +File: setuptools.info, Node: Using 2to3, Next: Distributing Python 3 modules, Up: Supporting both Python 2 and Python 3 with Setuptools + +8.1.1 Using 2to3 +---------------- + +Setuptools attempts to make the porting process easier by automatically +running 2to3 as a part of running tests. To do so, you need to +configure the setup.py so that you can run the unit tests with ‘python +setup.py test’. + +See *note test - Build package and run a unittest suite: 56. for more +information on this. + +Once you have the tests running under Python 2, you can add the use_2to3 +keyword parameters to setup(), and start running the tests under Python +3. The test command will now first run the build command during which +the code will be converted with 2to3, and the tests will then be run +from the build directory, as opposed from the source directory as is +normally done. + +Setuptools will convert all Python files, and also all doctests in +Python files. However, if you have doctests located in separate text +files, these will not automatically be converted. By adding them to the +‘convert_2to3_doctests’ keyword parameter Setuptools will convert them +as well. + +By default, the conversion uses all fixers in the ‘lib2to3.fixers’ +package. To use additional fixers, the parameter ‘use_2to3_fixers’ can +be set to a list of names of packages containing fixers. To exclude +fixers, the parameter ‘use_2to3_exclude_fixers’ can be set to fixer +names to be skipped. + +An example setup.py might look something like this: + + from setuptools import setup + + setup( + name='your.module', + version='1.0', + description='This is your awesome module', + author='You', + author_email='your@email', + package_dir={'': 'src'}, + packages=['your', 'you.module'], + test_suite='your.module.tests', + use_2to3=True, + convert_2to3_doctests=['src/your/module/README.txt'], + use_2to3_fixers=['your.fixers'], + use_2to3_exclude_fixers=['lib2to3.fixes.fix_import'], + ) + +* Menu: + +* Differential conversion:: + + +File: setuptools.info, Node: Differential conversion, Up: Using 2to3 + +8.1.1.1 Differential conversion +............................... + +Note that a file will only be copied and converted during the build +process if the source file has been changed. If you add a file to the +doctests that should be converted, it will not be converted the next +time you run the tests, since it hasn’t been modified. You need to +remove it from the build directory. Also if you run the build, install +or test commands before adding the use_2to3 parameter, you will have to +remove the build directory before you run the test command, as the files +otherwise will seem updated, and no conversion will happen. + +In general, if code doesn’t seem to be converted, deleting the build +directory and trying again is a good safeguard against the build +directory getting “out of sync” with the source directory. + + +File: setuptools.info, Node: Distributing Python 3 modules, Next: Advanced features, Prev: Using 2to3, Up: Supporting both Python 2 and Python 3 with Setuptools + +8.1.2 Distributing Python 3 modules +----------------------------------- + +You can distribute your modules with Python 3 support in different ways. +A normal source distribution will work, but can be slow in installing, +as the 2to3 process will be run during the install. But you can also +distribute the module in binary format, such as a binary egg. That egg +will contain the already converted code, and hence no 2to3 conversion is +needed during install. + + +File: setuptools.info, Node: Advanced features, Prev: Distributing Python 3 modules, Up: Supporting both Python 2 and Python 3 with Setuptools + +8.1.3 Advanced features +----------------------- + +If you don’t want to run the 2to3 conversion on the doctests in Python +files, you can turn that off by setting ‘setuptools.use_2to3_on_doctests += False’. + + +File: setuptools.info, Node: The Internal Structure of Python Eggs, Next: Easy Install, Prev: Supporting both Python 2 and Python 3 with Setuptools, Up: Guides on backward compatibility & deprecated practice + +8.2 The Internal Structure of Python Eggs +========================================= + +STOP! This is not the first document you should read! + +* Menu: + +* Eggs and their Formats:: +* Standard Metadata:: +* Other Technical Considerations:: + + +File: setuptools.info, Node: Eggs and their Formats, Next: Standard Metadata, Up: The Internal Structure of Python Eggs + +8.2.1 Eggs and their Formats +---------------------------- + +A “Python egg” is a logical structure embodying the release of a +specific version of a Python project, comprising its code, resources, +and metadata. There are multiple formats that can be used to physically +encode a Python egg, and others can be developed. However, a key +principle of Python eggs is that they should be discoverable and +importable. That is, it should be possible for a Python application to +easily and efficiently find out what eggs are present on a system, and +to ensure that the desired eggs’ contents are importable. + +There are two basic formats currently implemented for Python eggs: + + 1. ‘.egg’ format: a directory or zipfile `containing' the project’s + code and resources, along with an ‘EGG-INFO’ subdirectory that + contains the project’s metadata + + 2. ‘.egg-info’ format: a file or directory placed `adjacent' to the + project’s code and resources, that directly contains the project’s + metadata. + +Both formats can include arbitrary Python code and resources, including +static data files, package and non-package directories, Python modules, +C extension modules, and so on. But each format is optimized for +different purposes. + +The ‘.egg’ format is well-suited to distribution and the easy +uninstallation or upgrades of code, since the project is essentially +self-contained within a single directory or file, unmingled with any +other projects’ code or resources. It also makes it possible to have +multiple versions of a project simultaneously installed, such that +individual programs can select the versions they wish to use. + +The ‘.egg-info’ format, on the other hand, was created to support +backward-compatibility, performance, and ease of installation for system +packaging tools that expect to install all projects’ code and resources +to a single directory (e.g. ‘site-packages’). Placing the metadata in +that same directory simplifies the installation process, since it isn’t +necessary to create ‘.pth’ files or otherwise modify ‘sys.path’ to +include each installed egg. + +Its disadvantage, however, is that it provides no support for clean +uninstallation or upgrades, and of course only a single version of a +project can be installed to a given directory. Thus, support from a +package management tool is required. (This is why setuptools’ “install” +command refers to this type of egg installation as “single-version, +externally managed”.) Also, they lack sufficient data to allow them to +be copied from their installation source. easy_install can “ship” an +application by copying ‘.egg’ files or directories to a target location, +but it cannot do this for ‘.egg-info’ installs, because there is no way +to tell what code and resources belong to a particular egg – there may +be several eggs “scrambled” together in a single installation location, +and the ‘.egg-info’ format does not currently include a way to list the +files that were installed. (This may change in a future version.) + +* Menu: + +* Code and Resources:: +* Project Metadata:: +* Filename-Embedded Metadata:: +* Egg Links:: + + +File: setuptools.info, Node: Code and Resources, Next: Project Metadata, Up: Eggs and their Formats + +8.2.1.1 Code and Resources +.......................... + +The layout of the code and resources is dictated by Python’s normal +import layout, relative to the egg’s “base location”. + +For the ‘.egg’ format, the base location is the ‘.egg’ itself. That is, +adding the ‘.egg’ filename or directory name to ‘sys.path’ makes its +contents importable. + +For the ‘.egg-info’ format, however, the base location is the directory +that `contains' the ‘.egg-info’, and thus it is the directory that must +be added to ‘sys.path’ to make the egg importable. (Note that this +means that the “normal” installation of a package to a ‘sys.path’ +directory is sufficient to make it an “egg” if it has an ‘.egg-info’ +file or directory installed alongside of it.) + + +File: setuptools.info, Node: Project Metadata, Next: Filename-Embedded Metadata, Prev: Code and Resources, Up: Eggs and their Formats + +8.2.1.2 Project Metadata +........................ + +If eggs contained only code and resources, there would of course be no +difference between them and any other directory or zip file on +‘sys.path’. Thus, metadata must also be included, using a metadata file +or directory. + +For the ‘.egg’ format, the metadata is placed in an ‘EGG-INFO’ +subdirectory, directly within the ‘.egg’ file or directory. For the +‘.egg-info’ format, metadata is stored directly within the ‘.egg-info’ +directory itself. + +The minimum project metadata that all eggs must have is a standard +Python ‘PKG-INFO’ file, named ‘PKG-INFO’ and placed within the metadata +directory appropriate to the format. Because it’s possible for this to +be the only metadata file included, ‘.egg-info’ format eggs are not +required to be a directory; they can just be a ‘.egg-info’ file that +directly contains the ‘PKG-INFO’ metadata. This eliminates the need to +create a directory just to store one file. This option is `not' +available for ‘.egg’ formats, since setuptools always includes other +metadata. (In fact, setuptools itself never generates ‘.egg-info’ +files, either; the support for using files was added so that the +requirement could easily be satisfied by other tools, such as +distutils). + +In addition to the ‘PKG-INFO’ file, an egg’s metadata directory may also +include files and directories representing various forms of optional +standard metadata (see the section on *note Standard Metadata: cb, +below) or user-defined metadata required by the project. For example, +some projects may define a metadata format to describe their application +plugins, and metadata in this format would then be included by plugin +creators in their projects’ metadata directories. + + +File: setuptools.info, Node: Filename-Embedded Metadata, Next: Egg Links, Prev: Project Metadata, Up: Eggs and their Formats + +8.2.1.3 Filename-Embedded Metadata +.................................. + +To allow introspection of installed projects and runtime resolution of +inter-project dependencies, a certain amount of information is embedded +in egg filenames. At a minimum, this includes the project name, and +ideally will also include the project version number. Optionally, it +can also include the target Python version and required runtime platform +if platform-specific C code is included. The syntax of an egg filename +is as follows: + + name ["-" version ["-py" pyver ["-" required_platform]]] "." ext + +The “name” and “version” should be escaped using the ‘to_filename()’ +function provided by ‘pkg_resources’, after first processing them with +‘safe_name()’ and ‘safe_version()’ respectively. These latter two +functions can also be used to later “unescape” these parts of the +filename. (For a detailed description of these transformations, please +see the “Parsing Utilities” section of the ‘pkg_resources’ manual.) + +The “pyver” string is the Python major version, as found in the first 3 +characters of ‘sys.version’. “required_platform” is essentially a +distutils ‘get_platform()’ string, but with enhancements to properly +distinguish Mac OS versions. (See the ‘get_build_platform()’ +documentation in the “Platform Utilities” section of the ‘pkg_resources’ +manual for more details.) + +Finally, the “ext” is either ‘.egg’ or ‘.egg-info’, as appropriate for +the egg’s format. + +Normally, an egg’s filename should include at least the project name and +version, as this allows the runtime system to find desired project +versions without having to read the egg’s PKG-INFO to determine its +version number. + +Setuptools, however, only includes the version number in the filename +when an ‘.egg’ file is built using the ‘bdist_egg’ command, or when an +‘.egg-info’ directory is being installed by the ‘install_egg_info’ +command. When generating metadata for use with the original source +tree, it only includes the project name, so that the directory will not +have to be renamed each time the project’s version changes. + +This is especially important when version numbers change frequently, and +the source metadata directory is kept under version control with the +rest of the project. (As would be the case when the project’s source +includes project-defined metadata that is not generated from by +setuptools from data in the setup script.) + + +File: setuptools.info, Node: Egg Links, Prev: Filename-Embedded Metadata, Up: Eggs and their Formats + +8.2.1.4 Egg Links +................. + +In addition to the ‘.egg’ and ‘.egg-info’ formats, there is a third +egg-related extension that you may encounter on occasion: ‘.egg-link’ +files. + +These files are not eggs, strictly speaking. They simply provide a way +to reference an egg that is not physically installed in the desired +location. They exist primarily as a cross-platform alternative to +symbolic links, to support “installing” code that is being developed in +a different location than the desired installation location. For +example, if a user is developing an application plugin in their home +directory, but the plugin needs to be “installed” in an application +plugin directory, running “setup.py develop -md /path/to/app/plugins” +will install an ‘.egg-link’ file in ‘/path/to/app/plugins’, that tells +the egg runtime system where to find the actual egg (the user’s project +source directory and its ‘.egg-info’ subdirectory). + +‘.egg-link’ files are named following the format for ‘.egg’ and +‘.egg-info’ names, but only the project name is included; no version, +Python version, or platform information is included. When the runtime +searches for available eggs, ‘.egg-link’ files are opened and the actual +egg file/directory name is read from them. + +Each ‘.egg-link’ file should contain a single file or directory name, +with no newlines. This filename should be the base location of one or +more eggs. That is, the name must either end in ‘.egg’, or else it +should be the parent directory of one or more ‘.egg-info’ format eggs. + +As of setuptools 0.6c6, the path may be specified as a +platform-independent (i.e. ‘/’-separated) relative path from the +directory containing the ‘.egg-link’ file, and a second line may appear +in the file, specifying a platform-independent relative path from the +egg’s base directory to its setup script directory. This allows +installation tools such as EasyInstall to find the project’s setup +directory and build eggs or perform other setup commands on it. + + +File: setuptools.info, Node: Standard Metadata, Next: Other Technical Considerations, Prev: Eggs and their Formats, Up: The Internal Structure of Python Eggs + +8.2.2 Standard Metadata +----------------------- + +In addition to the minimum required ‘PKG-INFO’ metadata, projects can +include a variety of standard metadata files or directories, as +described below. Except as otherwise noted, these files and directories +are automatically generated by setuptools, based on information supplied +in the setup script or through analysis of the project’s code and +resources. + +Most of these files and directories are generated via “egg-info writers” +during execution of the setuptools ‘egg_info’ command, and are listed in +the ‘egg_info.writers’ entry point group defined by setuptools’ own +‘setup.py’ file. + +Project authors can register their own metadata writers as entry points +in this group (as described in the setuptools manual under “Adding new +EGG-INFO Files”) to cause setuptools to generate project-specific +metadata files or directories during execution of the ‘egg_info’ +command. It is up to project authors to document these new metadata +formats, if they create any. + +* Menu: + +* .txt File Formats: txt File Formats. +* Dependency Metadata:: +* namespace_packages.txt – Namespace Package Metadata: namespace_packages txt – Namespace Package Metadata. +* entry_points.txt – “Entry Point”/Plugin Metadata: entry_points txt – “Entry Point”/Plugin Metadata. +* The scripts Subdirectory:: +* Zip Support Metadata:: +* top_level.txt – Conflict Management Metadata: top_level txt – Conflict Management Metadata. +* SOURCES.txt – Source Files Manifest: SOURCES txt – Source Files Manifest. + + +File: setuptools.info, Node: txt File Formats, Next: Dependency Metadata, Up: Standard Metadata + +8.2.2.1 ‘.txt’ File Formats +........................... + +Files described in this section that have ‘.txt’ extensions have a +simple lexical format consisting of a sequence of text lines, each line +terminated by a linefeed character (regardless of platform). Leading +and trailing whitespace on each line is ignored, as are blank lines and +lines whose first nonblank character is a ‘#’ (comment symbol). (This +is the parsing format defined by the ‘yield_lines()’ function of the +‘pkg_resources’ module.) + +All ‘.txt’ files defined by this section follow this format, but some +are also “sectioned” files, meaning that their contents are divided into +sections, using square-bracketed section headers akin to Windows ‘.ini’ +format. Note that this does `not' imply that the lines within the +sections follow an ‘.ini’ format, however. Please see an individual +metadata file’s documentation for a description of what the lines and +section names mean in that particular file. + +Sectioned files can be parsed using the ‘split_sections()’ function; see +the “Parsing Utilities” section of the ‘pkg_resources’ manual for for +details. + + +File: setuptools.info, Node: Dependency Metadata, Next: namespace_packages txt – Namespace Package Metadata, Prev: txt File Formats, Up: Standard Metadata + +8.2.2.2 Dependency Metadata +........................... + +* Menu: + +* requires.txt: requires txt. +* setup_requires.txt: setup_requires txt. +* dependency_links.txt: dependency_links txt. +* depends.txt – Obsolete, do not create!: depends txt – Obsolete do not create!. + + +File: setuptools.info, Node: requires txt, Next: setup_requires txt, Up: Dependency Metadata + +8.2.2.3 ‘requires.txt’ +...................... + +This is a “sectioned” text file. Each section is a sequence of +“requirements”, as parsed by the ‘parse_requirements()’ function; please +see the ‘pkg_resources’ manual for the complete requirement parsing +syntax. + +The first, unnamed section (i.e., before the first section header) in +this file is the project’s core requirements, which must be installed +for the project to function. (Specified using the ‘install_requires’ +keyword to ‘setup()’). + +The remaining (named) sections describe the project’s “extra” +requirements, as specified using the ‘extras_require’ keyword to +‘setup()’. The section name is the name of the optional feature, and +the section body lists that feature’s dependencies. + +Note that it is not normally necessary to inspect this file directly; +‘pkg_resources.Distribution’ objects have a ‘requires()’ method that can +be used to obtain ‘Requirement’ objects describing the project’s core +and optional dependencies. + + +File: setuptools.info, Node: setup_requires txt, Next: dependency_links txt, Prev: requires txt, Up: Dependency Metadata + +8.2.2.4 ‘setup_requires.txt’ +............................ + +Much like ‘requires.txt’ except represents the requirements specified by +the ‘setup_requires’ parameter to the Distribution. + + +File: setuptools.info, Node: dependency_links txt, Next: depends txt – Obsolete do not create!, Prev: setup_requires txt, Up: Dependency Metadata + +8.2.2.5 ‘dependency_links.txt’ +.............................. + +A list of dependency URLs, one per line, as specified using the +‘dependency_links’ keyword to ‘setup()’. These may be direct download +URLs, or the URLs of web pages containing direct download links. Please +see the setuptools manual for more information on specifying this +option. + + +File: setuptools.info, Node: depends txt – Obsolete do not create!, Prev: dependency_links txt, Up: Dependency Metadata + +8.2.2.6 ‘depends.txt’ – Obsolete, do not create! +................................................ + +This file follows an identical format to ‘requires.txt’, but is obsolete +and should not be used. The earliest versions of setuptools required +users to manually create and maintain this file, so the runtime still +supports reading it, if it exists. The new filename was created so that +it could be automatically generated from ‘setup()’ information without +overwriting an existing hand-created ‘depends.txt’, if one was already +present in the project’s source ‘.egg-info’ directory. + + +File: setuptools.info, Node: namespace_packages txt – Namespace Package Metadata, Next: entry_points txt – “Entry Point”/Plugin Metadata, Prev: Dependency Metadata, Up: Standard Metadata + +8.2.2.7 ‘namespace_packages.txt’ – Namespace Package Metadata +............................................................. + +A list of namespace package names, one per line, as supplied to the +‘namespace_packages’ keyword to ‘setup()’. Please see the manuals for +setuptools and ‘pkg_resources’ for more information about namespace +packages. + + +File: setuptools.info, Node: entry_points txt – “Entry Point”/Plugin Metadata, Next: The scripts Subdirectory, Prev: namespace_packages txt – Namespace Package Metadata, Up: Standard Metadata + +8.2.2.8 ‘entry_points.txt’ – “Entry Point”/Plugin Metadata +.......................................................... + +This is a “sectioned” text file, whose contents encode the +‘entry_points’ keyword supplied to ‘setup()’. All sections are named, +as the section names specify the entry point groups in which the +corresponding section’s entry points are registered. + +Each section is a sequence of “entry point” lines, each parseable using +the ‘EntryPoint.parse’ classmethod; please see the ‘pkg_resources’ +manual for the complete entry point parsing syntax. + +Note that it is not necessary to parse this file directly; the +‘pkg_resources’ module provides a variety of APIs to locate and load +entry points automatically. Please see the setuptools and +‘pkg_resources’ manuals for details on the nature and uses of entry +points. + + +File: setuptools.info, Node: The scripts Subdirectory, Next: Zip Support Metadata, Prev: entry_points txt – “Entry Point”/Plugin Metadata, Up: Standard Metadata + +8.2.2.9 The ‘scripts’ Subdirectory +.................................. + +This directory is currently only created for ‘.egg’ files built by the +setuptools ‘bdist_egg’ command. It will contain copies of all of the +project’s “traditional” scripts (i.e., those specified using the +‘scripts’ keyword to ‘setup()’). This is so that they can be +reconstituted when an ‘.egg’ file is installed. + +The scripts are placed here using the distutils’ standard +‘install_scripts’ command, so any ‘#!’ lines reflect the Python +installation where the egg was built. But instead of copying the +scripts to the local script installation directory, EasyInstall writes +short wrapper scripts that invoke the original scripts from inside the +egg, after ensuring that sys.path includes the egg and any eggs it +depends on. For more about *note script wrappers: d7, see the section +below on *note Installation and Path Management Issues: d8. + + +File: setuptools.info, Node: Zip Support Metadata, Next: top_level txt – Conflict Management Metadata, Prev: The scripts Subdirectory, Up: Standard Metadata + +8.2.2.10 Zip Support Metadata +............................. + +* Menu: + +* native_libs.txt: native_libs txt. +* eager_resources.txt: eager_resources txt. +* zip-safe and not-zip-safe:: + + +File: setuptools.info, Node: native_libs txt, Next: eager_resources txt, Up: Zip Support Metadata + +8.2.2.11 ‘native_libs.txt’ +.......................... + +A list of C extensions and other dynamic link libraries contained in the +egg, one per line. Paths are ‘/’-separated and relative to the egg’s +base location. + +This file is generated as part of ‘bdist_egg’ processing, and as such +only appears in ‘.egg’ files (and ‘.egg’ directories created by +unpacking them). It is used to ensure that all libraries are extracted +from a zipped egg at the same time, in case there is any direct linkage +between them. Please see the *note Zip File Issues: db. section below +for more information on library and resource extraction from ‘.egg’ +files. + + +File: setuptools.info, Node: eager_resources txt, Next: zip-safe and not-zip-safe, Prev: native_libs txt, Up: Zip Support Metadata + +8.2.2.12 ‘eager_resources.txt’ +.............................. + +A list of resource files and/or directories, one per line, as specified +via the ‘eager_resources’ keyword to ‘setup()’. Paths are ‘/’-separated +and relative to the egg’s base location. + +Resource files or directories listed here will be extracted +simultaneously, if any of the named resources are extracted, or if any +native libraries listed in ‘native_libs.txt’ are extracted. Please see +the setuptools manual for details on what this feature is used for and +how it works, as well as the *note Zip File Issues: db. section below. + + +File: setuptools.info, Node: zip-safe and not-zip-safe, Prev: eager_resources txt, Up: Zip Support Metadata + +8.2.2.13 ‘zip-safe’ and ‘not-zip-safe’ +...................................... + +These are zero-length files, and either one or the other should exist. +If ‘zip-safe’ exists, it means that the project will work properly when +installed as an ‘.egg’ zipfile, and conversely the existence of +‘not-zip-safe’ means the project should not be installed as an ‘.egg’ +file. The ‘zip_safe’ option to setuptools’ ‘setup()’ determines which +file will be written. If the option isn’t provided, setuptools attempts +to make its own assessment of whether the package can work, based on +code and content analysis. + +If neither file is present at installation time, EasyInstall defaults to +assuming that the project should be unzipped. (Command-line options to +EasyInstall, however, take precedence even over an existing ‘zip-safe’ +or ‘not-zip-safe’ file.) + +Note that these flag files appear only in ‘.egg’ files generated by +‘bdist_egg’, and in ‘.egg’ directories created by unpacking such an +‘.egg’ file. + + +File: setuptools.info, Node: top_level txt – Conflict Management Metadata, Next: SOURCES txt – Source Files Manifest, Prev: Zip Support Metadata, Up: Standard Metadata + +8.2.2.14 ‘top_level.txt’ – Conflict Management Metadata +....................................................... + +This file is a list of the top-level module or package names provided by +the project, one Python identifier per line. + +Subpackages are not included; a project containing both a ‘foo.bar’ and +a ‘foo.baz’ would include only one line, ‘foo’, in its ‘top_level.txt’. + +This data is used by ‘pkg_resources’ at runtime to issue a warning if an +egg is added to ‘sys.path’ when its contained packages may have already +been imported. + +(It was also once used to detect conflicts with non-egg packages at +installation time, but in more recent versions, setuptools installs eggs +in such a way that they always override non-egg packages, thus +preventing a problem from arising.) + + +File: setuptools.info, Node: SOURCES txt – Source Files Manifest, Prev: top_level txt – Conflict Management Metadata, Up: Standard Metadata + +8.2.2.15 ‘SOURCES.txt’ – Source Files Manifest +.............................................. + +This file is roughly equivalent to the distutils’ ‘MANIFEST’ file. The +differences are as follows: + + * The filenames always use ‘/’ as a path separator, which must be + converted back to a platform-specific path whenever they are read. + + * The file is automatically generated by setuptools whenever the + ‘egg_info’ or ‘sdist’ commands are run, and it is `not' + user-editable. + +Although this metadata is included with distributed eggs, it is not +actually used at runtime for any purpose. Its function is to ensure +that setuptools-built `source' distributions can correctly discover what +files are part of the project’s source, even if the list had been +generated using revision control metadata on the original author’s +system. + +In other words, ‘SOURCES.txt’ has little or no runtime value for being +included in distributed eggs, and it is possible that future versions of +the ‘bdist_egg’ and ‘install_egg_info’ commands will strip it before +installation or distribution. Therefore, do not rely on its being +available outside of an original source directory or source +distribution. + + +File: setuptools.info, Node: Other Technical Considerations, Prev: Standard Metadata, Up: The Internal Structure of Python Eggs + +8.2.3 Other Technical Considerations +------------------------------------ + +* Menu: + +* Zip File Issues:: +* Installation and Path Management Issues:: + + +File: setuptools.info, Node: Zip File Issues, Next: Installation and Path Management Issues, Up: Other Technical Considerations + +8.2.3.1 Zip File Issues +....................... + +Although zip files resemble directories, they are not fully +substitutable for them. Most platforms do not support loading dynamic +link libraries contained in zipfiles, so it is not possible to directly +import C extensions from ‘.egg’ zipfiles. Similarly, there are many +existing libraries – whether in Python or C – that require actual +operating system filenames, and do not work with arbitrary “file-like” +objects or in-memory strings, and thus cannot operate directly on the +contents of zip files. + +To address these issues, the ‘pkg_resources’ module provides a “resource +API” to support obtaining either the contents of a resource, or a true +operating system filename for the resource. If the egg containing the +resource is a directory, the resource’s real filename is simply +returned. However, if the egg is a zipfile, then the resource is first +extracted to a cache directory, and the filename within the cache is +returned. + +The cache directory is determined by the ‘pkg_resources’ API; please see +the ‘set_cache_path()’ and ‘get_default_cache()’ documentation for +details. + +* Menu: + +* The Extraction Process:: +* Extension Import Wrappers:: + + +File: setuptools.info, Node: The Extraction Process, Next: Extension Import Wrappers, Up: Zip File Issues + +8.2.3.2 The Extraction Process +.............................. + +Resources are extracted to a cache subdirectory whose name is based on +the enclosing ‘.egg’ filename and the path to the resource. If there is +already a file of the correct name, size, and timestamp, its filename is +returned to the requester. Otherwise, the desired file is extracted +first to a temporary name generated using +‘mkstemp(".$extract",target_dir)’, and then its timestamp is set to +match the one in the zip file, before renaming it to its final name. +(Some collision detection and resolution code is used to handle the fact +that Windows doesn’t overwrite files when renaming.) + +If a resource directory is requested, all of its contents are +recursively extracted in this fashion, to ensure that the directory name +can be used as if it were valid all along. + +If the resource requested for extraction is listed in the +‘native_libs.txt’ or ‘eager_resources.txt’ metadata files, then `all' +resources listed in `either' file will be extracted before the requested +resource’s filename is returned, thus ensuring that all C extensions and +data used by them will be simultaneously available. + + +File: setuptools.info, Node: Extension Import Wrappers, Prev: The Extraction Process, Up: Zip File Issues + +8.2.3.3 Extension Import Wrappers +................................. + +Since Python’s built-in zip import feature does not support loading C +extension modules from zipfiles, the setuptools ‘bdist_egg’ command +generates special import wrappers to make it work. + +The wrappers are ‘.py’ files (along with corresponding ‘.pyc’ and/or +‘.pyo’ files) that have the same module name as the corresponding C +extension. These wrappers are located in the same package directory (or +top-level directory) within the zipfile, so that say, ‘foomodule.so’ +will get a corresponding ‘foo.py’, while ‘bar/baz.pyd’ will get a +corresponding ‘bar/baz.py’. + +These wrapper files contain a short stanza of Python code that asks +‘pkg_resources’ for the filename of the corresponding C extension, then +reloads the module using the obtained filename. This will cause +‘pkg_resources’ to first ensure that all of the egg’s C extensions (and +any accompanying “eager resources”) are extracted to the cache before +attempting to link to the C library. + +Note, by the way, that ‘.egg’ directories will also contain these +wrapper files. However, Python’s default import priority is such that C +extensions take precedence over same-named Python modules, so the import +wrappers are ignored unless the egg is a zipfile. + + +File: setuptools.info, Node: Installation and Path Management Issues, Prev: Zip File Issues, Up: Other Technical Considerations + +8.2.3.4 Installation and Path Management Issues +............................................... + +Python’s initial setup of ‘sys.path’ is very dependent on the Python +version and installation platform, as well as how Python was started +(i.e., script vs. ‘-c’ vs. ‘-m’ vs. interactive interpreter). In +fact, Python also provides only two relatively robust ways to affect +‘sys.path’ outside of direct manipulation in code: the ‘PYTHONPATH’ +environment variable, and ‘.pth’ files. + +However, with no cross-platform way to safely and persistently change +environment variables, this leaves ‘.pth’ files as EasyInstall’s only +real option for persistent configuration of ‘sys.path’. + +But ‘.pth’ files are rather strictly limited in what they are allowed to +do normally. They add directories only to the `end' of ‘sys.path’, +after any locally-installed ‘site-packages’ directory, and they are only +processed `in' the ‘site-packages’ directory to start with. + +This is a double whammy for users who lack write access to that +directory, because they can’t create a ‘.pth’ file that Python will +read, and even if a sympathetic system administrator adds one for them +that calls ‘site.addsitedir()’ to allow some other directory to contain +‘.pth’ files, they won’t be able to install newer versions of anything +that’s installed in the systemwide ‘site-packages’, because their paths +will still be added `after' ‘site-packages’. + +So EasyInstall applies two workarounds to solve these problems. + +The first is that EasyInstall leverages ‘.pth’ files’ “import” feature +to manipulate ‘sys.path’ and ensure that anything EasyInstall adds to a +‘.pth’ file will always appear before both the standard library and the +local ‘site-packages’ directories. Thus, it is always possible for a +user who can write a Python-read ‘.pth’ file to ensure that their +packages come first in their own environment. + +Second, when installing to a ‘PYTHONPATH’ directory (as opposed to a +“site” directory like ‘site-packages’) EasyInstall will also install a +special version of the ‘site’ module. Because it’s in a ‘PYTHONPATH’ +directory, this module will get control before the standard library +version of ‘site’ does. It will record the state of ‘sys.path’ before +invoking the “real” ‘site’ module, and then afterwards it processes any +‘.pth’ files found in ‘PYTHONPATH’ directories, including all the fixups +needed to ensure that eggs always appear before the standard library in +sys.path, but are in a relative order to one another that is defined by +their ‘PYTHONPATH’ and ‘.pth’-prescribed sequence. + +The net result of these changes is that ‘sys.path’ order will be as +follows at runtime: + + 1. The ‘sys.argv[0]’ directory, or an empty string if no script is + being executed. + + 2. All eggs installed by EasyInstall in any ‘.pth’ file in each + ‘PYTHONPATH’ directory, in order first by ‘PYTHONPATH’ order, then + normal ‘.pth’ processing order (which is to say alphabetical by + ‘.pth’ filename, then by the order of listing within each ‘.pth’ + file). + + 3. All eggs installed by EasyInstall in any ‘.pth’ file in each “site” + directory (such as ‘site-packages’), following the same ordering + rules as for the ones on ‘PYTHONPATH’. + + 4. The ‘PYTHONPATH’ directories themselves, in their original order + + 5. Any paths from ‘.pth’ files found on ‘PYTHONPATH’ that were `not' + eggs installed by EasyInstall, again following the same relative + ordering rules. + + 6. The standard library and “site” directories, along with the + contents of any ‘.pth’ files found in the “site” directories. + +Notice that sections 1, 4, and 6 comprise the “normal” Python setup for +‘sys.path’. Sections 2 and 3 are inserted to support eggs, and section +5 emulates what the “normal” semantics of ‘.pth’ files on ‘PYTHONPATH’ +would be if Python natively supported them. + +For further discussion of the tradeoffs that went into this design, as +well as notes on the actual magic inserted into ‘.pth’ files to make +them do these things, please see also the following messages to the +distutils-SIG mailing list: + + * + ‘http://mail.python.org/pipermail/distutils-sig/2006-February/006026.html’ + + * + ‘http://mail.python.org/pipermail/distutils-sig/2006-March/006123.html’ + +* Menu: + +* Script Wrappers:: + + +File: setuptools.info, Node: Script Wrappers, Up: Installation and Path Management Issues + +8.2.3.5 Script Wrappers +....................... + +EasyInstall never directly installs a project’s original scripts to a +script installation directory. Instead, it writes short wrapper scripts +that first ensure that the project’s dependencies are active on +sys.path, before invoking the original script. These wrappers have a #! +line that points to the version of Python that was used to install them, +and their second line is always a comment that indicates the type of +script wrapper, the project version required for the script to run, and +information identifying the script to be invoked. + +The format of this marker line is: + + "# EASY-INSTALL-" script_type ": " tuple_of_strings "\n" + +The ‘script_type’ is one of ‘SCRIPT’, ‘DEV-SCRIPT’, or ‘ENTRY-SCRIPT’. +The ‘tuple_of_strings’ is a comma-separated sequence of Python string +constants. For ‘SCRIPT’ and ‘DEV-SCRIPT’ wrappers, there are two +strings: the project version requirement, and the script name (as a +filename within the ‘scripts’ metadata directory). For ‘ENTRY-SCRIPT’ +wrappers, there are three: the project version requirement, the entry +point group name, and the entry point name. (See the “Automatic Script +Creation” section in the setuptools manual for more information about +entry point scripts.) + +In each case, the project version requirement string will be a string +parseable with the ‘pkg_resources’ modules’ ‘Requirement.parse()’ +classmethod. The only difference between a ‘SCRIPT’ wrapper and a +‘DEV-SCRIPT’ is that a ‘DEV-SCRIPT’ actually executes the original +source script in the project’s source tree, and is created when the +“setup.py develop” command is run. A ‘SCRIPT’ wrapper, on the other +hand, uses the “installed” script written to the ‘EGG-INFO/scripts’ +subdirectory of the corresponding ‘.egg’ zipfile or directory. +(‘.egg-info’ eggs do not have script wrappers associated with them, +except in the “setup.py develop” case.) + +The purpose of including the marker line in generated script wrappers is +to facilitate introspection of installed scripts, and their relationship +to installed eggs. For example, an uninstallation tool could use this +data to identify what scripts can safely be removed, and/or identify +what scripts would stop working if a particular egg is uninstalled. + + +File: setuptools.info, Node: Easy Install, Next: Porting from Distutils, Prev: The Internal Structure of Python Eggs, Up: Guides on backward compatibility & deprecated practice + +8.3 Easy Install +================ + + Warning: Easy Install is deprecated. Do not use it. Instead use + pip. If you think you need Easy Install, please reach out to the + PyPA team (a ticket to pip or setuptools is fine), describing your + use-case. + +Easy Install is a python module (‘easy_install’) bundled with +‘setuptools’ that lets you automatically download, build, install, and +manage Python packages. + +Please share your experiences with us! If you encounter difficulty +installing a package, please contact us via the distutils mailing +list(1). (Note: please DO NOT send private email directly to the author +of setuptools; it will be discarded. The mailing list is a searchable +archive of previously-asked and answered questions; you should begin +your research there before reporting something as a bug – and then do so +via list discussion first.) + +(Also, if you’d like to learn about how you can use ‘setuptools’ to make +your own packages work better with EasyInstall, or provide +EasyInstall-like features without requiring your users to use +EasyInstall directly, you’ll probably want to check out the full +documentation as well.) + +* Menu: + +* Using “Easy Install”:: +* Reference Manual:: + + ---------- Footnotes ---------- + + (1) http://mail.python.org/pipermail/distutils-sig/ + + +File: setuptools.info, Node: Using “Easy Install”, Next: Reference Manual, Up: Easy Install + +8.3.1 Using “Easy Install” +-------------------------- + +* Menu: + +* Installing “Easy Install”:: +* Downloading and Installing a Package:: +* Upgrading a Package:: +* Changing the Active Version:: +* Uninstalling Packages:: +* Managing Scripts:: +* Executables and Launchers:: +* Tips & Techniques:: +* Password-Protected Sites:: +* Using .pypirc Credentials: Using pypirc Credentials. + + +File: setuptools.info, Node: Installing “Easy Install”, Next: Downloading and Installing a Package, Up: Using “Easy Install” + +8.3.1.1 Installing “Easy Install” +................................. + +Please see the setuptools PyPI page(1) for download links and basic +installation instructions for each of the supported platforms. + +You will need at least Python 3.5 or 2.7. An ‘easy_install’ script will +be installed in the normal location for Python scripts on your platform. + +Note that the instructions on the setuptools PyPI page assume that you +are are installing to Python’s primary ‘site-packages’ directory. If +this is not the case, you should consult the section below on *note +Custom Installation Locations: e8. before installing. (And, on Windows, +you should not use the ‘.exe’ installer when installing to an alternate +location.) + +Note that ‘easy_install’ normally works by downloading files from the +internet. If you are behind an NTLM-based firewall that prevents Python +programs from accessing the net directly, you may wish to first install +and use the APS proxy server(2), which lets you get past such firewalls +in the same way that your web browser(s) do. + +(Alternately, if you do not wish easy_install to actually download +anything, you can restrict it from doing so with the ‘--allow-hosts’ +option; see the sections on *note restricting downloads with +–allow-hosts: e9. and *note command-line options: ea. for more details.) + +* Menu: + +* Troubleshooting:: +* Windows Notes:: + + ---------- Footnotes ---------- + + (1) https://pypi.org/project/setuptools/ + + (2) http://ntlmaps.sf.net/ + + +File: setuptools.info, Node: Troubleshooting, Next: Windows Notes, Up: Installing “Easy Install” + +8.3.1.2 Troubleshooting +....................... + +If EasyInstall/setuptools appears to install correctly, and you can run +the ‘easy_install’ command but it fails with an ‘ImportError’, the most +likely cause is that you installed to a location other than +‘site-packages’, without taking any of the steps described in the *note +Custom Installation Locations: e8. section below. Please see that +section and follow the steps to make sure that your custom location will +work correctly. Then re-install. + +Similarly, if you can run ‘easy_install’, and it appears to be +installing packages, but then you can’t import them, the most likely +issue is that you installed EasyInstall correctly but are using it to +install packages to a non-standard location that hasn’t been properly +prepared. Again, see the section on *note Custom Installation +Locations: e8. for more details. + + +File: setuptools.info, Node: Windows Notes, Prev: Troubleshooting, Up: Installing “Easy Install” + +8.3.1.3 Windows Notes +..................... + +Installing setuptools will provide an ‘easy_install’ command according +to the techniques described in *note Executables and Launchers: ed. If +the ‘easy_install’ command is not available after installation, that +section provides details on how to configure Windows to make the +commands available. + + +File: setuptools.info, Node: Downloading and Installing a Package, Next: Upgrading a Package, Prev: Installing “Easy Install”, Up: Using “Easy Install” + +8.3.1.4 Downloading and Installing a Package +............................................ + +For basic use of ‘easy_install’, you need only supply the filename or +URL of a source distribution or .egg file (Python Egg(1)). + +`Example 1'. Install a package by name, searching PyPI for the latest +version, and automatically downloading, building, and installing it: + + easy_install SQLObject + +`Example 2'. Install or upgrade a package by name and version by +finding links on a given “download page”: + + easy_install -f http://pythonpaste.org/package_index.html SQLObject + +`Example 3'. Download a source distribution from a specified URL, +automatically building and installing it: + + easy_install http://example.com/path/to/MyPackage-1.2.3.tgz + +`Example 4'. Install an already-downloaded .egg file: + + easy_install /my_downloads/OtherPackage-3.2.1-py2.3.egg + +`Example 5'. Upgrade an already-installed package to the latest version +listed on PyPI: + + easy_install --upgrade PyProtocols + +`Example 6'. Install a source distribution that’s already downloaded +and extracted in the current directory (New in 0.5a9): + + easy_install . + +`Example 7'. (New in 0.6a1) Find a source distribution or Subversion +checkout URL for a package, and extract it or check it out to +‘~/projects/sqlobject’ (the name will always be in all-lowercase), where +it can be examined or edited. (The package will not be installed, but +it can easily be installed with ‘easy_install ~/projects/sqlobject’. +See *note Editing and Viewing Source Packages: ef. below for more +info.): + + easy_install --editable --build-directory ~/projects SQLObject + +`Example 7'. (New in 0.6.11) Install a distribution within your home +dir: + + easy_install --user SQLAlchemy + +Easy Install accepts URLs, filenames, PyPI package names (i.e., +‘distutils’ “distribution” names), and package+version specifiers. In +each case, it will attempt to locate the latest available version that +meets your criteria. + +When downloading or processing downloaded files, Easy Install recognizes +distutils source distribution files with extensions of .tgz, .tar, +.tar.gz, .tar.bz2, or .zip. And of course it handles already-built .egg +distributions as well as ‘.win32.exe’ installers built using distutils. + +By default, packages are installed to the running Python installation’s +‘site-packages’ directory, unless you provide the ‘-d’ or +‘--install-dir’ option to specify an alternative directory, or specify +an alternate location using distutils configuration files. (See *note +Configuration Files: f0, below.) + +By default, any scripts included with the package are installed to the +running Python installation’s standard script installation location. +However, if you specify an installation directory via the command line +or a config file, then the default directory for installing scripts will +be the same as the package installation directory, to ensure that the +script will have access to the installed package. You can override this +using the ‘-s’ or ‘--script-dir’ option. + +Installed packages are added to an ‘easy-install.pth’ file in the +install directory, so that Python will always use the +most-recently-installed version of the package. If you would like to be +able to select which version to use at runtime, you should use the ‘-m’ +or ‘--multi-version’ option. + + ---------- Footnotes ---------- + + (1) http://peak.telecommunity.com/DevCenter/PythonEggs + + +File: setuptools.info, Node: Upgrading a Package, Next: Changing the Active Version, Prev: Downloading and Installing a Package, Up: Using “Easy Install” + +8.3.1.5 Upgrading a Package +........................... + +You don’t need to do anything special to upgrade a package: just install +the new version, either by requesting a specific version, e.g.: + + easy_install "SomePackage==2.0" + +a version greater than the one you have now: + + easy_install "SomePackage>2.0" + +using the upgrade flag, to find the latest available version on PyPI: + + easy_install --upgrade SomePackage + +or by using a download page, direct download URL, or package filename: + + easy_install -f http://example.com/downloads ExamplePackage + + easy_install http://example.com/downloads/ExamplePackage-2.0-py2.4.egg + + easy_install my_downloads/ExamplePackage-2.0.tgz + +If you’re using ‘-m’ or ‘--multi-version’ , using the ‘require()’ +function at runtime automatically selects the newest installed version +of a package that meets your version criteria. So, installing a newer +version is the only step needed to upgrade such packages. + +If you’re installing to a directory on PYTHONPATH, or a configured +“site” directory (and not using ‘-m’), installing a package +automatically replaces any previous version in the ‘easy-install.pth’ +file, so that Python will import the most-recently installed version by +default. So, again, installing the newer version is the only upgrade +step needed. + +If you haven’t suppressed script installation (using ‘--exclude-scripts’ +or ‘-x’), then the upgraded version’s scripts will be installed, and +they will be automatically patched to ‘require()’ the corresponding +version of the package, so that you can use them even if they are +installed in multi-version mode. + +‘easy_install’ never actually deletes packages (unless you’re installing +a package with the same name and version number as an existing package), +so if you want to get rid of older versions of a package, please see +*note Uninstalling Packages: f2, below. + + +File: setuptools.info, Node: Changing the Active Version, Next: Uninstalling Packages, Prev: Upgrading a Package, Up: Using “Easy Install” + +8.3.1.6 Changing the Active Version +................................... + +If you’ve upgraded a package, but need to revert to a +previously-installed version, you can do so like this: + + easy_install PackageName==1.2.3 + +Where ‘1.2.3’ is replaced by the exact version number you wish to switch +to. If a package matching the requested name and version is not already +installed in a directory on ‘sys.path’, it will be located via PyPI and +installed. + +If you’d like to switch to the latest installed version of +‘PackageName’, you can do so like this: + + easy_install PackageName + +This will activate the latest installed version. (Note: if you have set +any ‘find_links’ via distutils configuration files, those download pages +will be checked for the latest available version of the package, and it +will be downloaded and installed if it is newer than your current +version.) + +Note that changing the active version of a package will install the +newly active version’s scripts, unless the ‘--exclude-scripts’ or ‘-x’ +option is specified. + + +File: setuptools.info, Node: Uninstalling Packages, Next: Managing Scripts, Prev: Changing the Active Version, Up: Using “Easy Install” + +8.3.1.7 Uninstalling Packages +............................. + +If you have replaced a package with another version, then you can just +delete the package(s) you don’t need by deleting the +PackageName-versioninfo.egg file or directory (found in the installation +directory). + +If you want to delete the currently installed version of a package (or +all versions of a package), you should first run: + + easy_install -m PackageName + +This will ensure that Python doesn’t continue to search for a package +you’re planning to remove. After you’ve done this, you can safely +delete the .egg files or directories, along with any scripts you wish to +remove. + + +File: setuptools.info, Node: Managing Scripts, Next: Executables and Launchers, Prev: Uninstalling Packages, Up: Using “Easy Install” + +8.3.1.8 Managing Scripts +........................ + +Whenever you install, upgrade, or change versions of a package, +EasyInstall automatically installs the scripts for the selected package +version, unless you tell it not to with ‘-x’ or ‘--exclude-scripts’. If +any scripts in the script directory have the same name, they are +overwritten. + +Thus, you do not normally need to manually delete scripts for older +versions of a package, unless the newer version of the package does not +include a script of the same name. However, if you are completely +uninstalling a package, you may wish to manually delete its scripts. + +EasyInstall’s default behavior means that you can normally only run +scripts from one version of a package at a time. If you want to keep +multiple versions of a script available, however, you can simply use the +‘--multi-version’ or ‘-m’ option, and rename the scripts that +EasyInstall creates. This works because EasyInstall installs scripts as +short code stubs that ‘require()’ the matching version of the package +the script came from, so renaming the script has no effect on what it +executes. + +For example, suppose you want to use two versions of the ‘rst2html’ tool +provided by the docutils(1) package. You might first install one +version: + + easy_install -m docutils==0.3.9 + +then rename the ‘rst2html.py’ to ‘r2h_039’, and install another version: + + easy_install -m docutils==0.3.10 + +This will create another ‘rst2html.py’ script, this one using docutils +version 0.3.10 instead of 0.3.9. You now have two scripts, each using a +different version of the package. (Notice that we used ‘-m’ for both +installations, so that Python won’t lock us out of using anything but +the most recently-installed version of the package.) + + ---------- Footnotes ---------- + + (1) http://docutils.sf.net/ + + +File: setuptools.info, Node: Executables and Launchers, Next: Tips & Techniques, Prev: Managing Scripts, Up: Using “Easy Install” + +8.3.1.9 Executables and Launchers +................................. + +On Unix systems, scripts are installed with as natural files with a “#!” +header and no extension and they launch under the Python version +indicated in the header. + +On Windows, there is no mechanism to “execute” files without extensions, +so EasyInstall provides two techniques to mirror the Unix behavior. The +behavior is indicated by the SETUPTOOLS_LAUNCHER environment variable, +which may be “executable” (default) or “natural”. + +Regardless of the technique used, the script(s) will be installed to a +Scripts directory (by default in the Python installation directory). It +is recommended for EasyInstall that you ensure this directory is in the +PATH environment variable. The easiest way to ensure the Scripts +directory is in the PATH is to run ‘Tools\Scripts\win_add2path.py’ from +the Python directory. + +Note that instead of changing your ‘PATH’ to include the Python scripts +directory, you can also retarget the installation location for scripts +so they go on a directory that’s already on the ‘PATH’. For more +information see *note Command-Line Options: ea. and *note Configuration +Files: f0. During installation, pass command line options (such as +‘--script-dir’) to control where scripts will be installed. + +* Menu: + +* Windows Executable Launcher:: +* Natural Script Launcher:: + + +File: setuptools.info, Node: Windows Executable Launcher, Next: Natural Script Launcher, Up: Executables and Launchers + +8.3.1.10 Windows Executable Launcher +.................................... + +If the “executable” launcher is used, EasyInstall will create a ‘.exe’ +launcher of the same name beside each installed script (including +‘easy_install’ itself). These small .exe files launch the script of the +same name using the Python version indicated in the ‘#!’ header. + +This behavior is currently default. To force the use of executable +launchers, set ‘SETUPTOOLS_LAUNCHER’ to “executable”. + + +File: setuptools.info, Node: Natural Script Launcher, Prev: Windows Executable Launcher, Up: Executables and Launchers + +8.3.1.11 Natural Script Launcher +................................ + +EasyInstall also supports deferring to an external launcher such as +pylauncher(1) for launching scripts. Enable this experimental +functionality by setting the ‘SETUPTOOLS_LAUNCHER’ environment variable +to “natural”. EasyInstall will then install scripts as simple scripts +with a .pya (or .pyw) extension appended. If these extensions are +associated with the pylauncher and listed in the PATHEXT environment +variable, these scripts can then be invoked simply and directly just +like any other executable. This behavior may become default in a future +version. + +EasyInstall uses the .pya extension instead of simply the typical ‘.py’ +extension. This distinct extension is necessary to prevent Python from +treating the scripts as importable modules (where name conflicts exist). +Current releases of pylauncher do not yet associate with .pya files by +default, but future versions should do so. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/pylauncher + + +File: setuptools.info, Node: Tips & Techniques, Next: Password-Protected Sites, Prev: Executables and Launchers, Up: Using “Easy Install” + +8.3.1.12 Tips & Techniques +.......................... + +* Menu: + +* Multiple Python Versions:: +* Restricting Downloads with --allow-hosts:: +* Installing on Un-networked Machines:: +* Packaging Others’ Projects As Eggs:: +* Creating your own Package Index:: + + +File: setuptools.info, Node: Multiple Python Versions, Next: Restricting Downloads with --allow-hosts, Up: Tips & Techniques + +8.3.1.13 Multiple Python Versions +................................. + +EasyInstall installs itself under two names: ‘easy_install’ and +‘easy_install-N.N’, where ‘N.N’ is the Python version used to install +it. Thus, if you install EasyInstall for both Python 3.2 and 2.7, you +can use the ‘easy_install-3.2’ or ‘easy_install-2.7’ scripts to install +packages for the respective Python version. + +Setuptools also supplies easy_install as a runnable module which may be +invoked using ‘python -m easy_install’ for any Python with Setuptools +installed. + + +File: setuptools.info, Node: Restricting Downloads with --allow-hosts, Next: Installing on Un-networked Machines, Prev: Multiple Python Versions, Up: Tips & Techniques + +8.3.1.14 Restricting Downloads with ‘--allow-hosts’ +................................................... + +You can use the ‘--allow-hosts’ (‘-H’) option to restrict what domains +EasyInstall will look for links and downloads on. ‘--allow-hosts=None’ +prevents downloading altogether. You can also use wildcards, for +example to restrict downloading to hosts in your own intranet. See the +section below on *note Command-Line Options: ea. for more details on the +‘--allow-hosts’ option. + +By default, there are no host restrictions in effect, but you can change +this default by editing the appropriate *note configuration files: f0. +and adding: + + [easy_install] + allow_hosts = *.myintranet.example.com,*.python.org + +The above example would then allow downloads only from hosts in the +‘python.org’ and ‘myintranet.example.com’ domains, unless overridden on +the command line. + + +File: setuptools.info, Node: Installing on Un-networked Machines, Next: Packaging Others’ Projects As Eggs, Prev: Restricting Downloads with --allow-hosts, Up: Tips & Techniques + +8.3.1.15 Installing on Un-networked Machines +............................................ + +Just copy the eggs or source packages you need to a directory on the +target machine, then use the ‘-f’ or ‘--find-links’ option to specify +that directory’s location. For example: + + easy_install -H None -f somedir SomePackage + +will attempt to install SomePackage using only eggs and source packages +found in ‘somedir’ and disallowing all remote access. You should of +course make sure you have all of SomePackage’s dependencies available in +somedir. + +If you have another machine of the same operating system and library +versions (or if the packages aren’t platform-specific), you can create +the directory of eggs using a command like this: + + easy_install -zmaxd somedir SomePackage + +This will tell EasyInstall to put zipped eggs or source packages for +SomePackage and all its dependencies into ‘somedir’, without creating +any scripts or .pth files. You can then copy the contents of ‘somedir’ +to the target machine. (‘-z’ means zipped eggs, ‘-m’ means +multi-version, which prevents .pth files from being used, ‘-a’ means to +copy all the eggs needed, even if they’re installed elsewhere on the +machine, and ‘-d’ indicates the directory to place the eggs in.) + +You can also build the eggs from local development packages that were +installed with the ‘setup.py develop’ command, by including the ‘-l’ +option, e.g.: + + easy_install -zmaxld somedir SomePackage + +This will use locally-available source distributions to build the eggs. + + +File: setuptools.info, Node: Packaging Others’ Projects As Eggs, Next: Creating your own Package Index, Prev: Installing on Un-networked Machines, Up: Tips & Techniques + +8.3.1.16 Packaging Others’ Projects As Eggs +........................................... + +Need to distribute a package that isn’t published in egg form? You can +use EasyInstall to build eggs for a project. You’ll want to use the +‘--zip-ok’, ‘--exclude-scripts’, and possibly ‘--no-deps’ options (‘-z’, +‘-x’ and ‘-N’, respectively). Use ‘-d’ or ‘--install-dir’ to specify +the location where you’d like the eggs placed. By placing them in a +directory that is published to the web, you can then make the eggs +available for download, either in an intranet or to the internet at +large. + +If someone distributes a package in the form of a single ‘.py’ file, you +can wrap it in an egg by tacking an ‘#egg=name-version’ suffix on the +file’s URL. So, something like this: + + easy_install -f "http://some.example.com/downloads/foo.py#egg=foo-1.0" foo + +will install the package as an egg, and this: + + easy_install -zmaxd. \ + -f "http://some.example.com/downloads/foo.py#egg=foo-1.0" foo + +will create a ‘.egg’ file in the current directory. + + +File: setuptools.info, Node: Creating your own Package Index, Prev: Packaging Others’ Projects As Eggs, Up: Tips & Techniques + +8.3.1.17 Creating your own Package Index +........................................ + +In addition to local directories and the Python Package Index, +EasyInstall can find download links on most any web page whose URL is +given to the ‘-f’ (‘--find-links’) option. In the simplest case, you +can simply have a web page with links to eggs or Python source packages, +even an automatically generated directory listing (such as the Apache +web server provides). + +If you are setting up an intranet site for package downloads, you may +want to configure the target machines to use your download site by +default, adding something like this to their *note configuration files: +f0.: + + [easy_install] + find_links = http://mypackages.example.com/somedir/ + http://turbogears.org/download/ + http://peak.telecommunity.com/dist/ + +As you can see, you can list multiple URLs separated by whitespace, +continuing on multiple lines if necessary (as long as the subsequent +lines are indented. + +If you are more ambitious, you can also create an entirely custom +package index or PyPI mirror. See the ‘--index-url’ option under *note +Command-Line Options: ea, below, and also the section on *note Package +Index "API": fc. + + +File: setuptools.info, Node: Password-Protected Sites, Next: Using pypirc Credentials, Prev: Tips & Techniques, Up: Using “Easy Install” + +8.3.1.18 Password-Protected Sites +................................. + +If a site you want to download from is password-protected using HTTP +“Basic” authentication, you can specify your credentials in the URL, +like so: + + http://some_userid:some_password@some.example.com/some_path/ + +You can do this with both index page URLs and direct download URLs. As +long as any HTML pages read by easy_install use `relative' links to +point to the downloads, the same user ID and password will be used to do +the downloading. + + +File: setuptools.info, Node: Using pypirc Credentials, Prev: Password-Protected Sites, Up: Using “Easy Install” + +8.3.1.19 Using .pypirc Credentials +.................................. + +In additional to supplying credentials in the URL, ‘easy_install’ will +also honor credentials if present in the .pypirc file. Teams +maintaining a private repository of packages may already have defined +access credentials for uploading packages according to the distutils +documentation. ‘easy_install’ will attempt to honor those if present. +Refer to the distutils documentation for Python 2.5 or later for details +on the syntax. + +* Menu: + +* Controlling Build Options:: +* Editing and Viewing Source Packages:: +* Dealing with Installation Conflicts:: +* Compressed Installation:: + + +File: setuptools.info, Node: Controlling Build Options, Next: Editing and Viewing Source Packages, Up: Using pypirc Credentials + +8.3.1.20 Controlling Build Options +.................................. + +EasyInstall respects standard distutils *note Configuration Files: f0, +so you can use them to configure build options for packages that it +installs from source. For example, if you are on Windows using the +MinGW compiler, you can configure the default compiler by putting +something like this: + + [build] + compiler = mingw32 + +into the appropriate distutils configuration file. In fact, since this +is just normal distutils configuration, it will affect any builds using +that config file, not just ones done by EasyInstall. For example, if +you add those lines to ‘distutils.cfg’ in the ‘distutils’ package +directory, it will be the default compiler for `all' packages you build. +See *note Configuration Files: f0. below for a list of the standard +configuration file locations, and links to more documentation on using +distutils configuration files. + + +File: setuptools.info, Node: Editing and Viewing Source Packages, Next: Dealing with Installation Conflicts, Prev: Controlling Build Options, Up: Using pypirc Credentials + +8.3.1.21 Editing and Viewing Source Packages +............................................ + +Sometimes a package’s source distribution contains additional +documentation, examples, configuration files, etc., that are not part of +its actual code. If you want to be able to examine these files, you can +use the ‘--editable’ option to EasyInstall, and EasyInstall will look +for a source distribution or Subversion URL for the package, then +download and extract it or check it out as a subdirectory of the +‘--build-directory’ you specify. If you then wish to install the +package after editing or configuring it, you can do so by rerunning +EasyInstall with that directory as the target. + +Note that using ‘--editable’ stops EasyInstall from actually building or +installing the package; it just finds, obtains, and possibly unpacks it +for you. This allows you to make changes to the package if necessary, +and to either install it in development mode using ‘setup.py develop’ +(if the package uses setuptools, that is), or by running ‘easy_install +projectdir’ (where ‘projectdir’ is the subdirectory EasyInstall created +for the downloaded package. + +In order to use ‘--editable’ (‘-e’ for short), you `must' also supply a +‘--build-directory’ (‘-b’ for short). The project will be placed in a +subdirectory of the build directory. The subdirectory will have the +same name as the project itself, but in all-lowercase. If a file or +directory of that name already exists, EasyInstall will print an error +message and exit. + +Also, when using ‘--editable’, you cannot use URLs or filenames as +arguments. You `must' specify project names (and optional version +requirements) so that EasyInstall knows what directory name(s) to +create. If you need to force EasyInstall to use a particular URL or +filename, you should specify it as a ‘--find-links’ item (‘-f’ for +short), and then also specify the project name, e.g.: + + easy_install -eb ~/projects \ + -fhttp://prdownloads.sourceforge.net/ctypes/ctypes-0.9.6.tar.gz?download \ + ctypes==0.9.6 + + +File: setuptools.info, Node: Dealing with Installation Conflicts, Next: Compressed Installation, Prev: Editing and Viewing Source Packages, Up: Using pypirc Credentials + +8.3.1.22 Dealing with Installation Conflicts +............................................ + +(NOTE: As of 0.6a11, this section is obsolete; it is retained here only +so that people using older versions of EasyInstall can consult it. As +of version 0.6a11, installation conflicts are handled automatically +without deleting the old or system-installed packages, and without +ignoring the issue. Instead, eggs are automatically shifted to the +front of ‘sys.path’ using special code added to the ‘easy-install.pth’ +file. So, if you are using version 0.6a11 or better of setuptools, you +do not need to worry about conflicts, and the following issues do not +apply to you.) + +EasyInstall installs distributions in a “managed” way, such that each +distribution can be independently activated or deactivated on +‘sys.path’. However, packages that were not installed by EasyInstall +are “unmanaged”, in that they usually live all in one directory and +cannot be independently activated or deactivated. + +As a result, if you are using EasyInstall to upgrade an existing +package, or to install a package with the same name as an existing +package, EasyInstall will warn you of the conflict. (This is an +improvement over ‘setup.py install’, because the ‘distutils’ just +install new packages on top of old ones, possibly combining two +unrelated packages or leaving behind modules that have been deleted in +the newer version of the package.) + +EasyInstall will stop the installation if it detects a conflict between +an existing, “unmanaged” package, and a module or package in any of the +distributions you’re installing. It will display a list of all of the +existing files and directories that would need to be deleted for the new +package to be able to function correctly. To proceed, you must manually +delete these conflicting files and directories and re-run EasyInstall. + +Of course, once you’ve replaced all of your existing “unmanaged” +packages with versions managed by EasyInstall, you won’t have any more +conflicts to worry about! + + +File: setuptools.info, Node: Compressed Installation, Prev: Dealing with Installation Conflicts, Up: Using pypirc Credentials + +8.3.1.23 Compressed Installation +................................ + +EasyInstall tries to install packages in zipped form, if it can. +Zipping packages can improve Python’s overall import performance if +you’re not using the ‘--multi-version’ option, because Python processes +zipfile entries on ‘sys.path’ much faster than it does directories. + +As of version 0.5a9, EasyInstall analyzes packages to determine whether +they can be safely installed as a zipfile, and then acts on its +analysis. (Previous versions would not install a package as a zipfile +unless you used the ‘--zip-ok’ option.) + +The current analysis approach is fairly conservative; it currently looks +for: + + * Any use of the ‘__file__’ or ‘__path__’ variables (which + should be replaced with ‘pkg_resources’ API calls) + + * Possible use of ‘inspect’ functions that expect to manipulate + source files (e.g. ‘inspect.getsource()’) + + * Top-level modules that might be scripts used with ‘python -m’ + (Python 2.4) + +If any of the above are found in the package being installed, +EasyInstall will assume that the package cannot be safely run from a +zipfile, and unzip it to a directory instead. You can override this +analysis with the ‘-zip-ok’ flag, which will tell EasyInstall to install +the package as a zipfile anyway. Or, you can use the ‘--always-unzip’ +flag, in which case EasyInstall will always unzip, even if its analysis +says the package is safe to run as a zipfile. + +Normally, however, it is simplest to let EasyInstall handle the +determination of whether to zip or unzip, and only specify overrides +when needed to work around a problem. If you find you need to override +EasyInstall’s guesses, you may want to contact the package author and +the EasyInstall maintainers, so that they can make appropriate changes +in future versions. + +(Note: If a package uses ‘setuptools’ in its setup script, the package +author has the option to declare the package safe or unsafe for zipped +usage via the ‘zip_safe’ argument to ‘setup()’. If the package author +makes such a declaration, EasyInstall believes the package’s author and +does not perform its own analysis. However, your command-line option, +if any, will still override the package author’s choice.) + + +File: setuptools.info, Node: Reference Manual, Prev: Using “Easy Install”, Up: Easy Install + +8.3.2 Reference Manual +---------------------- + +* Menu: + +* Configuration Files:: +* Command-Line Options:: +* Custom Installation Locations:: +* Package Index “API”:: + + +File: setuptools.info, Node: Configuration Files, Next: Command-Line Options, Up: Reference Manual + +8.3.2.1 Configuration Files +........................... + +(New in 0.4a2) + +You may specify default options for EasyInstall using the standard +distutils configuration files, under the command heading ‘easy_install’. +EasyInstall will look first for a ‘setup.cfg’ file in the current +directory, then a ‘~/.pydistutils.cfg’ or ‘$HOME\\pydistutils.cfg’ (on +Unix-like OSes and Windows, respectively), and finally a ‘distutils.cfg’ +file in the ‘distutils’ package directory. Here’s a simple example: + + [easy_install] + + # set the default location to install packages + install_dir = /home/me/lib/python + + # Notice that indentation can be used to continue an option + # value; this is especially useful for the "--find-links" + # option, which tells easy_install to use download links on + # these pages before consulting PyPI: + # + find_links = http://sqlobject.org/ + http://peak.telecommunity.com/dist/ + +In addition to accepting configuration for its own options under +‘[easy_install]’, EasyInstall also respects defaults specified for other +distutils commands. For example, if you don’t set an ‘install_dir’ for +‘[easy_install]’, but `have' set an ‘install_lib’ for the ‘[install]’ +command, this will become EasyInstall’s default installation directory. +Thus, if you are already using distutils configuration files to set +default install locations, build options, etc., EasyInstall will respect +your existing settings until and unless you override them explicitly in +an ‘[easy_install]’ section. + +For more information, see also the current Python documentation on the +use and location of distutils configuration files(1). + +Notice that ‘easy_install’ will use the ‘setup.cfg’ from the current +working directory only if it was triggered from ‘setup.py’ through the +‘install_requires’ option. The standalone command will not use that +file. + + ---------- Footnotes ---------- + + (1) https://docs.python.org/install/index.html#inst-config-files + + +File: setuptools.info, Node: Command-Line Options, Next: Custom Installation Locations, Prev: Configuration Files, Up: Reference Manual + +8.3.2.2 Command-Line Options +............................ + +‘--zip-ok, -z’ + + Install all packages as zip files, even if they are marked as + unsafe for running as a zipfile. This can be useful when + EasyInstall’s analysis of a non-setuptools package is too + conservative, but keep in mind that the package may not work + correctly. (Changed in 0.5a9; previously this option was required + in order for zipped installation to happen at all.) + +‘--always-unzip, -Z’ + + Don’t install any packages as zip files, even if the packages are + marked as safe for running as a zipfile. This can be useful if a + package does something unsafe, but not in a way that EasyInstall + can easily detect. EasyInstall’s default analysis is currently + very conservative, however, so you should only use this option if + you’ve had problems with a particular package, and `after' + reporting the problem to the package’s maintainer and to the + EasyInstall maintainers. + + (Note: the ‘-z/-Z’ options only affect the installation of + newly-built or downloaded packages that are not already installed + in the target directory; if you want to convert an existing + installed version from zipped to unzipped or vice versa, you’ll + need to delete the existing version first, and re-run EasyInstall.) + +‘--multi-version, -m’ + + “Multi-version” mode. Specifying this option prevents + ‘easy_install’ from adding an ‘easy-install.pth’ entry for the + package being installed, and if an entry for any version the + package already exists, it will be removed upon successful + installation. In multi-version mode, no specific version of the + package is available for importing, unless you use + ‘pkg_resources.require()’ to put it on ‘sys.path’. This can be as + simple as: + + from pkg_resources import require + require("SomePackage", "OtherPackage", "MyPackage") + + which will put the latest installed version of the specified + packages on ‘sys.path’ for you. (For more advanced uses, like + selecting specific versions and enabling optional dependencies, see + the ‘pkg_resources’ API doc.) + + Changed in 0.6a10: this option is no longer silently enabled when + installing to a non-PYTHONPATH, non-“site” directory. You must + always explicitly use this option if you want it to be active. + +‘--upgrade, -U’ (New in 0.5a4) + + By default, EasyInstall only searches online if a project/version + requirement can’t be met by distributions already installed on + sys.path or the installation directory. However, if you supply the + ‘--upgrade’ or ‘-U’ flag, EasyInstall will always check the package + index and ‘--find-links’ URLs before selecting a version to + install. In this way, you can force EasyInstall to use the latest + available version of any package it installs (subject to any + version requirements that might exclude such later versions). + +‘--install-dir=DIR, -d DIR’ + + Set the installation directory. It is up to you to ensure that + this directory is on ‘sys.path’ at runtime, and to use + ‘pkg_resources.require()’ to enable the installed package(s) that + you need. + + (New in 0.4a2) If this option is not directly specified on the + command line or in a distutils configuration file, the distutils + default installation location is used. Normally, this would be the + ‘site-packages’ directory, but if you are using distutils + configuration files, setting things like ‘prefix’ or ‘install_lib’, + then those settings are taken into account when computing the + default installation directory, as is the ‘--prefix’ option. + +‘--script-dir=DIR, -s DIR’ + + Set the script installation directory. If you don’t supply this + option (via the command line or a configuration file), but you + `have' supplied an ‘--install-dir’ (via command line or config + file), then this option defaults to the same directory, so that the + scripts will be able to find their associated package installation. + Otherwise, this setting defaults to the location where the + distutils would normally install scripts, taking any distutils + configuration file settings into account. + +‘--exclude-scripts, -x’ + + Don’t install scripts. This is useful if you need to install + multiple versions of a package, but do not want to reset the + version that will be run by scripts that are already installed. + +‘--user’ (New in 0.6.11) + + Use the user-site-packages as specified in PEP 370(1) instead of + the global site-packages. + +‘--always-copy, -a’ (New in 0.5a4) + + Copy all needed distributions to the installation directory, even + if they are already present in a directory on sys.path. In older + versions of EasyInstall, this was the default behavior, but now you + must explicitly request it. By default, EasyInstall will no longer + copy such distributions from other sys.path directories to the + installation directory, unless you explicitly gave the + distribution’s filename on the command line. + + Note that as of 0.6a10, using this option excludes “system” and + “development” eggs from consideration because they can’t be + reliably copied. This may cause EasyInstall to choose an older + version of a package than what you expected, or it may cause + downloading and installation of a fresh copy of something that’s + already installed. You will see warning messages for any eggs that + EasyInstall skips, before it falls back to an older version or + attempts to download a fresh copy. + +‘--find-links=URLS_OR_FILENAMES, -f URLS_OR_FILENAMES’ + + Scan the specified “download pages” or directories for direct links + to eggs or other distributions. Any existing file or directory + names or direct download URLs are immediately added to + EasyInstall’s search cache, and any indirect URLs (ones that don’t + point to eggs or other recognized archive formats) are added to a + list of additional places to search for download links. As soon as + EasyInstall has to go online to find a package (either because it + doesn’t exist locally, or because ‘--upgrade’ or ‘-U’ was used), + the specified URLs will be downloaded and scanned for additional + direct links. + + Eggs and archives found by way of ‘--find-links’ are only + downloaded if they are needed to meet a requirement specified on + the command line; links to unneeded packages are ignored. + + If all requested packages can be found using links on the specified + download pages, the Python Package Index will not be consulted + unless you also specified the ‘--upgrade’ or ‘-U’ option. + + (Note: if you want to refer to a local HTML file containing links, + you must use a ‘file:’ URL, as filenames that do not refer to a + directory, egg, or archive are ignored.) + + You may specify multiple URLs or file/directory names with this + option, separated by whitespace. Note that on the command line, + you will probably have to surround the URL list with quotes, so + that it is recognized as a single option value. You can also + specify URLs in a configuration file; see *note Configuration + Files: f0, above. + + Changed in 0.6a10: previously all URLs and directories passed to + this option were scanned as early as possible, but from 0.6a10 on, + only directories and direct archive links are scanned immediately; + URLs are not retrieved unless a package search was already going to + go online due to a package not being available locally, or due to + the use of the ‘--update’ or ‘-U’ option. + +‘--no-find-links’ Blocks the addition of any link. + + This parameter is useful if you want to avoid adding links defined + in a project easy_install is installing (whether it’s a requested + project or a dependency). When used, ‘--find-links’ is ignored. + + Added in Distribute 0.6.11 and Setuptools 0.7. + +‘--index-url=URL, -i URL’ (New in 0.4a1; default changed in 0.6c7) + + Specifies the base URL of the Python Package Index. The default is + ‘https://pypi.org/simple/’ if not specified. When a package is + requested that is not locally available or linked from a + ‘--find-links’ download page, the package index will be searched + for download pages for the needed package, and those download pages + will be searched for links to download an egg or source + distribution. + +‘--editable, -e’ (New in 0.6a1) + + Only find and download source distributions for the specified + projects, unpacking them to subdirectories of the specified + ‘--build-directory’. EasyInstall will not actually build or + install the requested projects or their dependencies; it will just + find and extract them for you. See *note Editing and Viewing + Source Packages: ef. above for more details. + +‘--build-directory=DIR, -b DIR’ (UPDATED in 0.6a1) + + Set the directory used to build source packages. If a package is + built from a source distribution or checkout, it will be extracted + to a subdirectory of the specified directory. The subdirectory + will have the same name as the extracted distribution’s project, + but in all-lowercase. If a file or directory of that name already + exists in the given directory, a warning will be printed to the + console, and the build will take place in a temporary directory + instead. + + This option is most useful in combination with the ‘--editable’ + option, which forces EasyInstall to `only' find and extract (but + not build and install) source distributions. See *note Editing and + Viewing Source Packages: ef, above, for more information. + +‘--verbose, -v, --quiet, -q’ (New in 0.4a4) + + Control the level of detail of EasyInstall’s progress messages. + The default detail level is “info”, which prints information only + about relatively time-consuming operations like running a setup + script, unpacking an archive, or retrieving a URL. Using ‘-q’ or + ‘--quiet’ drops the detail level to “warn”, which will only display + installation reports, warnings, and errors. Using ‘-v’ or + ‘--verbose’ increases the detail level to include individual + file-level operations, link analysis messages, and distutils + messages from any setup scripts that get run. If you include the + ‘-v’ option more than once, the second and subsequent uses are + passed down to any setup scripts, increasing the verbosity of their + reporting as well. + +‘--dry-run, -n’ (New in 0.4a4) + + Don’t actually install the package or scripts. This option is + passed down to any setup scripts run, so packages should not + actually build either. This does `not' skip downloading, nor does + it skip extracting source distributions to a temporary/build + directory. + +‘--optimize=LEVEL’, ‘-O LEVEL’ (New in 0.4a4) + + If you are installing from a source distribution, and are `not' + using the ‘--zip-ok’ option, this option controls the optimization + level for compiling installed ‘.py’ files to ‘.pyo’ files. It does + not affect the compilation of modules contained in ‘.egg’ files, + only those in ‘.egg’ directories. The optimization level can be + set to 0, 1, or 2; the default is 0 (unless it’s set under + ‘install’ or ‘install_lib’ in one of your distutils configuration + files). + +‘--record=FILENAME’ (New in 0.5a4) + + Write a record of all installed files to FILENAME. This is + basically the same as the same option for the standard distutils + “install” command, and is included for compatibility with tools + that expect to pass this option to “setup.py install”. + +‘--site-dirs=DIRLIST, -S DIRLIST’ (New in 0.6a1) + + Specify one or more custom “site” directories (separated by + commas). “Site” directories are directories where ‘.pth’ files are + processed, such as the main Python ‘site-packages’ directory. As + of 0.6a10, EasyInstall automatically detects whether a given + directory processes ‘.pth’ files (or can be made to do so), so you + should not normally need to use this option. It is is now only + necessary if you want to override EasyInstall’s judgment and force + an installation directory to be treated as if it supported ‘.pth’ + files. + +‘--no-deps, -N’ (New in 0.6a6) + + Don’t install any dependencies. This is intended as a convenience + for tools that wrap eggs in a platform-specific packaging system. + (We don’t recommend that you use it for anything else.) + +‘--allow-hosts=PATTERNS, -H PATTERNS’ (New in 0.6a6) + + Restrict downloading and spidering to hosts matching the specified + glob patterns. E.g. ‘-H *.python.org’ restricts web access so + that only packages listed and downloadable from machines in the + ‘python.org’ domain. The glob patterns must match the `entire' + user/host/port section of the target URL(s). For example, + ‘*.python.org’ will NOT accept a URL like ‘http://python.org/foo’ + or ‘http://www.python.org:8080/’. Multiple patterns can be + specified by separating them with commas. The default pattern is + ‘*’, which matches anything. + + In general, this option is mainly useful for blocking EasyInstall’s + web access altogether (e.g. ‘-Hlocalhost’), or to restrict it to + an intranet or other trusted site. EasyInstall will do the best it + can to satisfy dependencies given your host restrictions, but of + course can fail if it can’t find suitable packages. EasyInstall + displays all blocked URLs, so that you can adjust your + ‘--allow-hosts’ setting if it is more strict than you intended. + Some sites may wish to define a restrictive default setting for + this option in their *note configuration files: f0, and then + manually override the setting on the command line as needed. + +‘--prefix=DIR’ (New in 0.6a10) + + Use the specified directory as a base for computing the default + installation and script directories. On Windows, the resulting + default directories will be ‘prefix\\Lib\\site-packages’ and + ‘prefix\\Scripts’, while on other platforms the defaults will be + ‘prefix/lib/python2.X/site-packages’ (with the appropriate version + substituted) for libraries and ‘prefix/bin’ for scripts. + + Note that the ‘--prefix’ option only sets the `default' + installation and script directories, and does not override the ones + set on the command line or in a configuration file. + +‘--local-snapshots-ok, -l’ (New in 0.6c6) + + Normally, EasyInstall prefers to only install `released' versions + of projects, not in-development ones, because such projects may not + have a currently-valid version number. So, it usually only + installs them when their ‘setup.py’ directory is explicitly passed + on the command line. + + However, if this option is used, then any in-development projects + that were installed using the ‘setup.py develop’ command, will be + used to build eggs, effectively upgrading the “in-development” + project to a snapshot release. Normally, this option is used only + in conjunction with the ‘--always-copy’ option to create a + distributable snapshot of every egg needed to run an application. + + Note that if you use this option, you must make sure that there is + a valid version number (such as an SVN revision number tag) for any + in-development projects that may be used, as otherwise EasyInstall + may not be able to tell what version of the project is “newer” when + future installations or upgrades are attempted. + + ---------- Footnotes ---------- + + (1) https://www.python.org/dev/peps/pep-0370 + + +File: setuptools.info, Node: Custom Installation Locations, Next: Package Index “API”, Prev: Command-Line Options, Up: Reference Manual + +8.3.2.3 Custom Installation Locations +..................................... + +By default, EasyInstall installs python packages into Python’s main +‘site-packages’ directory, and manages them using a custom ‘.pth’ file +in that same directory. + +Very often though, a user or developer wants ‘easy_install’ to install +and manage python packages in an alternative location, usually for one +of 3 reasons: + + 1. They don’t have access to write to the main Python site-packages + directory. + + 2. They want a user-specific stash of packages, that is not visible to + other users. + + 3. They want to isolate a set of packages to a specific python + application, usually to minimize the possibility of version + conflicts. + +Historically, there have been many approaches to achieve custom +installation. The following section lists only the easiest and most +relevant approaches (1). + +*note Use the "–user" option: 104. + +*note Use the "–user" option and customize "PYTHONUSERBASE": 105. + +*note Use "virtualenv": 106. + +* Menu: + +* Use the “–user” option:: +* Use the “–user” option and customize “PYTHONUSERBASE”:: +* Use “virtualenv”:: + + ---------- Footnotes ---------- + + (1) (1) There are older ways to achieve custom installation using +various ‘easy_install’ and ‘setup.py install’ options, combined with +‘PYTHONPATH’ and/or ‘PYTHONUSERBASE’ alterations, but all of these are +effectively deprecated by the User scheme brought in by PEP-370 +(http://www.python.org/dev/peps/pep-0370/). + + +File: setuptools.info, Node: Use the “–user” option, Next: Use the “–user” option and customize “PYTHONUSERBASE”, Up: Custom Installation Locations + +8.3.2.4 Use the “–user” option +.............................. + +Python provides a User scheme for installation, which means that all +python distributions support an alternative install location that is +specific to a user (1). The Default location for each OS is explained +in the python documentation for the ‘site.USER_BASE’ variable. This +mode of installation can be turned on by specifying the ‘--user’ option +to ‘setup.py install’ or ‘easy_install’. This approach serves the need +to have a user-specific stash of packages. + + ---------- Footnotes ---------- + + (1) (3) Prior to the User scheme, there was the Home scheme, which is +still available, but requires more effort than the User scheme to get +packages recognized. + + +File: setuptools.info, Node: Use the “–user” option and customize “PYTHONUSERBASE”, Next: Use “virtualenv”, Prev: Use the “–user” option, Up: Custom Installation Locations + +8.3.2.5 Use the “–user” option and customize “PYTHONUSERBASE” +............................................................. + +The User scheme install location can be customized by setting the +‘PYTHONUSERBASE’ environment variable, which updates the value of +‘site.USER_BASE’. To isolate packages to a specific application, simply +set the OS environment of that application to a specific value of +‘PYTHONUSERBASE’, that contains just those packages. + + +File: setuptools.info, Node: Use “virtualenv”, Prev: Use the “–user” option and customize “PYTHONUSERBASE”, Up: Custom Installation Locations + +8.3.2.6 Use “virtualenv” +........................ + +“virtualenv” is a 3rd-party python package that effectively “clones” a +python installation, thereby creating an isolated location to install +packages. The evolution of “virtualenv” started before the existence of +the User installation scheme. “virtualenv” provides a version of +‘easy_install’ that is scoped to the cloned python install and is used +in the normal way. “virtualenv” does offer various features that the +User installation scheme alone does not provide, e.g. the ability to +hide the main python site-packages. + +Please refer to the virtualenv(1) documentation for more details. + + ---------- Footnotes ---------- + + (1) https://pypi.org/project/virtualenv/ + + +File: setuptools.info, Node: Package Index “API”, Prev: Custom Installation Locations, Up: Reference Manual + +8.3.2.7 Package Index “API” +........................... + +Custom package indexes (and PyPI) must follow the following rules for +EasyInstall to be able to look up and download packages: + + 1. Except where stated otherwise, “pages” are HTML or XHTML, and + “links” refer to ‘href’ attributes. + + 2. Individual project version pages’ URLs must be of the form + ‘base/projectname/version’, where ‘base’ is the package index’s + base URL. + + 3. Omitting the ‘/version’ part of a project page’s URL (but keeping + the trailing ‘/’) should result in a page that is either: + + a. The single active version of that project, as though the + version had been explicitly included, OR + + b. A page with links to all of the active version pages for that + project. + + 4. Individual project version pages should contain direct links to + downloadable distributions where possible. It is explicitly + permitted for a project’s “long_description” to include URLs, and + these should be formatted as HTML links by the package index, as + EasyInstall does no special processing to identify what parts of a + page are index-specific and which are part of the project’s + supplied description. + + 5. Where available, MD5 information should be added to download URLs + by appending a fragment identifier of the form ‘#md5=...’, where + ‘...’ is the 32-character hex MD5 digest. EasyInstall will verify + that the downloaded file’s MD5 digest matches the given value. + + 6. Individual project version pages should identify any “homepage” or + “download” URLs using ‘rel="homepage"’ and ‘rel="download"’ + attributes on the HTML elements linking to those URLs. Use of + these attributes will cause EasyInstall to always follow the + provided links, unless it can be determined by inspection that they + are downloadable distributions. If the links are not to + downloadable distributions, they are retrieved, and if they are + HTML, they are scanned for download links. They are `not' scanned + for additional “homepage” or “download” links, as these are only + processed for pages that are part of a package index site. + + 7. The root URL of the index, if retrieved with a trailing ‘/’, must + result in a page containing links to `all' projects’ active version + pages. + + (Note: This requirement is a workaround for the absence of + case-insensitive ‘safe_name()’ matching of project names in URL + paths. If project names are matched in this fashion (e.g. via the + PyPI server, mod_rewrite, or a similar mechanism), then it is not + necessary to include this all-packages listing page.) + + 8. If a package index is accessed via a ‘file://’ URL, then + EasyInstall will automatically use ‘index.html’ files, if present, + when trying to read a directory with a trailing ‘/’ on the URL. + + +File: setuptools.info, Node: Porting from Distutils, Next: “Eggsecutable” Scripts, Prev: Easy Install, Up: Guides on backward compatibility & deprecated practice + +8.4 Porting from Distutils +========================== + +Setuptools and the PyPA have a stated goal(1) to make Setuptools the +reference API for distutils. + +Since the 49.1.2 release, Setuptools includes a local, vendored copy of +distutils (from late copies of CPython) that is disabled by default. To +enable the use of this copy of distutils when invoking setuptools, set +the enviroment variable: + + SETUPTOOLS_USE_DISTUTILS=local + +This behavior is planned to become the default. + +* Menu: + +* Prefer Setuptools:: + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/packaging-problems/issues/127 + + +File: setuptools.info, Node: Prefer Setuptools, Up: Porting from Distutils + +8.4.1 Prefer Setuptools +----------------------- + +As Distutils is deprecated, any usage of functions or objects from +distutils is similarly discouraged, and Setuptools aims to replace or +deprecate all such uses. This section describes the recommended +replacements. + +‘distutils.core.setup’ → ‘setuptools.setup’ + +‘distutils.cmd.Command’ → ‘setuptools.Command’ + +‘distutils.log’ → (no replacement yet) + +‘distutils.version.*’ → ‘packaging.version.*’ + +If a project relies on uses of ‘distutils’ that do not have a suitable +replacement above, please search the Setuptools issue tracker(1) and +file a request, describing the use-case so that Setuptools’ maintainers +can investigate. Please provide enough detail to help the maintainers +understand how distutils is used, what value it provides, and why that +behavior should be supported. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/ + + +File: setuptools.info, Node: “Eggsecutable” Scripts, Prev: Porting from Distutils, Up: Guides on backward compatibility & deprecated practice + +8.5 “Eggsecutable” Scripts +========================== + +Deprecated since version 45.3.0. + +Occasionally, there are situations where it’s desirable to make an +‘.egg’ file directly executable. You can do this by including an entry +point such as the following: + + setup( + # other arguments here... + entry_points={ + "setuptools.installation": [ + "eggsecutable = my_package.some_module:main_func", + ] + } + ) + +Any eggs built from the above setup script will include a short +executable prelude that imports and calls ‘main_func()’ from +‘my_package.some_module’. The prelude can be run on Unix-like platforms +(including Mac and Linux) by invoking the egg with ‘/bin/sh’, or by +enabling execute permissions on the ‘.egg’ file. For the executable +prelude to run, the appropriate version of Python must be available via +the ‘PATH’ environment variable, under its “long” name. That is, if the +egg is built for Python 2.3, there must be a ‘python2.3’ executable +present in a directory on ‘PATH’. + +IMPORTANT NOTE: Eggs with an “eggsecutable” header cannot be renamed, or +invoked via symlinks. They `must' be invoked using their original +filename, in order to ensure that, once running, ‘pkg_resources’ will +know what project and version is in use. The header script will check +this and exit with an error if the ‘.egg’ file has been renamed or is +invoked via a symlink that changes its base name. + + +File: setuptools.info, Node: History<2>, Next: Credits, Prev: Guides on backward compatibility & deprecated practice, Up: Top + +9 History +********* + +* Menu: + +* v50.3.2: v50 3 2. +* v50.3.1: v50 3 1. +* v50.3.0: v50 3 0. +* v50.2.0: v50 2 0. +* v50.1.0: v50 1 0. +* v50.0.3: v50 0 3. +* v50.0.2: v50 0 2. +* v50.0.1: v50 0 1. +* v50.0.0: v50 0 0. +* v49.6.0: v49 6 0. +* v49.5.0: v49 5 0. +* v49.4.0: v49 4 0. +* v49.3.2: v49 3 2. +* v49.3.1: v49 3 1. +* v49.3.0: v49 3 0. +* v49.2.1: v49 2 1. +* v49.2.0: v49 2 0. +* v49.1.3: v49 1 3. +* v49.1.2: v49 1 2. +* v49.1.1: v49 1 1. +* v49.0.1: v49 0 1. +* v49.1.0: v49 1 0. +* v49.0.0: v49 0 0. +* v48.0.0: v48 0 0. +* v47.3.2: v47 3 2. +* v47.3.1: v47 3 1. +* v47.3.0: v47 3 0. +* v47.2.0: v47 2 0. +* v47.1.1: v47 1 1. +* v44.1.1: v44 1 1. +* v47.1.0: v47 1 0. +* v47.0.0: v47 0 0. +* v46.4.0: v46 4 0. +* v46.3.1: v46 3 1. +* v46.3.0: v46 3 0. +* v46.2.0: v46 2 0. +* v46.1.3: v46 1 3. +* v46.1.2: v46 1 2. +* v46.1.1: v46 1 1. +* v46.1.0: v46 1 0. +* v44.1.0: v44 1 0. +* v46.0.0: v46 0 0. +* v45.3.0: v45 3 0. +* v45.2.0: v45 2 0. +* v45.1.0: v45 1 0. +* v45.0.0: v45 0 0. +* v44.0.0: v44 0 0. +* v43.0.0: v43 0 0. +* v42.0.2: v42 0 2. +* v42.0.1: v42 0 1. +* v42.0.0: v42 0 0. +* v41.6.0: v41 6 0. +* v41.5.1: v41 5 1. +* v41.5.0: v41 5 0. +* v41.4.0: v41 4 0. +* v41.3.0: v41 3 0. +* v41.2.0: v41 2 0. +* v41.1.0: v41 1 0. +* v41.0.1: v41 0 1. +* v41.0.0: v41 0 0. +* v40.9.0: v40 9 0. +* v40.8.0: v40 8 0. +* v40.7.3: v40 7 3. +* v40.7.2: v40 7 2. +* v40.7.1: v40 7 1. +* v40.7.0: v40 7 0. +* v40.6.3: v40 6 3. +* v40.6.2: v40 6 2. +* v40.6.1: v40 6 1. +* v40.6.0: v40 6 0. +* v40.5.0: v40 5 0. +* v40.4.3: v40 4 3. +* v40.4.2: v40 4 2. +* v40.4.1: v40 4 1. +* v40.4.0: v40 4 0. +* v40.3.0: v40 3 0. +* v40.2.0: v40 2 0. +* v40.1.1: v40 1 1. +* v40.1.0: v40 1 0. +* v40.0.0: v40 0 0. +* v39.2.0: v39 2 0. +* v39.1.0: v39 1 0. +* v39.0.1: v39 0 1. +* v39.0.0: v39 0 0. +* v38.7.0: v38 7 0. +* v38.6.1: v38 6 1. +* v38.6.0: v38 6 0. +* v38.5.2: v38 5 2. +* v38.5.1: v38 5 1. +* v38.5.0: v38 5 0. +* v38.4.1: v38 4 1. +* v38.4.0: v38 4 0. +* v38.3.0: v38 3 0. +* v38.2.5: v38 2 5. +* v38.2.4: v38 2 4. +* v38.2.3: v38 2 3. +* v38.2.2: v38 2 2. +* v38.2.1: v38 2 1. +* v38.2.0: v38 2 0. +* v38.1.0: v38 1 0. +* v38.0.0: v38 0 0. +* v37.0.0: v37 0 0. +* v36.8.0: v36 8 0. +* v36.7.3: v36 7 3. +* v36.7.2: v36 7 2. +* v36.7.1: v36 7 1. +* v36.7.0: v36 7 0. +* v36.6.1: v36 6 1. +* v36.6.0: v36 6 0. +* v36.5.0: v36 5 0. +* v36.4.0: v36 4 0. +* v36.3.0: v36 3 0. +* v36.2.7: v36 2 7. +* v36.2.6: v36 2 6. +* v36.2.5: v36 2 5. +* v36.2.4: v36 2 4. +* v36.2.3: v36 2 3. +* v36.2.2: v36 2 2. +* v36.2.1: v36 2 1. +* v36.2.0: v36 2 0. +* v36.1.1: v36 1 1. +* v36.1.0: v36 1 0. +* v36.0.1: v36 0 1. +* v36.0.0: v36 0 0. +* v35.0.2: v35 0 2. +* v35.0.1: v35 0 1. +* v35.0.0: v35 0 0. +* v34.4.1: v34 4 1. +* v34.4.0: v34 4 0. +* v34.3.3: v34 3 3. +* v34.3.2: v34 3 2. +* v34.3.1: v34 3 1. +* v34.3.0: v34 3 0. +* v34.2.0: v34 2 0. +* v34.1.1: v34 1 1. +* v34.1.0: v34 1 0. +* v34.0.3: v34 0 3. +* v34.0.2: v34 0 2. +* v34.0.1: v34 0 1. +* v34.0.0: v34 0 0. +* v33.1.1: v33 1 1. +* v33.1.0: v33 1 0. +* v33.0.0: v33 0 0. +* v32.3.1: v32 3 1. +* v32.3.0: v32 3 0. +* v32.2.0: v32 2 0. +* v32.1.3: v32 1 3. +* v32.1.2: v32 1 2. +* v32.1.1: v32 1 1. +* v32.1.0: v32 1 0. +* v32.0.0: v32 0 0. +* v31.0.1: v31 0 1. +* v31.0.0: v31 0 0. +* v30.4.0: v30 4 0. +* v30.3.0: v30 3 0. +* v30.2.1: v30 2 1. +* v30.2.0: v30 2 0. +* v30.1.0: v30 1 0. +* v30.0.0: v30 0 0. +* v29.0.1: v29 0 1. +* v29.0.0: v29 0 0. +* v28.8.0: v28 8 0. +* v28.7.1: v28 7 1. +* v28.7.0: v28 7 0. +* v28.6.1: v28 6 1. +* v28.6.0: v28 6 0. +* v28.5.0: v28 5 0. +* v28.4.0: v28 4 0. +* v28.3.0: v28 3 0. +* v28.1.0: v28 1 0. +* v28.0.0: v28 0 0. +* v27.3.1: v27 3 1. +* v27.3.0: v27 3 0. +* v27.2.0: v27 2 0. +* v27.1.2: v27 1 2. +* v27.1.1: v27 1 1. +* v27.1.0: v27 1 0. +* v27.0.0: v27 0 0. +* v26.1.1: v26 1 1. +* v26.1.0: v26 1 0. +* v26.0.0: v26 0 0. +* v25.4.0: v25 4 0. +* v25.3.0: v25 3 0. +* v25.2.0: v25 2 0. +* v25.1.6: v25 1 6. +* v25.1.5: v25 1 5. +* v25.1.4: v25 1 4. +* v25.1.3: v25 1 3. +* v25.1.2: v25 1 2. +* v25.1.1: v25 1 1. +* v25.1.0: v25 1 0. +* v25.0.2: v25 0 2. +* v25.0.1: v25 0 1. +* v25.0.0: v25 0 0. +* v24.3.1: v24 3 1. +* v24.3.0: v24 3 0. +* v24.2.1: v24 2 1. +* v24.2.0: v24 2 0. +* v24.1.1: v24 1 1. +* v24.1.0: v24 1 0. +* v24.0.3: v24 0 3. +* v24.0.2: v24 0 2. +* v24.0.1: v24 0 1. +* v24.0.0: v24 0 0. +* v23.2.1: v23 2 1. +* v23.1.0: v23 1 0. +* v23.0.0: v23 0 0. +* v22.0.5: v22 0 5. +* v22.0.4: v22 0 4. +* v22.0.3: v22 0 3. +* v22.0.2: v22 0 2. +* v22.0.1: v22 0 1. +* v22.0.0: v22 0 0. +* v21.2.2: v21 2 2. +* v21.2.1: v21 2 1. +* v21.2.0: v21 2 0. +* v21.1.0: v21 1 0. +* v21.0.0: v21 0 0. +* v20.10.0: v20 10 0. +* v20.9.0: v20 9 0. +* v20.8.1: v20 8 1. +* v20.8.0: v20 8 0. +* v20.7.0: v20 7 0. +* v20.6.8: v20 6 8. +* v20.6.7: v20 6 7. +* v20.6.6: v20 6 6. +* v20.6.0: v20 6 0. +* 20.5: 20 5. +* 20.4: 20 4. +* 20.3.1: 20 3 1. +* 20.3: 20 3. +* 20.2.2: 20 2 2. +* 20.2.1: 20 2 1. +* 20.2: 20 2. +* 20.1.1: 20 1 1. +* 20.1: 20 1. +* 20.0: 20 0. +* 19.7: 19 7. +* 19.6.2: 19 6 2. +* 19.6.1: 19 6 1. +* 19.6: 19 6. +* 19.5: 19 5. +* 19.4.1: 19 4 1. +* 19.4: 19 4. +* 19.3: 19 3. +* 19.2: 19 2. +* 19.1.1: 19 1 1. +* 19.1: 19 1. +* 19.0: 19 0. +* 18.8.1: 18 8 1. +* 18.8: 18 8. +* 18.7.1: 18 7 1. +* 18.7: 18 7. +* 18.6.1: 18 6 1. +* 18.6: 18 6. +* 18.5: 18 5. +* 18.4: 18 4. +* 18.3.2: 18 3 2. +* 18.3.1: 18 3 1. +* 18.3: 18 3. +* 18.2: 18 2. +* 18.1: 18 1. +* 18.0.1: 18 0 1. +* 18.0: 18 0. +* 17.1.1: 17 1 1. +* 17.1: 17 1. +* 17.0: 17 0. +* 16.0: 16 0. +* 15.2: 15 2. +* 15.1: 15 1. +* 15.0: 15 0. +* 14.3.1: 14 3 1. +* 14.3: 14 3. +* 14.2: 14 2. +* 14.1.1: 14 1 1. +* 14.1: 14 1. +* 14.0: 14 0. +* 13.0.2: 13 0 2. +* 13.0.1: 13 0 1. +* 13.0: 13 0. +* 12.4: 12 4. +* 12.3: 12 3. +* 12.2: 12 2. +* 12.1: 12 1. +* 12.0.5: 12 0 5. +* 12.0.4: 12 0 4. +* 12.0.3: 12 0 3. +* 12.0.2: 12 0 2. +* 12.0.1: 12 0 1. +* 12.0: 12 0. +* 11.3.1: 11 3 1. +* 11.3: 11 3. +* 11.2: 11 2. +* 11.1: 11 1. +* 11.0: 11 0. +* 10.2.1: 10 2 1. +* 10.2: 10 2. +* 10.1: 10 1. +* 10.0.1: 10 0 1. +* 10.0: 10 0. +* 9.1: 9 1. +* 9.0.1: 9 0 1. +* 9.0: 9 0. +* 8.4: 8 4. +* 8.3: 8 3. +* 8.2.1: 8 2 1. +* 8.2: 8 2. +* 8.1: 8 1. +* 8.0.4: 8 0 4. +* 8.0.3: 8 0 3. +* 8.0.2: 8 0 2. +* 8.0.1: 8 0 1. +* 8.0: 8 0. +* 7.0: 7 0. +* 6.1: 6 1. +* 6.0.2: 6 0 2. +* 6.0.1: 6 0 1. +* 6.0: 6 0. +* 5.8: 5 8. +* 5.7: 5 7. +* 5.6: 5 6. +* 5.5.1: 5 5 1. +* 5.5: 5 5. +* 5.4.2: 5 4 2. +* 5.4.1: 5 4 1. +* 5.4: 5 4. +* 5.3: 5 3. +* 5.2: 5 2. +* 5.1: 5 1. +* 5.0.2: 5 0 2. +* 5.0.1: 5 0 1. +* 5.0: 5 0. +* 3.7.1 and 3.8.1 and 4.0.1: 3 7 1 and 3 8 1 and 4 0 1. +* 4.0: 4 0. +* 3.8: 3 8. +* 3.7: 3 7. +* 3.6: 3 6. +* 3.5.2: 3 5 2. +* 3.5.1: 3 5 1. +* 3.5: 3 5. +* 3.4.4: 3 4 4. +* 3.4.3: 3 4 3. +* 3.4.2: 3 4 2. +* 3.4.1: 3 4 1. +* 3.4: 3 4. +* 3.3: 3 3. +* 3.2: 3 2. +* 3.1: 3 1. +* 3.0.2: 3 0 2. +* 3.0.1: 3 0 1. +* 3.0: 3 0. +* 2.2: 2 2. +* 2.1.2: 2 1 2. +* 2.1.1: 2 1 1. +* 2.1: 2 1. +* 2.0.2: 2 0 2. +* 2.0.1: 2 0 1. +* 2.0: 2 0. +* 1.4.2: 1 4 2. +* 1.4.1: 1 4 1. +* 1.4: 1 4. +* 1.3.2: 1 3 2. +* 1.3.1: 1 3 1. +* 1.3: 1 3. +* 1.2: 1 2. +* 1.1.7: 1 1 7. +* 1.1.6: 1 1 6. +* 1.1.5: 1 1 5. +* 1.1.4: 1 1 4. +* 1.1.3: 1 1 3. +* 1.1.2: 1 1 2. +* 1.1.1: 1 1 1. +* 1.1: 1 1. +* 1.0: 1 0. +* 0.9.8: 0 9 8. +* 0.9.7: 0 9 7. +* 0.9.6: 0 9 6. +* 0.9.5: 0 9 5. +* 0.9.4: 0 9 4. +* 0.9.3: 0 9 3. +* 0.9.2: 0 9 2. +* 0.9.1: 0 9 1. +* 0.9: 0 9. +* 0.8: 0 8. +* 0.7.8: 0 7 8. +* 0.7.7: 0 7 7. +* 0.7.6: 0 7 6. +* 0.7.5: 0 7 5. +* 0.7.4: 0 7 4. +* 0.7.3: 0 7 3. +* 0.7.2: 0 7 2. +* 0.7.1: 0 7 1. +* 0.7: 0 7. +* 0.7b4: 0 7b4. +* 0.6.49: 0 6 49. +* 0.6.48: 0 6 48. +* 0.6.47: 0 6 47. +* 0.6.46: 0 6 46. +* 0.6.45: 0 6 45. +* 0.6.44: 0 6 44. +* 0.6.43: 0 6 43. +* 0.6.42: 0 6 42. +* 0.6.41: 0 6 41. +* 0.6.40: 0 6 40. +* 0.6.39: 0 6 39. +* 0.6.38: 0 6 38. +* 0.6.37: 0 6 37. +* 0.6.36: 0 6 36. +* 0.6.35: 0 6 35. +* 0.6.34: 0 6 34. +* 0.6.33: 0 6 33. +* 0.6.32: 0 6 32. +* 0.6.31: 0 6 31. +* 0.6.30: 0 6 30. +* 0.6.29: 0 6 29. +* 0.6.28: 0 6 28. +* 0.6.27: 0 6 27. +* 0.6.26: 0 6 26. +* 0.6.25: 0 6 25. +* 0.6.24: 0 6 24. +* 0.6.23: 0 6 23. +* 0.6.21: 0 6 21. +* 0.6.20: 0 6 20. +* 0.6.19: 0 6 19. +* 0.6.18: 0 6 18. +* 0.6.17: 0 6 17. +* 0.6.16: 0 6 16. +* 0.6.15: 0 6 15. +* 0.6.14: 0 6 14. +* 0.6.13: 0 6 13. +* 0.6.12: 0 6 12. +* 0.6.11: 0 6 11. +* 0.6.10: 0 6 10. +* 0.6.9: 0 6 9. +* 0.6.8: 0 6 8. +* 0.6.7: 0 6 7. +* 0.6.6: 0 6 6. +* 0.6.5: 0 6 5. +* 0.6.4: 0 6 4. +* 0.6.3: 0 6 3. +* 0.6.2: 0 6 2. +* 0.6.1: 0 6 1. +* 0.6: 0 6. +* 0.6c9: 0 6c9. +* 0.6c7: 0 6c7. +* 0.6c6: 0 6c6. +* 0.6c5: 0 6c5. +* 0.6c4: 0 6c4. +* 0.6c3: 0 6c3. +* 0.6c2: 0 6c2. +* 0.6c1: 0 6c1. +* 0.6b4: 0 6b4. +* 0.6b3: 0 6b3. +* 0.6b2: 0 6b2. +* 0.6b1: 0 6b1. +* 0.6a11: 0 6a11. +* 0.6a10: 0 6a10. +* 0.6a9: 0 6a9. +* 0.6a8: 0 6a8. +* 0.6a7: 0 6a7. +* 0.6a6: 0 6a6. +* 0.6a5: 0 6a5. +* 0.6a3: 0 6a3. +* 0.6a2: 0 6a2. +* 0.6a1: 0 6a1. +* 0.5a12: 0 5a12. +* 0.5a11: 0 5a11. +* 0.5a10: 0 5a10. +* 0.5a9: 0 5a9. +* 0.5a8: 0 5a8. +* 0.5a7: 0 5a7. +* 0.5a6: 0 5a6. +* 0.5a5: 0 5a5. +* 0.5a4: 0 5a4. +* 0.5a3: 0 5a3. +* 0.5a2: 0 5a2. +* 0.5a1: 0 5a1. +* 0.4a4: 0 4a4. +* 0.4a3: 0 4a3. +* 0.4a2: 0 4a2. +* 0.4a1: 0 4a1. +* 0.3a4: 0 3a4. +* 0.3a3: 0 3a3. +* 0.3a2: 0 3a2. +* 0.3a1: 0 3a1. + + +File: setuptools.info, Node: v50 3 2, Next: v50 3 1, Up: History<2> + +9.1 v50.3.2 +=========== + +17 Oct 2020 + +* Menu: + +* Documentation changes:: +* Misc:: + + +File: setuptools.info, Node: Documentation changes, Next: Misc, Up: v50 3 2 + +9.1.1 Documentation changes +--------------------------- + + * #2394(1): Extended towncrier news template to include change note + categories. This allows to see what types of changes a given + version introduces – by @webknjaz(2) + + * #2427(3): Started enforcing strict syntax and reference validation + in the Sphinx docs – by @webknjaz(4) + + * #2428(5): Removed redundant Sphinx ‘Makefile’ support – by + @webknjaz(6) + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2394 + + (2) https://github.com/sponsors/webknjaz + + (3) https://github.com/pypa/setuptools/issues/2427 + + (4) https://github.com/sponsors/webknjaz + + (5) https://github.com/pypa/setuptools/issues/2428 + + (6) https://github.com/sponsors/webknjaz + + +File: setuptools.info, Node: Misc, Prev: Documentation changes, Up: v50 3 2 + +9.1.2 Misc +---------- + + * #2401(1): Enabled test results reporting in AppVeyor CI – by + @webknjaz(2) + + * #2420(3): Replace Python 3.9.0 beta with 3.9.0 final on GitHub + Actions. + + * #2421(4): Python 3.9 Trove classifier got added to the dist + metadata – by @webknjaz(5) + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2401 + + (2) https://github.com/sponsors/webknjaz + + (3) https://github.com/pypa/setuptools/issues/2420 + + (4) https://github.com/pypa/setuptools/issues/2421 + + (5) https://github.com/sponsors/webknjaz + + +File: setuptools.info, Node: v50 3 1, Next: v50 3 0, Prev: v50 3 2, Up: History<2> + +9.2 v50.3.1 +=========== + +14 Oct 2020 + +* Menu: + +* Documentation changes: Documentation changes<2>. +* Misc: Misc<2>. + + +File: setuptools.info, Node: Documentation changes<2>, Next: Misc<2>, Up: v50 3 1 + +9.2.1 Documentation changes +--------------------------- + + * #2093(1): Finalized doc revamp. + + * #2097(2): doc: simplify index and group deprecated files + + * #2102(3): doc overhaul step 2: break main doc into multiple + sections + + * #2111(4): doc overhaul step 3: update userguide + + * #2395(5): Added a ‘:user:’ role to Sphinx config – by @webknjaz(6) + + * #2395(7): Added an illustrative explanation about the change notes + to fragments dir – by @webknjaz(8) + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2093 + + (2) https://github.com/pypa/setuptools/issues/2097 + + (3) https://github.com/pypa/setuptools/issues/2102 + + (4) https://github.com/pypa/setuptools/issues/2111 + + (5) https://github.com/pypa/setuptools/issues/2395 + + (6) https://github.com/sponsors/webknjaz + + (7) https://github.com/pypa/setuptools/issues/2395 + + (8) https://github.com/sponsors/webknjaz + + +File: setuptools.info, Node: Misc<2>, Prev: Documentation changes<2>, Up: v50 3 1 + +9.2.2 Misc +---------- + + * #2379(1): Travis CI test suite now tests against PPC64. + + * #2413(2): Suppress EOF errors (and other exceptions) when importing + lib2to3. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2379 + + (2) https://github.com/pypa/setuptools/issues/2413 + + +File: setuptools.info, Node: v50 3 0, Next: v50 2 0, Prev: v50 3 1, Up: History<2> + +9.3 v50.3.0 +=========== + +05 Sep 2020 + +* Menu: + +* Changes:: + + +File: setuptools.info, Node: Changes, Up: v50 3 0 + +9.3.1 Changes +------------- + + * #2368(1): In distutils, restore support for monkeypatched + CCompiler.spawn per pypa/distutils#15(2). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2368 + + (2) https://github.com/pypa/distutils/issues/15 + + +File: setuptools.info, Node: v50 2 0, Next: v50 1 0, Prev: v50 3 0, Up: History<2> + +9.4 v50.2.0 +=========== + +04 Sep 2020 + +* Menu: + +* Changes: Changes<2>. + + +File: setuptools.info, Node: Changes<2>, Up: v50 2 0 + +9.4.1 Changes +------------- + + * #2355(1): When pip is imported as part of a build, leave distutils + patched. + + * #2380(2): There are some setuptools specific changes in the + ‘setuptools.command.bdist_rpm’ module that are no longer needed, + because they are part of the ‘bdist_rpm’ module in distutils in + Python 3.5.0. Therefore, code was removed from + ‘setuptools.command.bdist_rpm’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2355 + + (2) https://github.com/pypa/setuptools/issues/2380 + + +File: setuptools.info, Node: v50 1 0, Next: v50 0 3, Prev: v50 2 0, Up: History<2> + +9.5 v50.1.0 +=========== + +02 Sep 2020 + +* Menu: + +* Changes: Changes<3>. + + +File: setuptools.info, Node: Changes<3>, Up: v50 1 0 + +9.5.1 Changes +------------- + + * #2350(1): Setuptools reverts using the included distutils by + default. Platform maintainers and system integrators and others + are `strongly' encouraged to set ‘SETUPTOOLS_USE_DISTUTILS=local’ + to help identify and work through the reported issues with + distutils adoption, mainly to file issues and pull requests with + pypa/distutils such that distutils performs as needed across every + supported environment. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2350 + + +File: setuptools.info, Node: v50 0 3, Next: v50 0 2, Prev: v50 1 0, Up: History<2> + +9.6 v50.0.3 +=========== + +01 Sep 2020 + +* Menu: + +* Misc: Misc<3>. + + +File: setuptools.info, Node: Misc<3>, Up: v50 0 3 + +9.6.1 Misc +---------- + + * #2363(1): Restore link_libpython support on Python 3.7 and earlier + (see pypa/distutils#9(2)). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2363 + + (2) https://github.com/pypa/distutils/issues/9 + + +File: setuptools.info, Node: v50 0 2, Next: v50 0 1, Prev: v50 0 3, Up: History<2> + +9.7 v50.0.2 +=========== + +01 Sep 2020 + +* Menu: + +* Misc: Misc<4>. + + +File: setuptools.info, Node: Misc<4>, Up: v50 0 2 + +9.7.1 Misc +---------- + + * #2352(1): In distutils hack, use absolute import rather than + relative to avoid bpo-30876(2). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2352 + + (2) http://bugs.python.org/issue30876 + + +File: setuptools.info, Node: v50 0 1, Next: v50 0 0, Prev: v50 0 2, Up: History<2> + +9.8 v50.0.1 +=========== + +01 Sep 2020 + +* Menu: + +* Misc: Misc<5>. + + +File: setuptools.info, Node: Misc<5>, Up: v50 0 1 + +9.8.1 Misc +---------- + + * #2357(1): Restored Python 3.5 support in distutils.util for missing + ‘subprocess._optim_args_from_interpreter_flags’. + + * #2358(2): Restored AIX support on Python 3.8 and earlier. + + * #2361(3): Add Python 3.10 support to _distutils_hack. Get the + ‘Loader’ abstract class from importlib.abc rather than + importlib.util.abc (alias removed in Python 3.10). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2357 + + (2) https://github.com/pypa/setuptools/issues/2358 + + (3) https://github.com/pypa/setuptools/issues/2361 + + +File: setuptools.info, Node: v50 0 0, Next: v49 6 0, Prev: v50 0 1, Up: History<2> + +9.9 v50.0.0 +=========== + +20 Aug 2020 + +* Menu: + +* Breaking Changes:: +* Changes: Changes<4>. + + +File: setuptools.info, Node: Breaking Changes, Next: Changes<4>, Up: v50 0 0 + +9.9.1 Breaking Changes +---------------------- + + * #2232(1): Once again, Setuptools overrides the stdlib distutils on + import. For environments or invocations where this behavior is + undesirable, users are provided with a temporary escape hatch. If + the environment variable ‘SETUPTOOLS_USE_DISTUTILS’ is set to + ‘stdlib’, Setuptools will fall back to the legacy behavior. Use of + this escape hatch is discouraged, but it is provided to ease the + transition while proper fixes for edge cases can be addressed. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2232 + + +File: setuptools.info, Node: Changes<4>, Prev: Breaking Changes, Up: v50 0 0 + +9.9.2 Changes +------------- + + * #2334(1): In MSVC module, refine text in error message. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2334 + + +File: setuptools.info, Node: v49 6 0, Next: v49 5 0, Prev: v50 0 0, Up: History<2> + +9.10 v49.6.0 +============ + +13 Aug 2020 + +* Menu: + +* Changes: Changes<5>. + + +File: setuptools.info, Node: Changes<5>, Up: v49 6 0 + +9.10.1 Changes +-------------- + + * #2129(1): In pkg_resources, no longer detect any pathname ending in + .egg as a Python egg. Now the path must be an unpacked egg or a + zip file. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2129 + + +File: setuptools.info, Node: v49 5 0, Next: v49 4 0, Prev: v49 6 0, Up: History<2> + +9.11 v49.5.0 +============ + +13 Aug 2020 + +* Menu: + +* Changes: Changes<6>. + + +File: setuptools.info, Node: Changes<6>, Up: v49 5 0 + +9.11.1 Changes +-------------- + + * #2306(1): When running as a PEP 517(2) backend, setuptools does not + try to install ‘setup_requires’ itself. They are reported as build + requirements for the frontend to install. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2306 + + (2) https://www.python.org/dev/peps/pep-0517/ + + +File: setuptools.info, Node: v49 4 0, Next: v49 3 2, Prev: v49 5 0, Up: History<2> + +9.12 v49.4.0 +============ + +13 Aug 2020 + +* Menu: + +* Changes: Changes<7>. + + +File: setuptools.info, Node: Changes<7>, Up: v49 4 0 + +9.12.1 Changes +-------------- + + * #2310(1): Updated vendored packaging version to 20.4. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2310 + + +File: setuptools.info, Node: v49 3 2, Next: v49 3 1, Prev: v49 4 0, Up: History<2> + +9.13 v49.3.2 +============ + +12 Aug 2020 + +* Menu: + +* Documentation changes: Documentation changes<3>. +* Misc: Misc<6>. + + +File: setuptools.info, Node: Documentation changes<3>, Next: Misc<6>, Up: v49 3 2 + +9.13.1 Documentation changes +---------------------------- + + * #2300(1): Improve the ‘safe_version’ function documentation + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2300 + + +File: setuptools.info, Node: Misc<6>, Prev: Documentation changes<3>, Up: v49 3 2 + +9.13.2 Misc +----------- + + * #2297(1): Once again, in stubs prefer exec_module to the deprecated + load_module. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2297 + + +File: setuptools.info, Node: v49 3 1, Next: v49 3 0, Prev: v49 3 2, Up: History<2> + +9.14 v49.3.1 +============ + +10 Aug 2020 + +* Menu: + +* Changes: Changes<8>. + + +File: setuptools.info, Node: Changes<8>, Up: v49 3 1 + +9.14.1 Changes +-------------- + + * #2316(1): Removed warning when ‘distutils’ is imported before + ‘setuptools’ when ‘distutils’ replacement is not enabled. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2316 + + +File: setuptools.info, Node: v49 3 0, Next: v49 2 1, Prev: v49 3 1, Up: History<2> + +9.15 v49.3.0 +============ + +09 Aug 2020 + +* Menu: + +* Changes: Changes<9>. + + +File: setuptools.info, Node: Changes<9>, Up: v49 3 0 + +9.15.1 Changes +-------------- + + * #2259(1): Setuptools now provides a .pth file (except for editable + installs of setuptools) to the target environment to ensure that + when enabled, the setuptools-provided distutils is preferred before + setuptools has been imported (and even if setuptools is never + imported). Honors the SETUPTOOLS_USE_DISTUTILS environment + variable. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2259 + + +File: setuptools.info, Node: v49 2 1, Next: v49 2 0, Prev: v49 3 0, Up: History<2> + +9.16 v49.2.1 +============ + +02 Aug 2020 + +* Menu: + +* Misc: Misc<7>. + + +File: setuptools.info, Node: Misc<7>, Up: v49 2 1 + +9.16.1 Misc +----------- + + * #2257(1): Fixed two flaws in + distutils._msvccompiler.MSVCCompiler.spawn. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2257 + + +File: setuptools.info, Node: v49 2 0, Next: v49 1 3, Prev: v49 2 1, Up: History<2> + +9.17 v49.2.0 +============ + +12 Jul 2020 + +* Menu: + +* Changes: Changes<10>. + + +File: setuptools.info, Node: Changes<10>, Up: v49 2 0 + +9.17.1 Changes +-------------- + + * #2230(1): Now warn the user when setuptools is imported after + distutils modules have been loaded (exempting PyPy for 3.6), + directing the users of packages to import setuptools first. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2230 + + +File: setuptools.info, Node: v49 1 3, Next: v49 1 2, Prev: v49 2 0, Up: History<2> + +9.18 v49.1.3 +============ + +12 Jul 2020 + +* Menu: + +* Misc: Misc<8>. + + +File: setuptools.info, Node: Misc<8>, Up: v49 1 3 + +9.18.1 Misc +----------- + + * #2212(1): (Distutils) Allow spawn to accept environment. Avoid + monkey-patching global state. + + * #2249(2): Fix extension loading technique in stubs. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2212 + + (2) https://github.com/pypa/setuptools/issues/2249 + + +File: setuptools.info, Node: v49 1 2, Next: v49 1 1, Prev: v49 1 3, Up: History<2> + +9.19 v49.1.2 +============ + +11 Jul 2020 + +* Menu: + +* Changes: Changes<11>. + + +File: setuptools.info, Node: Changes<11>, Up: v49 1 2 + +9.19.1 Changes +-------------- + + * #2232(1): In preparation for re-enabling a local copy of distutils, + Setuptools now honors an environment variable, + SETUPTOOLS_USE_DISTUTILS. If set to ‘stdlib’ (current default), + distutils will be used from the standard library. If set to + ‘local’ (default in a imminent backward-incompatible release), the + local copy of distutils will be used. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2232 + + +File: setuptools.info, Node: v49 1 1, Next: v49 0 1, Prev: v49 1 2, Up: History<2> + +9.20 v49.1.1 +============ + +10 Jul 2020 + +* Menu: + +* Misc: Misc<9>. + + +File: setuptools.info, Node: Misc<9>, Up: v49 1 1 + +9.20.1 Misc +----------- + + * #2094(1): Removed pkg_resources.py2_warn module, which is no longer + reachable. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2094 + + +File: setuptools.info, Node: v49 0 1, Next: v49 1 0, Prev: v49 1 1, Up: History<2> + +9.21 v49.0.1 +============ + +05 Jul 2020 + +* Menu: + +* Misc: Misc<10>. + + +File: setuptools.info, Node: Misc<10>, Up: v49 0 1 + +9.21.1 Misc +----------- + + * #2228(1): Applied fix for pypa/distutils#3(2), restoring + expectation that spawn will raise a DistutilsExecError when + attempting to execute a missing file. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2228 + + (2) https://github.com/pypa/distutils/issues/3 + + +File: setuptools.info, Node: v49 1 0, Next: v49 0 0, Prev: v49 0 1, Up: History<2> + +9.22 v49.1.0 +============ + +03 Jul 2020 + +* Menu: + +* Changes: Changes<12>. + + +File: setuptools.info, Node: Changes<12>, Up: v49 1 0 + +9.22.1 Changes +-------------- + + * #2228(1): Disabled distutils adoption for now while emergent issues + are addressed. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2228 + + +File: setuptools.info, Node: v49 0 0, Next: v48 0 0, Prev: v49 1 0, Up: History<2> + +9.23 v49.0.0 +============ + +03 Jul 2020 + +* Menu: + +* Breaking Changes: Breaking Changes<2>. +* Changes: Changes<13>. +* Misc: Misc<11>. + + +File: setuptools.info, Node: Breaking Changes<2>, Next: Changes<13>, Up: v49 0 0 + +9.23.1 Breaking Changes +----------------------- + + * #2165(1): Setuptools no longer installs a site.py file during + easy_install or develop installs. As a result, .eggs on PYTHONPATH + will no longer take precedence over other packages on sys.path. If + this issue affects your production environment, please reach out to + the maintainers at #2165(2). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2165 + + (2) https://github.com/pypa/setuptools/issues/2165 + + +File: setuptools.info, Node: Changes<13>, Next: Misc<11>, Prev: Breaking Changes<2>, Up: v49 0 0 + +9.23.2 Changes +-------------- + + * #2137(1): Removed (private) pkg_resources.RequirementParseError, + now replaced by packaging.requirements.InvalidRequirement. Kept + the name for compatibility, but users should catch + InvalidRequirement instead. + + * #2180(2): Update vendored packaging in pkg_resources to 19.2. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2137 + + (2) https://github.com/pypa/setuptools/issues/2180 + + +File: setuptools.info, Node: Misc<11>, Prev: Changes<13>, Up: v49 0 0 + +9.23.3 Misc +----------- + + * #2199(1): Fix exception causes all over the codebase by using + ‘raise new_exception from old_exception’ + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2199 + + +File: setuptools.info, Node: v48 0 0, Next: v47 3 2, Prev: v49 0 0, Up: History<2> + +9.24 v48.0.0 +============ + +03 Jul 2020 + +* Menu: + +* Breaking Changes: Breaking Changes<3>. + + +File: setuptools.info, Node: Breaking Changes<3>, Up: v48 0 0 + +9.24.1 Breaking Changes +----------------------- + + * #2143(1): Setuptools adopts distutils from the Python 3.9 standard + library and no longer depends on distutils in the standard library. + When importing ‘setuptools’ or ‘setuptools.distutils_patch’, + Setuptools will expose its bundled version as a top-level + ‘distutils’ package (and unload any previously-imported top-level + distutils package), retaining the expectation that ‘distutils’’ + objects are actually Setuptools objects. To avoid getting any + legacy behavior from the standard library, projects are advised to + always “import setuptools” prior to importing anything from + distutils. This behavior happens by default when using ‘pip + install’ or ‘pep517.build’. Workflows that rely on ‘setup.py + (anything)’ will need to first ensure setuptools is imported. One + way to achieve this behavior without modifying code is to invoke + Python thus: ‘python -c "import setuptools; + exec(open('setup.py').read())" (anything)’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2143 + + +File: setuptools.info, Node: v47 3 2, Next: v47 3 1, Prev: v48 0 0, Up: History<2> + +9.25 v47.3.2 +============ + +03 Jul 2020 + +* Menu: + +* Misc: Misc<12>. + + +File: setuptools.info, Node: Misc<12>, Up: v47 3 2 + +9.25.1 Misc +----------- + + * #2071(1): Replaced references to the deprecated imp package with + references to importlib + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2071 + + +File: setuptools.info, Node: v47 3 1, Next: v47 3 0, Prev: v47 3 2, Up: History<2> + +9.26 v47.3.1 +============ + +16 Jun 2020 + +* Menu: + +* Misc: Misc<13>. + + +File: setuptools.info, Node: Misc<13>, Up: v47 3 1 + +9.26.1 Misc +----------- + + * #1973(1): Removed ‘pkg_resources.py31compat.makedirs’ in favor of + the stdlib. Use ‘os.makedirs()’ instead. + + * #2198(2): Restore ‘__requires__’ directive in easy-install wrapper + scripts. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1973 + + (2) https://github.com/pypa/setuptools/issues/2198 + + +File: setuptools.info, Node: v47 3 0, Next: v47 2 0, Prev: v47 3 1, Up: History<2> + +9.27 v47.3.0 +============ + +15 Jun 2020 + +* Menu: + +* Changes: Changes<14>. +* Misc: Misc<14>. + + +File: setuptools.info, Node: Changes<14>, Next: Misc<14>, Up: v47 3 0 + +9.27.1 Changes +-------------- + + * #2197(1): Console script wrapper for editable installs now has a + unified template and honors importlib_metadata if present for + faster script execution on older Pythons. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2197 + + +File: setuptools.info, Node: Misc<14>, Prev: Changes<14>, Up: v47 3 0 + +9.27.2 Misc +----------- + + * #2195(1): Fix broken entry points generated by easy-install (pip + editable installs). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2195 + + +File: setuptools.info, Node: v47 2 0, Next: v47 1 1, Prev: v47 3 0, Up: History<2> + +9.28 v47.2.0 +============ + +15 Jun 2020 + +* Menu: + +* Changes: Changes<15>. + + +File: setuptools.info, Node: Changes<15>, Up: v47 2 0 + +9.28.1 Changes +-------------- + + * #2194(1): Editable-installed entry points now load significantly + faster on Python versions 3.8+. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2194 + + +File: setuptools.info, Node: v47 1 1, Next: v44 1 1, Prev: v47 2 0, Up: History<2> + +9.29 v47.1.1 +============ + +28 May 2020 + +* Menu: + +* Documentation changes: Documentation changes<4>. +* Incorporate changes from v44.1.1;: Incorporate changes from v44 1 1. + + +File: setuptools.info, Node: Documentation changes<4>, Next: Incorporate changes from v44 1 1, Up: v47 1 1 + +9.29.1 Documentation changes +---------------------------- + + * #2156(1): Update mailing list pointer in developer docs + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2156 + + +File: setuptools.info, Node: Incorporate changes from v44 1 1, Prev: Documentation changes<4>, Up: v47 1 1 + +9.29.2 Incorporate changes from v44.1.1: +---------------------------------------- + + * #2158(1): Avoid loading working set during + ‘Distribution.finalize_options’ prior to invoking + ‘_install_setup_requires’, broken since v42.0.0. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2158 + + +File: setuptools.info, Node: v44 1 1, Next: v47 1 0, Prev: v47 1 1, Up: History<2> + +9.30 v44.1.1 +============ + +28 May 2020 + +* Menu: + +* Misc: Misc<15>. + + +File: setuptools.info, Node: Misc<15>, Up: v44 1 1 + +9.30.1 Misc +----------- + + * #2158(1): Avoid loading working set during + ‘Distribution.finalize_options’ prior to invoking + ‘_install_setup_requires’, broken since v42.0.0. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2158 + + +File: setuptools.info, Node: v47 1 0, Next: v47 0 0, Prev: v44 1 1, Up: History<2> + +9.31 v47.1.0 +============ + +28 May 2020 + +* Menu: + +* Changes: Changes<16>. + + +File: setuptools.info, Node: Changes<16>, Up: v47 1 0 + +9.31.1 Changes +-------------- + + * #2070(1): In wheel-to-egg conversion, use simple + pkg_resources-style namespace declaration for packages that declare + namespace_packages. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2070 + + +File: setuptools.info, Node: v47 0 0, Next: v46 4 0, Prev: v47 1 0, Up: History<2> + +9.32 v47.0.0 +============ + +28 May 2020 + +* Menu: + +* Breaking Changes: Breaking Changes<4>. +* Changes: Changes<17>. + + +File: setuptools.info, Node: Breaking Changes<4>, Next: Changes<17>, Up: v47 0 0 + +9.32.1 Breaking Changes +----------------------- + + * #2094(1): Setuptools now actively crashes under Python 2. Python + 3.5 or later is required. Users of Python 2 should use + ‘setuptools<45’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2094 + + +File: setuptools.info, Node: Changes<17>, Prev: Breaking Changes<4>, Up: v47 0 0 + +9.32.2 Changes +-------------- + + * #1700(1): Document all supported keywords by migrating the ones + from distutils. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1700 + + +File: setuptools.info, Node: v46 4 0, Next: v46 3 1, Prev: v47 0 0, Up: History<2> + +9.33 v46.4.0 +============ + +16 May 2020 + +* Menu: + +* Changes: Changes<18>. + + +File: setuptools.info, Node: Changes<18>, Up: v46 4 0 + +9.33.1 Changes +-------------- + + * #1753(1): ‘attr:’ now extracts variables through rudimentary + examination of the AST, thereby supporting modules with third-party + imports. If examining the AST fails to find the variable, ‘attr:’ + falls back to the old behavior of importing the module. Works on + Python 3 only. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1753 + + +File: setuptools.info, Node: v46 3 1, Next: v46 3 0, Prev: v46 4 0, Up: History<2> + +9.34 v46.3.1 +============ + +15 May 2020 + +No significant changes. + + +File: setuptools.info, Node: v46 3 0, Next: v46 2 0, Prev: v46 3 1, Up: History<2> + +9.35 v46.3.0 +============ + +13 May 2020 + +* Menu: + +* Changes: Changes<19>. +* Misc: Misc<16>. + + +File: setuptools.info, Node: Changes<19>, Next: Misc<16>, Up: v46 3 0 + +9.35.1 Changes +-------------- + + * #2089(1): Package index functionality no longer attempts to remove + an md5 fragment from the index URL. This functionality, added for + distribute #163(2) is no longer relevant. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2089 + + (2) https://github.com/pypa/setuptools/issues/163 + + +File: setuptools.info, Node: Misc<16>, Prev: Changes<19>, Up: v46 3 0 + +9.35.2 Misc +----------- + + * #2041(1): Preserve file modes during pkg files copying, but clear + read only flag for target afterwards. + + * #2105(2): Filter ‘2to3’ deprecation warnings from + ‘TestDevelop.test_2to3_user_mode’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2041 + + (2) https://github.com/pypa/setuptools/issues/2105 + + +File: setuptools.info, Node: v46 2 0, Next: v46 1 3, Prev: v46 3 0, Up: History<2> + +9.36 v46.2.0 +============ + +10 May 2020 + +* Menu: + +* Changes: Changes<20>. +* Documentation changes: Documentation changes<5>. +* Misc: Misc<17>. + + +File: setuptools.info, Node: Changes<20>, Next: Documentation changes<5>, Up: v46 2 0 + +9.36.1 Changes +-------------- + + * #2040(1): Deprecated the ‘bdist_wininst’ command. Binary packages + should be built as wheels instead. + + * #2062(2): Change ‘Mac OS X’ to ‘macOS’ in code. + + * #2075(3): Stop recognizing files ending with ‘.dist-info’ as + distribution metadata. + + * #2086(4): Deprecate ‘use_2to3’ functionality. Packagers are + encouraged to use single-source solutions or build tool chains to + manage conversions outside of setuptools. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2040 + + (2) https://github.com/pypa/setuptools/issues/2062 + + (3) https://github.com/pypa/setuptools/issues/2075 + + (4) https://github.com/pypa/setuptools/issues/2086 + + +File: setuptools.info, Node: Documentation changes<5>, Next: Misc<17>, Prev: Changes<20>, Up: v46 2 0 + +9.36.2 Documentation changes +---------------------------- + + * #1698(1): Added documentation for ‘build_meta’ (a bare minimum, not + completed). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1698 + + +File: setuptools.info, Node: Misc<17>, Prev: Documentation changes<5>, Up: v46 2 0 + +9.36.3 Misc +----------- + + * #2082(1): Filter ‘lib2to3’ ‘PendingDeprecationWarning’ and + ‘DeprecationWarning’ in tests, because ‘lib2to3’ is deprecated in + Python 3.9(2). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2082 + + (2) https://bugs.python.org/issue40360 + + +File: setuptools.info, Node: v46 1 3, Next: v46 1 2, Prev: v46 2 0, Up: History<2> + +9.37 v46.1.3 +============ + +25 Mar 2020 + +No significant changes. + + +File: setuptools.info, Node: v46 1 2, Next: v46 1 1, Prev: v46 1 3, Up: History<2> + +9.38 v46.1.2 +============ + +25 Mar 2020 + +* Menu: + +* Misc: Misc<18>. + + +File: setuptools.info, Node: Misc<18>, Up: v46 1 2 + +9.38.1 Misc +----------- + + * #1458(1): Added template for reporting Python 2 incompatibilities. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1458 + + +File: setuptools.info, Node: v46 1 1, Next: v46 1 0, Prev: v46 1 2, Up: History<2> + +9.39 v46.1.1 +============ + +21 Mar 2020 + +No significant changes. + + +File: setuptools.info, Node: v46 1 0, Next: v44 1 0, Prev: v46 1 1, Up: History<2> + +9.40 v46.1.0 +============ + +21 Mar 2020 + +* Menu: + +* Changes: Changes<21>. +* Incorporate changes from v44.1.0;: Incorporate changes from v44 1 0. + + +File: setuptools.info, Node: Changes<21>, Next: Incorporate changes from v44 1 0, Up: v46 1 0 + +9.40.1 Changes +-------------- + + * #308(1): Allow version number normalization to be bypassed by + wrapping in a ‘setuptools.sic()’ call. + + * #1424(2): Prevent keeping files mode for package_data build. It + may break a build if user’s package data has read only flag. + + * #1431(3): In ‘easy_install.check_site_dir’, ensure the installation + directory exists. + + * #1563(4): In ‘pkg_resources’ prefer ‘find_spec’ (PEP 451(5)) to + ‘find_module’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/308 + + (2) https://github.com/pypa/setuptools/issues/1424 + + (3) https://github.com/pypa/setuptools/issues/1431 + + (4) https://github.com/pypa/setuptools/issues/1563 + + (5) https://www.python.org/dev/peps/pep-0451/ + + +File: setuptools.info, Node: Incorporate changes from v44 1 0, Prev: Changes<21>, Up: v46 1 0 + +9.40.2 Incorporate changes from v44.1.0: +---------------------------------------- + + * #1704(1): Set sys.argv[0] in setup script run by + build_meta.__legacy__ + + * #1959(2): Fix for Python 4: replace unsafe six.PY3 with six.PY2 + + * #1994(3): Fixed a bug in the + “setuptools.finalize_distribution_options” hook that lead to + ignoring the order attribute of entry points managed by this hook. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1704 + + (2) https://github.com/pypa/setuptools/issues/1959 + + (3) https://github.com/pypa/setuptools/issues/1994 + + +File: setuptools.info, Node: v44 1 0, Next: v46 0 0, Prev: v46 1 0, Up: History<2> + +9.41 v44.1.0 +============ + +21 Mar 2020 + +* Menu: + +* Changes: Changes<22>. + + +File: setuptools.info, Node: Changes<22>, Up: v44 1 0 + +9.41.1 Changes +-------------- + + * #1704(1): Set sys.argv[0] in setup script run by + build_meta.__legacy__ + + * #1959(2): Fix for Python 4: replace unsafe six.PY3 with six.PY2 + + * #1994(3): Fixed a bug in the + “setuptools.finalize_distribution_options” hook that lead to + ignoring the order attribute of entry points managed by this hook. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1704 + + (2) https://github.com/pypa/setuptools/issues/1959 + + (3) https://github.com/pypa/setuptools/issues/1994 + + +File: setuptools.info, Node: v46 0 0, Next: v45 3 0, Prev: v44 1 0, Up: History<2> + +9.42 v46.0.0 +============ + +08 Mar 2020 + +* Menu: + +* Breaking Changes: Breaking Changes<5>. +* Changes: Changes<23>. +* Documentation changes: Documentation changes<6>. +* Misc: Misc<19>. + + +File: setuptools.info, Node: Breaking Changes<5>, Next: Changes<23>, Up: v46 0 0 + +9.42.1 Breaking Changes +----------------------- + + * #65(1): Once again as in 3.0, removed the Features feature. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/65 + + +File: setuptools.info, Node: Changes<23>, Next: Documentation changes<6>, Prev: Breaking Changes<5>, Up: v46 0 0 + +9.42.2 Changes +-------------- + + * #1890(1): Fix vendored dependencies so importing + ‘setuptools.extern.some_module’ gives the same object as + ‘setuptools._vendor.some_module’. This makes Metadata picklable + again. + + * #1899(2): Test suite now fails on warnings. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1890 + + (2) https://github.com/pypa/setuptools/issues/1899 + + +File: setuptools.info, Node: Documentation changes<6>, Next: Misc<19>, Prev: Changes<23>, Up: v46 0 0 + +9.42.3 Documentation changes +---------------------------- + + * #2011(1): Fix broken link to distutils docs on package_data + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/2011 + + +File: setuptools.info, Node: Misc<19>, Prev: Documentation changes<6>, Up: v46 0 0 + +9.42.4 Misc +----------- + + * #1991(1): Include pkg_resources test data in sdist, so tests can be + executed from it. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1991 + + +File: setuptools.info, Node: v45 3 0, Next: v45 2 0, Prev: v46 0 0, Up: History<2> + +9.43 v45.3.0 +============ + +07 Mar 2020 + +* Menu: + +* Changes: Changes<24>. + + +File: setuptools.info, Node: Changes<24>, Up: v45 3 0 + +9.43.1 Changes +-------------- + + * #1557(1): Deprecated eggsecutable scripts and updated docs. + + * #1904(2): Update msvc.py to use CPython 3.8.0 mechanism to find + msvc 14+ + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1557 + + (2) https://github.com/pypa/setuptools/issues/1904 + + +File: setuptools.info, Node: v45 2 0, Next: v45 1 0, Prev: v45 3 0, Up: History<2> + +9.44 v45.2.0 +============ + +08 Feb 2020 + +* Menu: + +* Changes: Changes<25>. +* Misc: Misc<20>. + + +File: setuptools.info, Node: Changes<25>, Next: Misc<20>, Up: v45 2 0 + +9.44.1 Changes +-------------- + + * #1905(1): Fixed defect in _imp, introduced in 41.6.0 when the + ‘tests’ directory is not present. + + * #1941(2): Improve editable installs with PEP 518(3) build + isolation: + + * The ‘--user’ option is now always available. A warning is + issued if the user site directory is not available. + + * The error shown when the install directory is not in + ‘PYTHONPATH’ has been turned into a warning. + + * #1981(4): Setuptools now declares its ‘tests’ and ‘docs’ + dependencies in metadata (extras). + + * #1985(5): Add support for installing scripts in environments where + bdist_wininst is missing (i.e. Python 3.9). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1905 + + (2) https://github.com/pypa/setuptools/issues/1941 + + (3) https://www.python.org/dev/peps/pep-0518/ + + (4) https://github.com/pypa/setuptools/issues/1981 + + (5) https://github.com/pypa/setuptools/issues/1985 + + +File: setuptools.info, Node: Misc<20>, Prev: Changes<25>, Up: v45 2 0 + +9.44.2 Misc +----------- + + * #1968(1): Add flake8-2020 to check for misuse of sys.version or + sys.version_info. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1968 + + +File: setuptools.info, Node: v45 1 0, Next: v45 0 0, Prev: v45 2 0, Up: History<2> + +9.45 v45.1.0 +============ + +19 Jan 2020 + +* Menu: + +* Changes: Changes<26>. + + +File: setuptools.info, Node: Changes<26>, Up: v45 1 0 + +9.45.1 Changes +-------------- + + * #1458(1): Add minimum sunset date and preamble to Python 2 warning. + + * #1704(2): Set sys.argv[0] in setup script run by + build_meta.__legacy__ + + * #1974(3): Add Python 3 Only Trove Classifier and remove universal + wheel declaration for more complete transition from Python 2. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1458 + + (2) https://github.com/pypa/setuptools/issues/1704 + + (3) https://github.com/pypa/setuptools/issues/1974 + + +File: setuptools.info, Node: v45 0 0, Next: v44 0 0, Prev: v45 1 0, Up: History<2> + +9.46 v45.0.0 +============ + +11 Jan 2020 + +* Menu: + +* Breaking Changes: Breaking Changes<6>. +* Changes: Changes<27>. + + +File: setuptools.info, Node: Breaking Changes<6>, Next: Changes<27>, Up: v45 0 0 + +9.46.1 Breaking Changes +----------------------- + + * #1458(1): Drop support for Python 2. Setuptools now requires + Python 3.5 or later. Install setuptools using pip >=9 or pin to + Setuptools <45 to maintain 2.7 support. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1458 + + +File: setuptools.info, Node: Changes<27>, Prev: Breaking Changes<6>, Up: v45 0 0 + +9.46.2 Changes +-------------- + + * #1959(1): Fix for Python 4: replace unsafe six.PY3 with six.PY2 + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1959 + + +File: setuptools.info, Node: v44 0 0, Next: v43 0 0, Prev: v45 0 0, Up: History<2> + +9.47 v44.0.0 +============ + +01 Jan 2020 + +* Menu: + +* Breaking Changes: Breaking Changes<7>. + + +File: setuptools.info, Node: Breaking Changes<7>, Up: v44 0 0 + +9.47.1 Breaking Changes +----------------------- + + * #1908(1): Drop support for Python 3.4. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1908 + + +File: setuptools.info, Node: v43 0 0, Next: v42 0 2, Prev: v44 0 0, Up: History<2> + +9.48 v43.0.0 +============ + +31 Dec 2019 + +* Menu: + +* Breaking Changes: Breaking Changes<8>. +* Changes: Changes<28>. + + +File: setuptools.info, Node: Breaking Changes<8>, Next: Changes<28>, Up: v43 0 0 + +9.48.1 Breaking Changes +----------------------- + + * #1634(1): Include ‘pyproject.toml’ in source distribution by + default. Projects relying on the previous behavior where + ‘pyproject.toml’ was excluded by default should stop relying on + that behavior or add ‘exclude pyproject.toml’ to their MANIFEST.in + file. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1634 + + +File: setuptools.info, Node: Changes<28>, Prev: Breaking Changes<8>, Up: v43 0 0 + +9.48.2 Changes +-------------- + + * #1927(1): Setuptools once again declares ‘setuptools’ in the + ‘build-system.requires’ and adds PEP 517(2) build support by + declaring itself as the ‘build-backend’. It additionally specifies + ‘build-system.backend-path’ to rely on itself for those builders + that support it. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1927 + + (2) https://www.python.org/dev/peps/pep-0517/ + + +File: setuptools.info, Node: v42 0 2, Next: v42 0 1, Prev: v43 0 0, Up: History<2> + +9.49 v42.0.2 +============ + +01 Dec 2019 + +* Menu: + +* Changes: Changes<29>. + + +File: setuptools.info, Node: Changes<29>, Up: v42 0 2 + +9.49.1 Changes +-------------- + + * #1921(1): Fix support for easy_install’s ‘find-links’ option in + ‘setup.cfg’. + + * #1922(2): Build dependencies (setup_requires and tests_require) now + install transitive dependencies indicated by extras. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1921 + + (2) https://github.com/pypa/setuptools/issues/1922 + + +File: setuptools.info, Node: v42 0 1, Next: v42 0 0, Prev: v42 0 2, Up: History<2> + +9.50 v42.0.1 +============ + +25 Nov 2019 + +* Menu: + +* Changes: Changes<30>. + + +File: setuptools.info, Node: Changes<30>, Up: v42 0 1 + +9.50.1 Changes +-------------- + + * #1918(1): Fix regression in handling wheels compatibility tags. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1918 + + +File: setuptools.info, Node: v42 0 0, Next: v41 6 0, Prev: v42 0 1, Up: History<2> + +9.51 v42.0.0 +============ + +23 Nov 2019 + +* Menu: + +* Breaking Changes: Breaking Changes<9>. +* Changes: Changes<31>. + + +File: setuptools.info, Node: Breaking Changes<9>, Next: Changes<31>, Up: v42 0 0 + +9.51.1 Breaking Changes +----------------------- + + * + #1830(1), #1909(2): Mark the easy_install script and setuptools command as deprecated, and use pip(3) when available to fetch/build wheels for missing ‘setup_requires’/‘tests_require’ requirements, with the following differences in behavior: + + * support for ‘python_requires’ + + * better support for wheels (proper handling of priority + with respect to PEP 425(4) tags) + + * PEP 517(5)/518 support + + * eggs are not supported + + * no support for the ‘allow_hosts’ easy_install option + (‘index_url’/‘find_links’ are still honored) + + * pip environment variables are honored (and take + precedence over easy_install options) + + * #1898(6): Removed the “upload” and “register” commands in favor of + twine(7). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1830 + + (2) https://github.com/pypa/setuptools/issues/1909 + + (3) https://pip.pypa.io/en/stable/ + + (4) https://www.python.org/dev/peps/pep-0425/ + + (5) https://www.python.org/dev/peps/pep-0517/ + + (6) https://github.com/pypa/setuptools/issues/1898 + + (7) https://pypi.org/p/twine + + +File: setuptools.info, Node: Changes<31>, Prev: Breaking Changes<9>, Up: v42 0 0 + +9.51.2 Changes +-------------- + + * #1767(1): Add support for the ‘license_files’ option in ‘setup.cfg’ + to automatically include multiple license files in a source + distribution. + + * #1829(2): Update handling of wheels compatibility tags: * add + support for manylinux2010 * fix use of removed ‘m’ ABI flag in + Python 3.8 on Windows + + * #1861(3): Fix empty namespace package installation from wheel. + + * #1877(4): Setuptools now exposes a new entry point hook + “setuptools.finalize_distribution_options”, enabling plugins like + setuptools_scm(5) to configure options on the distribution at + finalization time. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1767 + + (2) https://github.com/pypa/setuptools/issues/1829 + + (3) https://github.com/pypa/setuptools/issues/1861 + + (4) https://github.com/pypa/setuptools/issues/1877 + + (5) https://pypi.org/project/setuptools_scm + + +File: setuptools.info, Node: v41 6 0, Next: v41 5 1, Prev: v42 0 0, Up: History<2> + +9.52 v41.6.0 +============ + +29 Oct 2019 + +* Menu: + +* Changes: Changes<32>. + + +File: setuptools.info, Node: Changes<32>, Up: v41 6 0 + +9.52.1 Changes +-------------- + + * #479(1): Replace usage of deprecated ‘imp’ module with local + re-implementation in ‘setuptools._imp’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/479 + + +File: setuptools.info, Node: v41 5 1, Next: v41 5 0, Prev: v41 6 0, Up: History<2> + +9.53 v41.5.1 +============ + +28 Oct 2019 + +* Menu: + +* Changes: Changes<33>. + + +File: setuptools.info, Node: Changes<33>, Up: v41 5 1 + +9.53.1 Changes +-------------- + + * #1891(1): Fix code for detecting Visual Studio’s version on Windows + under Python 2. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1891 + + +File: setuptools.info, Node: v41 5 0, Next: v41 4 0, Prev: v41 5 1, Up: History<2> + +9.54 v41.5.0 +============ + +27 Oct 2019 + +* Menu: + +* Changes: Changes<34>. +* Documentation changes: Documentation changes<7>. +* Misc: Misc<21>. + + +File: setuptools.info, Node: Changes<34>, Next: Documentation changes<7>, Up: v41 5 0 + +9.54.1 Changes +-------------- + + * #1811(1): Improve Visual C++ 14.X support, mainly for Visual Studio + 2017 and 2019. + + * #1814(2): Fix ‘pkg_resources.Requirement’ hash/equality + implementation: take PEP 508(3) direct URL into account. + + * #1824(4): Fix tests when running under ‘python3.10’. + + * #1878(5): Formally deprecated the ‘test’ command, with the + recommendation that users migrate to ‘tox’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1811 + + (2) https://github.com/pypa/setuptools/issues/1814 + + (3) https://www.python.org/dev/peps/pep-0508/ + + (4) https://github.com/pypa/setuptools/issues/1824 + + (5) https://github.com/pypa/setuptools/issues/1878 + + +File: setuptools.info, Node: Documentation changes<7>, Next: Misc<21>, Prev: Changes<34>, Up: v41 5 0 + +9.54.2 Documentation changes +---------------------------- + + * #1860(1): Update documentation to mention the egg format is not + supported by pip and dependency links support was dropped starting + with pip 19.0. + + * #1862(2): Drop ez_setup documentation: deprecated for some time + (last updated in 2016), and still relying on easy_install + (deprecated too). + + * #1868(3): Drop most documentation references to (deprecated) + EasyInstall. + + * #1884(4): Added a trove classifier to document support for Python + 3.8. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1860 + + (2) https://github.com/pypa/setuptools/issues/1862 + + (3) https://github.com/pypa/setuptools/issues/1868 + + (4) https://github.com/pypa/setuptools/issues/1884 + + +File: setuptools.info, Node: Misc<21>, Prev: Documentation changes<7>, Up: v41 5 0 + +9.54.3 Misc +----------- + + * #1886(1): Added Python 3.8 release to the Travis test matrix. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1886 + + +File: setuptools.info, Node: v41 4 0, Next: v41 3 0, Prev: v41 5 0, Up: History<2> + +9.55 v41.4.0 +============ + +06 Oct 2019 + +* Menu: + +* Changes: Changes<35>. + + +File: setuptools.info, Node: Changes<35>, Up: v41 4 0 + +9.55.1 Changes +-------------- + + * #1847(1): In declarative config, now traps errors when invalid + ‘python_requires’ values are supplied. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1847 + + +File: setuptools.info, Node: v41 3 0, Next: v41 2 0, Prev: v41 4 0, Up: History<2> + +9.56 v41.3.0 +============ + +06 Oct 2019 + +* Menu: + +* Changes: Changes<36>. +* Misc: Misc<22>. + + +File: setuptools.info, Node: Changes<36>, Next: Misc<22>, Up: v41 3 0 + +9.56.1 Changes +-------------- + + * #1690(1): When storing extras, rely on OrderedSet to retain order + of extras as indicated by the packager, which will also be + deterministic on Python 2.7 (with PYTHONHASHSEED unset) and Python + 3.6+. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1690 + + +File: setuptools.info, Node: Misc<22>, Prev: Changes<36>, Up: v41 3 0 + +9.56.2 Misc +----------- + + * #1858(1): Fixed failing integration test triggered by + ‘long_description_content_type’ in packaging. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1858 + + +File: setuptools.info, Node: v41 2 0, Next: v41 1 0, Prev: v41 3 0, Up: History<2> + +9.57 v41.2.0 +============ + +21 Aug 2019 + +* Menu: + +* Changes: Changes<37>. +* Misc: Misc<23>. + + +File: setuptools.info, Node: Changes<37>, Next: Misc<23>, Up: v41 2 0 + +9.57.1 Changes +-------------- + + * #479(1): Remove some usage of the deprecated ‘imp’ module. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/479 + + +File: setuptools.info, Node: Misc<23>, Prev: Changes<37>, Up: v41 2 0 + +9.57.2 Misc +----------- + + * #1565(1): Changed html_sidebars from string to list of string as + per ‘https://www.sphinx-doc.org/en/master/changes.html#id58’ + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1565 + + +File: setuptools.info, Node: v41 1 0, Next: v41 0 1, Prev: v41 2 0, Up: History<2> + +9.58 v41.1.0 +============ + +13 Aug 2019 + +* Menu: + +* Misc: Misc<24>. +* Documentation changes: Documentation changes<8>. + + +File: setuptools.info, Node: Misc<24>, Next: Documentation changes<8>, Up: v41 1 0 + +9.58.1 Misc +----------- + + * #1697(1): Moved most of the constants from setup.py to setup.cfg + + * #1749(2): Fixed issue with the PEP 517(3) backend where building a + source distribution would fail if any tarball existed in the + destination directory. + + * #1750(4): Fixed an issue with PEP 517(5) backend where wheel builds + would fail if the destination directory did not already exist. + + * #1756(6): Force metadata-version >= 1.2. when project urls are + present. + + * #1769(7): Improve ‘package_data’ check: ensure the dictionary + values are lists/tuples of strings. + + * #1788(8): Changed compatibility fallback logic for ‘html.unescape’ + to avoid accessing ‘HTMLParser.unescape’ when not necessary. + ‘HTMLParser.unescape’ is deprecated and will be removed in Python + 3.9. + + * #1790(9): Added the file path to the error message when a + ‘UnicodeDecodeError’ occurs while reading a metadata file. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1697 + + (2) https://github.com/pypa/setuptools/issues/1749 + + (3) https://www.python.org/dev/peps/pep-0517/ + + (4) https://github.com/pypa/setuptools/issues/1750 + + (5) https://www.python.org/dev/peps/pep-0517/ + + (6) https://github.com/pypa/setuptools/issues/1756 + + (7) https://github.com/pypa/setuptools/issues/1769 + + (8) https://github.com/pypa/setuptools/issues/1788 + + (9) https://github.com/pypa/setuptools/issues/1790 + + +File: setuptools.info, Node: Documentation changes<8>, Prev: Misc<24>, Up: v41 1 0 + +9.58.2 Documentation changes +---------------------------- + + * #1776(1): Use license classifiers rather than the license field. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1776 + + +File: setuptools.info, Node: v41 0 1, Next: v41 0 0, Prev: v41 1 0, Up: History<2> + +9.59 v41.0.1 +============ + +22 Apr 2019 + +* Menu: + +* Changes: Changes<38>. + + +File: setuptools.info, Node: Changes<38>, Up: v41 0 1 + +9.59.1 Changes +-------------- + + * #1671(1): Fixed issue with the PEP 517(2) backend that prevented + building a wheel when the ‘dist/’ directory contained existing + ‘.whl’ files. + + * #1709(3): In test.paths_on_python_path, avoid adding unnecessary + duplicates to the PYTHONPATH. + + * #1741(4): In package_index, now honor “current directory” during a + checkout of git and hg repositories under Windows + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1671 + + (2) https://www.python.org/dev/peps/pep-0517/ + + (3) https://github.com/pypa/setuptools/issues/1709 + + (4) https://github.com/pypa/setuptools/issues/1741 + + +File: setuptools.info, Node: v41 0 0, Next: v40 9 0, Prev: v41 0 1, Up: History<2> + +9.60 v41.0.0 +============ + +05 Apr 2019 + +* Menu: + +* Breaking Changes: Breaking Changes<10>. + + +File: setuptools.info, Node: Breaking Changes<10>, Up: v41 0 0 + +9.60.1 Breaking Changes +----------------------- + + * #1735(1): When parsing setup.cfg files, setuptools now requires the + files to be encoded as UTF-8. Any other encoding will lead to a + UnicodeDecodeError. This change removes support for specifying an + encoding using a ‘coding: ‘ directive in the header of the file, a + feature that was introduces in 40.7. Given the recent release of + the aforementioned feature, it is assumed that few if any projects + are utilizing the feature to specify an encoding other than UTF-8. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1735 + + +File: setuptools.info, Node: v40 9 0, Next: v40 8 0, Prev: v41 0 0, Up: History<2> + +9.61 v40.9.0 +============ + +03 Apr 2019 + +* Menu: + +* Changes: Changes<39>. +* Documentation changes: Documentation changes<9>. + + +File: setuptools.info, Node: Changes<39>, Next: Documentation changes<9>, Up: v40 9 0 + +9.61.1 Changes +-------------- + + * #1675(1): Added support for ‘setup.cfg’-only projects when using + the ‘setuptools.build_meta’ backend. Projects that have enabled + PEP 517(2) no longer need to have a ‘setup.py’ and can use the + purely declarative ‘setup.cfg’ configuration file instead. + + * #1720(3): Added support for + ‘pkg_resources.parse_requirements’-style requirements in + ‘setup_requires’ when ‘setup.py’ is invoked from the + ‘setuptools.build_meta’ build backend. + + * #1664(4): Added the path to the ‘PKG-INFO’ or ‘METADATA’ file in + the exception text when the ‘Version:’ header can’t be found. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1675 + + (2) https://www.python.org/dev/peps/pep-0517/ + + (3) https://github.com/pypa/setuptools/issues/1720 + + (4) https://github.com/pypa/setuptools/issues/1664 + + +File: setuptools.info, Node: Documentation changes<9>, Prev: Changes<39>, Up: v40 9 0 + +9.61.2 Documentation changes +---------------------------- + + * #1705(1): Removed some placeholder documentation sections referring + to deprecated features. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1705 + + +File: setuptools.info, Node: v40 8 0, Next: v40 7 3, Prev: v40 9 0, Up: History<2> + +9.62 v40.8.0 +============ + +05 Feb 2019 + +* Menu: + +* Changes: Changes<40>. + + +File: setuptools.info, Node: Changes<40>, Up: v40 8 0 + +9.62.1 Changes +-------------- + + * #1652(1): Added the ‘build_meta:__legacy__’ backend, a + “compatibility mode” PEP 517(2) backend that can be used as the + default when ‘build-backend’ is left unspecified in + ‘pyproject.toml’. + + * #1635(3): Resource paths are passed to + ‘pkg_resources.resource_string’ and similar no longer accept paths + that traverse parents, that begin with a leading ‘/’. Violations + of this expectation raise DeprecationWarnings and will become + errors. Additionally, any paths that are absolute on Windows are + strictly disallowed and will raise ValueErrors. + + * #1536(4): ‘setuptools’ will now automatically include licenses if + ‘setup.cfg’ contains a ‘license_file’ attribute, unless this file + is manually excluded inside ‘MANIFEST.in’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1652 + + (2) https://www.python.org/dev/peps/pep-0517/ + + (3) https://github.com/pypa/setuptools/issues/1635 + + (4) https://github.com/pypa/setuptools/issues/1536 + + +File: setuptools.info, Node: v40 7 3, Next: v40 7 2, Prev: v40 8 0, Up: History<2> + +9.63 v40.7.3 +============ + +03 Feb 2019 + +* Menu: + +* Changes: Changes<41>. + + +File: setuptools.info, Node: Changes<41>, Up: v40 7 3 + +9.63.1 Changes +-------------- + + * #1670(1): In package_index, revert to using a copy of splituser + from Python 3.8. Attempts to use ‘urllib.parse.urlparse’ led to + problems as reported in #1663(2) and #1668(3). This change serves + as an alternative to #1499(4) and fixes #1668(5). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1670 + + (2) https://github.com/pypa/setuptools/issues/1663 + + (3) https://github.com/pypa/setuptools/issues/1668 + + (4) https://github.com/pypa/setuptools/issues/1499 + + (5) https://github.com/pypa/setuptools/issues/1668 + + +File: setuptools.info, Node: v40 7 2, Next: v40 7 1, Prev: v40 7 3, Up: History<2> + +9.64 v40.7.2 +============ + +31 Jan 2019 + +* Menu: + +* Changes: Changes<42>. + + +File: setuptools.info, Node: Changes<42>, Up: v40 7 2 + +9.64.1 Changes +-------------- + + * #1666(1): Restore port in URL handling in package_index. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1666 + + +File: setuptools.info, Node: v40 7 1, Next: v40 7 0, Prev: v40 7 2, Up: History<2> + +9.65 v40.7.1 +============ + +28 Jan 2019 + +* Menu: + +* Changes: Changes<43>. + + +File: setuptools.info, Node: Changes<43>, Up: v40 7 1 + +9.65.1 Changes +-------------- + + * #1660(1): On Python 2, when reading config files, downcast options + from text to bytes to satisfy distutils expectations. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1660 + + +File: setuptools.info, Node: v40 7 0, Next: v40 6 3, Prev: v40 7 1, Up: History<2> + +9.66 v40.7.0 +============ + +27 Jan 2019 + +* Menu: + +* Breaking Changes: Breaking Changes<11>. +* Changes: Changes<44>. + + +File: setuptools.info, Node: Breaking Changes<11>, Next: Changes<44>, Up: v40 7 0 + +9.66.1 Breaking Changes +----------------------- + + * #1551(1): File inputs for the ‘license’ field in ‘setup.cfg’ files + now explicitly raise an error. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1551 + + +File: setuptools.info, Node: Changes<44>, Prev: Breaking Changes<11>, Up: v40 7 0 + +9.66.2 Changes +-------------- + + * #1180(1): Add support for non-ASCII in setup.cfg (#1062(2)). Add + support for native strings on some parameters (#1136(3)). + + * #1499(4): ‘setuptools.package_index’ no longer relies on the + deprecated ‘urllib.parse.splituser’ per Python #27485(5). + + * #1544(6): Added tests for PackageIndex.download (for git URLs). + + * #1625(7): In PEP 517(8) build_meta builder, ensure that sdists are + built as gztar per the spec. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1180 + + (2) https://github.com/pypa/setuptools/issues/1062 + + (3) https://github.com/pypa/setuptools/issues/1136 + + (4) https://github.com/pypa/setuptools/issues/1499 + + (5) http://bugs.python.org/issue27485 + + (6) https://github.com/pypa/setuptools/issues/1544 + + (7) https://github.com/pypa/setuptools/issues/1625 + + (8) https://www.python.org/dev/peps/pep-0517/ + + +File: setuptools.info, Node: v40 6 3, Next: v40 6 2, Prev: v40 7 0, Up: History<2> + +9.67 v40.6.3 +============ + +11 Dec 2018 + +* Menu: + +* Changes: Changes<45>. + + +File: setuptools.info, Node: Changes<45>, Up: v40 6 3 + +9.67.1 Changes +-------------- + + * #1594(1): PEP 517(2) backend no longer declares setuptools as a + dependency as it can be assumed. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1594 + + (2) https://www.python.org/dev/peps/pep-0517/ + + +File: setuptools.info, Node: v40 6 2, Next: v40 6 1, Prev: v40 6 3, Up: History<2> + +9.68 v40.6.2 +============ + +13 Nov 2018 + +* Menu: + +* Changes: Changes<46>. + + +File: setuptools.info, Node: Changes<46>, Up: v40 6 2 + +9.68.1 Changes +-------------- + + * #1592(1): Fix invalid dependency on external six module (instead of + vendored version). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1592 + + +File: setuptools.info, Node: v40 6 1, Next: v40 6 0, Prev: v40 6 2, Up: History<2> + +9.69 v40.6.1 +============ + +12 Nov 2018 + +* Menu: + +* Changes: Changes<47>. + + +File: setuptools.info, Node: Changes<47>, Up: v40 6 1 + +9.69.1 Changes +-------------- + + * #1590(1): Fixed regression where packages without ‘author’ or + ‘author_email’ fields generated malformed package metadata. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1590 + + +File: setuptools.info, Node: v40 6 0, Next: v40 5 0, Prev: v40 6 1, Up: History<2> + +9.70 v40.6.0 +============ + +12 Nov 2018 + +* Menu: + +* Deprecations:: +* Changes: Changes<48>. +* Documentation changes: Documentation changes<10>. +* Misc: Misc<25>. + + +File: setuptools.info, Node: Deprecations, Next: Changes<48>, Up: v40 6 0 + +9.70.1 Deprecations +------------------- + + * #1541(1): Officially deprecated the ‘requires’ parameter in + ‘setup()’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1541 + + +File: setuptools.info, Node: Changes<48>, Next: Documentation changes<10>, Prev: Deprecations, Up: v40 6 0 + +9.70.2 Changes +-------------- + + * #1519(1): In ‘pkg_resources.normalize_path’, additional path + normalization is now performed to ensure path values to a directory + is always the same, preventing false positives when checking + scripts have a consistent prefix to set up on Windows. + + * #1545(2): Changed the warning class of all deprecation warnings; + deprecation warning classes are no longer derived from + ‘DeprecationWarning’ and are thus visible by default. + + * #1554(3): ‘build_meta.build_sdist’ now includes ‘setup.py’ in + source distributions by default. + + * #1576(4): Started monkey-patching ‘get_metadata_version’ and + ‘read_pkg_file’ onto ‘distutils.DistributionMetadata’ to retain the + correct version on the ‘PKG-INFO’ file in the (deprecated) ‘upload’ + command. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1519 + + (2) https://github.com/pypa/setuptools/issues/1545 + + (3) https://github.com/pypa/setuptools/issues/1554 + + (4) https://github.com/pypa/setuptools/issues/1576 + + +File: setuptools.info, Node: Documentation changes<10>, Next: Misc<25>, Prev: Changes<48>, Up: v40 6 0 + +9.70.3 Documentation changes +---------------------------- + + * #1395(1): Changed Pyrex references to Cython in the documentation. + + * #1456(2): Documented that the ‘rpmbuild’ packages is required for + the ‘bdist_rpm’ command. + + * #1537(3): Documented how to use ‘setup.cfg’ for ‘src/ layouts’ + + * #1539(4): Added minimum version column in ‘setup.cfg’ metadata + table. + + * #1552(5): Fixed a minor typo in the python 2/3 compatibility + documentation. + + * #1553(6): Updated installation instructions to point to ‘pip + install’ instead of ‘ez_setup.py’. + + * #1560(7): Updated ‘setuptools’ distribution documentation to remove + some outdated information. + + * #1564(8): Documented ‘setup.cfg’ minimum version for version and + project_urls. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1395 + + (2) https://github.com/pypa/setuptools/issues/1456 + + (3) https://github.com/pypa/setuptools/issues/1537 + + (4) https://github.com/pypa/setuptools/issues/1539 + + (5) https://github.com/pypa/setuptools/issues/1552 + + (6) https://github.com/pypa/setuptools/issues/1553 + + (7) https://github.com/pypa/setuptools/issues/1560 + + (8) https://github.com/pypa/setuptools/issues/1564 + + +File: setuptools.info, Node: Misc<25>, Prev: Documentation changes<10>, Up: v40 6 0 + +9.70.4 Misc +----------- + + * #1533(1): Restricted the ‘recursive-include setuptools/_vendor’ to + contain only .py and .txt files. + + * #1572(2): Added the ‘concurrent.futures’ backport ‘futures’ to the + Python 2.7 test suite requirements. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1533 + + (2) https://github.com/pypa/setuptools/issues/1572 + + +File: setuptools.info, Node: v40 5 0, Next: v40 4 3, Prev: v40 6 0, Up: History<2> + +9.71 v40.5.0 +============ + +26 Oct 2018 + +* Menu: + +* Changes: Changes<49>. +* Documentation changes: Documentation changes<11>. + + +File: setuptools.info, Node: Changes<49>, Next: Documentation changes<11>, Up: v40 5 0 + +9.71.1 Changes +-------------- + + * #1335(1): In ‘pkg_resources.normalize_path’, fix issue on Cygwin + when cwd contains symlinks. + + * #1502(2): Deprecated support for downloads from Subversion in + package_index/easy_install. + + * #1517(3): Dropped use of six.u in favor of ‘u""’ literals. + + * #1520(4): Added support for ‘data_files’ in ‘setup.cfg’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1335 + + (2) https://github.com/pypa/setuptools/issues/1502 + + (3) https://github.com/pypa/setuptools/issues/1517 + + (4) https://github.com/pypa/setuptools/issues/1520 + + +File: setuptools.info, Node: Documentation changes<11>, Prev: Changes<49>, Up: v40 5 0 + +9.71.2 Documentation changes +---------------------------- + + * #1525(1): Fixed rendering of the deprecation warning in + easy_install doc. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1525 + + +File: setuptools.info, Node: v40 4 3, Next: v40 4 2, Prev: v40 5 0, Up: History<2> + +9.72 v40.4.3 +============ + +23 Sep 2018 + +* Menu: + +* Changes: Changes<50>. + + +File: setuptools.info, Node: Changes<50>, Up: v40 4 3 + +9.72.1 Changes +-------------- + + * #1480(1): Bump vendored pyparsing in pkg_resources to 2.2.1. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1480 + + +File: setuptools.info, Node: v40 4 2, Next: v40 4 1, Prev: v40 4 3, Up: History<2> + +9.73 v40.4.2 +============ + +21 Sep 2018 + +* Menu: + +* Misc: Misc<26>. + + +File: setuptools.info, Node: Misc<26>, Up: v40 4 2 + +9.73.1 Misc +----------- + + * #1497(1): Updated gitignore in repo. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1497 + + +File: setuptools.info, Node: v40 4 1, Next: v40 4 0, Prev: v40 4 2, Up: History<2> + +9.74 v40.4.1 +============ + +18 Sep 2018 + +* Menu: + +* Changes: Changes<51>. + + +File: setuptools.info, Node: Changes<51>, Up: v40 4 1 + +9.74.1 Changes +-------------- + + * #1480(1): Bump vendored pyparsing to 2.2.1. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1480 + + +File: setuptools.info, Node: v40 4 0, Next: v40 3 0, Prev: v40 4 1, Up: History<2> + +9.75 v40.4.0 +============ + +18 Sep 2018 + +* Menu: + +* Changes: Changes<52>. + + +File: setuptools.info, Node: Changes<52>, Up: v40 4 0 + +9.75.1 Changes +-------------- + + * #1481(1): Join the sdist ‘--dist-dir’ and the ‘build_meta’ sdist + directory argument to point to the same target (meaning the build + frontend no longer needs to clean manually the dist dir to avoid + multiple sdist presence, and setuptools no longer needs to handle + conflicts between the two). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1481 + + +File: setuptools.info, Node: v40 3 0, Next: v40 2 0, Prev: v40 4 0, Up: History<2> + +9.76 v40.3.0 +============ + +16 Sep 2018 + +* Menu: + +* Changes: Changes<53>. +* Misc: Misc<27>. + + +File: setuptools.info, Node: Changes<53>, Next: Misc<27>, Up: v40 3 0 + +9.76.1 Changes +-------------- + + * #1402(1): Fixed a bug with namespace packages under Python 3.6 when + one package in current directory hides another which is installed. + + * #1427(2): Set timestamp of ‘.egg-info’ directory whenever + ‘egg_info’ command is run. + + * #1474(3): ‘build_meta.get_requires_for_build_sdist’ now does not + include the ‘wheel’ package anymore. + + * #1486(4): Suppress warnings in pkg_resources.handle_ns. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1402 + + (2) https://github.com/pypa/setuptools/issues/1427 + + (3) https://github.com/pypa/setuptools/issues/1474 + + (4) https://github.com/pypa/setuptools/issues/1486 + + +File: setuptools.info, Node: Misc<27>, Prev: Changes<53>, Up: v40 3 0 + +9.76.2 Misc +----------- + + * #1479(1): Remove internal use of six.binary_type. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1479 + + +File: setuptools.info, Node: v40 2 0, Next: v40 1 1, Prev: v40 3 0, Up: History<2> + +9.77 v40.2.0 +============ + +21 Aug 2018 + +* Menu: + +* Changes: Changes<54>. + + +File: setuptools.info, Node: Changes<54>, Up: v40 2 0 + +9.77.1 Changes +-------------- + + * #1466(1): Fix handling of Unicode arguments in PEP 517(2) backend + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1466 + + (2) https://www.python.org/dev/peps/pep-0517/ + + +File: setuptools.info, Node: v40 1 1, Next: v40 1 0, Prev: v40 2 0, Up: History<2> + +9.78 v40.1.1 +============ + +21 Aug 2018 + +* Menu: + +* Changes: Changes<55>. + + +File: setuptools.info, Node: Changes<55>, Up: v40 1 1 + +9.78.1 Changes +-------------- + + * #1465(1): Fix regression with ‘egg_info’ command when tagging is + used. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1465 + + +File: setuptools.info, Node: v40 1 0, Next: v40 0 0, Prev: v40 1 1, Up: History<2> + +9.79 v40.1.0 +============ + +17 Aug 2018 + +* Menu: + +* Changes: Changes<56>. +* Misc: Misc<28>. + + +File: setuptools.info, Node: Changes<56>, Next: Misc<28>, Up: v40 1 0 + +9.79.1 Changes +-------------- + + * #1410(1): Deprecated ‘upload’ and ‘register’ commands. + + * #1312(2): Introduced find_namespace_packages() to find PEP 420(3) + namespace packages. + + * #1420(4): Added find_namespace: directive to config parser. + + * #1418(5): Solved race in when creating egg cache directories. + + * #1450(6): Upgraded vendored PyParsing from 2.1.10 to 2.2.0. + + * #1451(7): Upgraded vendored appdirs from 1.4.0 to 1.4.3. + + * #1388(8): Fixed “Microsoft Visual C++ Build Tools” link in + exception when Visual C++ not found. + + * #1389(9): Added support for scripts which have unicode content. + + * #1416(10): Moved several Python version checks over to using + ‘six.PY2’ and ‘six.PY3’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1410 + + (2) https://github.com/pypa/setuptools/issues/1312 + + (3) https://www.python.org/dev/peps/pep-0420/ + + (4) https://github.com/pypa/setuptools/issues/1420 + + (5) https://github.com/pypa/setuptools/issues/1418 + + (6) https://github.com/pypa/setuptools/issues/1450 + + (7) https://github.com/pypa/setuptools/issues/1451 + + (8) https://github.com/pypa/setuptools/issues/1388 + + (9) https://github.com/pypa/setuptools/issues/1389 + + (10) https://github.com/pypa/setuptools/issues/1416 + + +File: setuptools.info, Node: Misc<28>, Prev: Changes<56>, Up: v40 1 0 + +9.79.2 Misc +----------- + + * #1441(1): Removed spurious executable permissions from files that + don’t need them. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1441 + + +File: setuptools.info, Node: v40 0 0, Next: v39 2 0, Prev: v40 1 0, Up: History<2> + +9.80 v40.0.0 +============ + +09 Jul 2018 + +* Menu: + +* Breaking Changes: Breaking Changes<12>. +* Changes: Changes<57>. +* Documentation changes: Documentation changes<12>. +* Misc: Misc<29>. + + +File: setuptools.info, Node: Breaking Changes<12>, Next: Changes<57>, Up: v40 0 0 + +9.80.1 Breaking Changes +----------------------- + + * #1342(1): Drop support for Python 3.3. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1342 + + +File: setuptools.info, Node: Changes<57>, Next: Documentation changes<12>, Prev: Breaking Changes<12>, Up: v40 0 0 + +9.80.2 Changes +-------------- + + * #1366(1): In package_index, fixed handling of encoded entities in + URLs. + + * #1383(2): In pkg_resources VendorImporter, avoid removing packages + imported from the root. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1366 + + (2) https://github.com/pypa/setuptools/issues/1383 + + +File: setuptools.info, Node: Documentation changes<12>, Next: Misc<29>, Prev: Changes<57>, Up: v40 0 0 + +9.80.3 Documentation changes +---------------------------- + + * #1379(1): Minor doc fixes after actually using the new release + process. + + * #1385(2): Removed section on non-package data files. + + * #1403(3): Fix developer’s guide. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1379 + + (2) https://github.com/pypa/setuptools/issues/1385 + + (3) https://github.com/pypa/setuptools/issues/1403 + + +File: setuptools.info, Node: Misc<29>, Prev: Documentation changes<12>, Up: v40 0 0 + +9.80.4 Misc +----------- + + * #1404(1): Fix PEP 518(2) configuration: set build requirements in + ‘pyproject.toml’ to ‘["wheel"]’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1404 + + (2) https://www.python.org/dev/peps/pep-0518/ + + +File: setuptools.info, Node: v39 2 0, Next: v39 1 0, Prev: v40 0 0, Up: History<2> + +9.81 v39.2.0 +============ + +19 May 2018 + +* Menu: + +* Changes: Changes<58>. +* Documentation changes: Documentation changes<13>. +* Misc: Misc<30>. + + +File: setuptools.info, Node: Changes<58>, Next: Documentation changes<13>, Up: v39 2 0 + +9.81.1 Changes +-------------- + + * #1359(1): Support using “file:” to load a PEP 440(2)-compliant + package version from a text file. + + * #1360(3): Fixed issue with a mismatch between the name of the + package and the name of the .dist-info file in wheel files + + * #1364(4): Add ‘__dir__()’ implementation to + ‘pkg_resources.Distribution()’ that includes the attributes in the + ‘_provider’ instance variable. + + * #1365(5): Take the package_dir option into account when loading the + version from a module attribute. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1359 + + (2) https://www.python.org/dev/peps/pep-0440/ + + (3) https://github.com/pypa/setuptools/issues/1360 + + (4) https://github.com/pypa/setuptools/issues/1364 + + (5) https://github.com/pypa/setuptools/issues/1365 + + +File: setuptools.info, Node: Documentation changes<13>, Next: Misc<30>, Prev: Changes<58>, Up: v39 2 0 + +9.81.2 Documentation changes +---------------------------- + + * #1353(1): Added coverage badge to README. + + * #1356(2): Made small fixes to the developer guide documentation. + + * #1357(3): Fixed warnings in documentation builds and started + enforcing that the docs build without warnings in tox. + + * #1376(4): Updated release process docs. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1353 + + (2) https://github.com/pypa/setuptools/issues/1356 + + (3) https://github.com/pypa/setuptools/issues/1357 + + (4) https://github.com/pypa/setuptools/issues/1376 + + +File: setuptools.info, Node: Misc<30>, Prev: Documentation changes<13>, Up: v39 2 0 + +9.81.3 Misc +----------- + + * #1343(1): The ‘setuptools’ specific + ‘long_description_content_type’, ‘project_urls’ and + ‘provides_extras’ fields are now set consistently after any + ‘distutils’ ‘setup_keywords’ calls, allowing them to override + values. + + * #1352(2): Added ‘tox’ environment for documentation builds. + + * #1354(3): Added ‘towncrier’ for changelog management. + + * #1355(4): Add PR template. + + * #1368(5): Fixed tests which failed without network connectivity. + + * #1369(6): Added unit tests for PEP 425(7) compatibility tags + support. + + * #1372(8): Stop testing Python 3.3 in Travis CI, now that the latest + version of ‘wheel’ no longer installs on it. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1343 + + (2) https://github.com/pypa/setuptools/issues/1352 + + (3) https://github.com/pypa/setuptools/issues/1354 + + (4) https://github.com/pypa/setuptools/issues/1355 + + (5) https://github.com/pypa/setuptools/issues/1368 + + (6) https://github.com/pypa/setuptools/issues/1369 + + (7) https://www.python.org/dev/peps/pep-0425/ + + (8) https://github.com/pypa/setuptools/issues/1372 + + +File: setuptools.info, Node: v39 1 0, Next: v39 0 1, Prev: v39 2 0, Up: History<2> + +9.82 v39.1.0 +============ + +28 Apr 2018 + + * #1340(1): Update all PyPI URLs to reflect the switch to the new + Warehouse codebase. + + * #1337(2): In ‘pkg_resources’, now support loading resources for + modules loaded by the ‘SourcelessFileLoader’. + + * #1332(3): Silence spurious wheel related warnings on Windows. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1340 + + (2) https://github.com/pypa/setuptools/issues/1337 + + (3) https://github.com/pypa/setuptools/issues/1332 + + +File: setuptools.info, Node: v39 0 1, Next: v39 0 0, Prev: v39 1 0, Up: History<2> + +9.83 v39.0.1 +============ + +18 Mar 2018 + + * #1297(1): Restore Unicode handling for Maintainer fields in + metadata. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1297 + + +File: setuptools.info, Node: v39 0 0, Next: v38 7 0, Prev: v39 0 1, Up: History<2> + +9.84 v39.0.0 +============ + +17 Mar 2018 + + * #1296(1): Setuptools now vendors its own direct dependencies, no + longer relying on the dependencies as vendored by pkg_resources. + + * #296(2): Removed long-deprecated support for iteration on Version + objects as returned by ‘pkg_resources.parse_version’. Removed the + ‘SetuptoolsVersion’ and ‘SetuptoolsLegacyVersion’ names as well. + They should not have been used, but if they were, replace with + ‘Version’ and ‘LegacyVersion’ from ‘packaging.version’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1296 + + (2) https://github.com/pypa/setuptools/issues/296 + + +File: setuptools.info, Node: v38 7 0, Next: v38 6 1, Prev: v39 0 0, Up: History<2> + +9.85 v38.7.0 +============ + +17 Mar 2018 + + * #1288(1): Add support for maintainer in PKG-INFO. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1288 + + +File: setuptools.info, Node: v38 6 1, Next: v38 6 0, Prev: v38 7 0, Up: History<2> + +9.86 v38.6.1 +============ + +17 Mar 2018 + + * #1292(1): Avoid generating ‘Provides-Extra’ in metadata when no + extra is present (but environment markers are). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1292 + + +File: setuptools.info, Node: v38 6 0, Next: v38 5 2, Prev: v38 6 1, Up: History<2> + +9.87 v38.6.0 +============ + +15 Mar 2018 + + * #1286(1): Add support for Metadata 2.1 (PEP 566(2)). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1286 + + (2) https://www.python.org/dev/peps/pep-0566/ + + +File: setuptools.info, Node: v38 5 2, Next: v38 5 1, Prev: v38 6 0, Up: History<2> + +9.88 v38.5.2 +============ + +06 Mar 2018 + + * #1285(1): Fixed RuntimeError in pkg_resources.parse_requirements on + Python 3.7 (stemming from PEP 479(2)). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1285 + + (2) https://www.python.org/dev/peps/pep-0479/ + + +File: setuptools.info, Node: v38 5 1, Next: v38 5 0, Prev: v38 5 2, Up: History<2> + +9.89 v38.5.1 +============ + +06 Feb 2018 + + * #1271(1): Revert to Cython legacy ‘build_ext’ behavior for + compatibility. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1271 + + +File: setuptools.info, Node: v38 5 0, Next: v38 4 1, Prev: v38 5 1, Up: History<2> + +9.90 v38.5.0 +============ + +04 Feb 2018 + + * #1229(1): Expand imports in ‘build_ext’ to refine detection of + Cython availability. + + * #1270(2): When Cython is available, ‘build_ext’ now uses the + new_build_ext. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1229 + + (2) https://github.com/pypa/setuptools/issues/1270 + + +File: setuptools.info, Node: v38 4 1, Next: v38 4 0, Prev: v38 5 0, Up: History<2> + +9.91 v38.4.1 +============ + +03 Feb 2018 + + * #1257(1): In bdist_egg.scan_module, fix ValueError on Python 3.7. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1257 + + +File: setuptools.info, Node: v38 4 0, Next: v38 3 0, Prev: v38 4 1, Up: History<2> + +9.92 v38.4.0 +============ + +05 Jan 2018 + + * #1231(1): Removed warning when PYTHONDONTWRITEBYTECODE is enabled. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1231 + + +File: setuptools.info, Node: v38 3 0, Next: v38 2 5, Prev: v38 4 0, Up: History<2> + +9.93 v38.3.0 +============ + +04 Jan 2018 + + * #1210(1): Add support for PEP 345(2) Project-URL metadata. + + * #1207(3): Add support for ‘long_description_type’ to setup.cfg + declarative config as intended and documented. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1210 + + (2) https://www.python.org/dev/peps/pep-0345/ + + (3) https://github.com/pypa/setuptools/issues/1207 + + +File: setuptools.info, Node: v38 2 5, Next: v38 2 4, Prev: v38 3 0, Up: History<2> + +9.94 v38.2.5 +============ + + * #1232(1): Fix trailing slash handling in + ‘pkg_resources.ZipProvider’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1232 + + +File: setuptools.info, Node: v38 2 4, Next: v38 2 3, Prev: v38 2 5, Up: History<2> + +9.95 v38.2.4 +============ + +04 Dec 2017 + + * #1220(1): Fix ‘data_files’ handling when installing from wheel. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1220 + + +File: setuptools.info, Node: v38 2 3, Next: v38 2 2, Prev: v38 2 4, Up: History<2> + +9.96 v38.2.3 +============ + +28 Nov 2017 + + * fix Travis’ Python 3.3 job. + + +File: setuptools.info, Node: v38 2 2, Next: v38 2 1, Prev: v38 2 3, Up: History<2> + +9.97 v38.2.2 +============ + +27 Nov 2017 + + * #1214(1): fix handling of namespace packages when installing from a + wheel. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1214 + + +File: setuptools.info, Node: v38 2 1, Next: v38 2 0, Prev: v38 2 2, Up: History<2> + +9.98 v38.2.1 +============ + +26 Nov 2017 + + * #1212(1): fix encoding handling of metadata when installing from a + wheel. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1212 + + +File: setuptools.info, Node: v38 2 0, Next: v38 1 0, Prev: v38 2 1, Up: History<2> + +9.99 v38.2.0 +============ + +26 Nov 2017 + + * #1200(1): easy_install now support installing from wheels: they + will be installed as standalone unzipped eggs. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1200 + + +File: setuptools.info, Node: v38 1 0, Next: v38 0 0, Prev: v38 2 0, Up: History<2> + +9.100 v38.1.0 +============= + +25 Nov 2017 + + * #1208(1): Improve error message when failing to locate scripts in + egg-info metadata. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1208 + + +File: setuptools.info, Node: v38 0 0, Next: v37 0 0, Prev: v38 1 0, Up: History<2> + +9.101 v38.0.0 +============= + +25 Nov 2017 + + * #458(1): In order to support deterministic builds, Setuptools no + longer allows packages to declare ‘install_requires’ as unordered + sequences (sets or dicts). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/458 + + +File: setuptools.info, Node: v37 0 0, Next: v36 8 0, Prev: v38 0 0, Up: History<2> + +9.102 v37.0.0 +============= + +20 Nov 2017 + + * #878(1): Drop support for Python 2.6. Python 2.6 users should rely + on ‘setuptools < 37dev’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/878 + + +File: setuptools.info, Node: v36 8 0, Next: v36 7 3, Prev: v37 0 0, Up: History<2> + +9.103 v36.8.0 +============= + +19 Nov 2017 + + * #1190(1): In SSL support for package index operations, use SNI + where available. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1190 + + +File: setuptools.info, Node: v36 7 3, Next: v36 7 2, Prev: v36 8 0, Up: History<2> + +9.104 v36.7.3 +============= + +13 Nov 2017 + + * #1175(1): Bug fixes to ‘build_meta’ module. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1175 + + +File: setuptools.info, Node: v36 7 2, Next: v36 7 1, Prev: v36 7 3, Up: History<2> + +9.105 v36.7.2 +============= + +13 Nov 2017 + + * #701(1): Fixed duplicate test discovery on Python 3. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/701 + + +File: setuptools.info, Node: v36 7 1, Next: v36 7 0, Prev: v36 7 2, Up: History<2> + +9.106 v36.7.1 +============= + +11 Nov 2017 + + * #1193(1): Avoid test failures in bdist_egg when + PYTHONDONTWRITEBYTECODE is set. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1193 + + +File: setuptools.info, Node: v36 7 0, Next: v36 6 1, Prev: v36 7 1, Up: History<2> + +9.107 v36.7.0 +============= + +09 Nov 2017 + + * #1054(1): Support ‘setup_requires’ in ‘setup.cfg’ files. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1054 + + +File: setuptools.info, Node: v36 6 1, Next: v36 6 0, Prev: v36 7 0, Up: History<2> + +9.108 v36.6.1 +============= + +09 Nov 2017 + + * #1132(1): Removed redundant and costly serialization/parsing step + in ‘EntryPoint.__init__’. + + * #844(2): ‘bdist_egg --exclude-source-files’ now tested and works on + Python 3. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1132 + + (2) https://github.com/pypa/setuptools/issues/844 + + +File: setuptools.info, Node: v36 6 0, Next: v36 5 0, Prev: v36 6 1, Up: History<2> + +9.109 v36.6.0 +============= + +12 Oct 2017 + + * #1143(1): Added ‘setuptools.build_meta’ module, an implementation + of PEP-517(2) for Setuptools-defined packages. + + * #1143(3): Added ‘dist_info’ command for producing dist_info + metadata. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1143 + + (2) https://www.python.org/dev/peps/pep-0517/ + + (3) https://github.com/pypa/setuptools/issues/1143 + + +File: setuptools.info, Node: v36 5 0, Next: v36 4 0, Prev: v36 6 0, Up: History<2> + +9.110 v36.5.0 +============= + +15 Sep 2017 + + * #170(1): When working with Mercurial checkouts, use + Windows-friendly syntax for suppressing output. + + * Inspired by #1134(2), performed substantial refactoring of + ‘pkg_resources.find_on_path’ to facilitate an optimization for + paths with many non-version entries. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/170 + + (2) https://github.com/pypa/setuptools/issues/1134 + + +File: setuptools.info, Node: v36 4 0, Next: v36 3 0, Prev: v36 5 0, Up: History<2> + +9.111 v36.4.0 +============= + +03 Sep 2017 + + * #1075(1): Add new ‘Description-Content-Type’ metadata field. See + here for documentation on how to use this field.(2) + + * #1068(3): Sort files and directories when building eggs for + deterministic order. + + * #196(4): Remove caching of easy_install command in fetch_build_egg. + Fixes issue where ‘pytest-runner-N.N’ would satisfy the + installation of ‘pytest’. + + * #1129(5): Fix working set dependencies handling when replacing + conflicting distributions (e.g. when using ‘setup_requires’ with a + conflicting transitive dependency, fix #1124(6)). + + * #1133(7): Improved handling of README files extensions and added + Markdown to the list of searched READMES. + + * #1135(8): Improve performance of pkg_resources import by not + invoking ‘access’ or ‘stat’ and using ‘os.listdir’ instead. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1075 + + (2) +https://packaging.python.org/specifications/#description-content-type + + (3) https://github.com/pypa/setuptools/issues/1068 + + (4) https://github.com/pypa/setuptools/issues/196 + + (5) https://github.com/pypa/setuptools/issues/1129 + + (6) https://github.com/pypa/setuptools/issues/1124 + + (7) https://github.com/pypa/setuptools/issues/1133 + + (8) https://github.com/pypa/setuptools/issues/1135 + + +File: setuptools.info, Node: v36 3 0, Next: v36 2 7, Prev: v36 4 0, Up: History<2> + +9.112 v36.3.0 +============= + +28 Aug 2017 + + * #1131(1): Make possible using several files within ‘file:’ + directive in metadata.long_description in ‘setup.cfg’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1131 + + +File: setuptools.info, Node: v36 2 7, Next: v36 2 6, Prev: v36 3 0, Up: History<2> + +9.113 v36.2.7 +============= + +02 Aug 2017 + + * fix #1105(1): Fix handling of requirements with environment markers + when declared in ‘setup.cfg’ (same treatment as for #1081(2)). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1105 + + (2) https://github.com/pypa/setuptools/issues/1081 + + +File: setuptools.info, Node: v36 2 6, Next: v36 2 5, Prev: v36 2 7, Up: History<2> + +9.114 v36.2.6 +============= + +31 Jul 2017 + + * #462(1): Don’t assume a directory is an egg by the ‘.egg’ extension + alone. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/462 + + +File: setuptools.info, Node: v36 2 5, Next: v36 2 4, Prev: v36 2 6, Up: History<2> + +9.115 v36.2.5 +============= + +30 Jul 2017 + + * #1093(1): Fix test command handler with extras_require. + + * #1112(2), #1091(3), #1115(4): Now using Trusty containers in Travis + for CI and CD. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1093 + + (2) https://github.com/pypa/setuptools/issues/1112 + + (3) https://github.com/pypa/setuptools/issues/1091 + + (4) https://github.com/pypa/setuptools/issues/1115 + + +File: setuptools.info, Node: v36 2 4, Next: v36 2 3, Prev: v36 2 5, Up: History<2> + +9.116 v36.2.4 +============= + +26 Jul 2017 + + * #1092(1): ‘pkg_resources’ now uses ‘inspect.getmro’ to resolve + classes in method resolution order. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1092 + + +File: setuptools.info, Node: v36 2 3, Next: v36 2 2, Prev: v36 2 4, Up: History<2> + +9.117 v36.2.3 +============= + +25 Jul 2017 + + * #1102(1): Restore behavior for empty extras. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1102 + + +File: setuptools.info, Node: v36 2 2, Next: v36 2 1, Prev: v36 2 3, Up: History<2> + +9.118 v36.2.2 +============= + +24 Jul 2017 + + * #1099(1): Revert commit a3ec721, restoring intended purpose of + extras as part of a requirement declaration. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1099 + + +File: setuptools.info, Node: v36 2 1, Next: v36 2 0, Prev: v36 2 2, Up: History<2> + +9.119 v36.2.1 +============= + +23 Jul 2017 + + * fix #1086(1) + + * fix #1087(2) + + * support extras specifiers in install_requires requirements + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1086 + + (2) https://github.com/pypa/setuptools/issues/1087 + + +File: setuptools.info, Node: v36 2 0, Next: v36 1 1, Prev: v36 2 1, Up: History<2> + +9.120 v36.2.0 +============= + +13 Jul 2017 + + * #1081(1): Environment markers indicated in ‘install_requires’ are + now processed and treated as nameless ‘extras_require’ with + markers, allowing their metadata in requires.txt to be correctly + generated. + + * #1053(2): Tagged commits are now released using Travis-CI build + stages, meaning releases depend on passing tests on all supported + Python versions (Linux) and not just the latest Python version. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1081 + + (2) https://github.com/pypa/setuptools/issues/1053 + + +File: setuptools.info, Node: v36 1 1, Next: v36 1 0, Prev: v36 2 0, Up: History<2> + +9.121 v36.1.1 +============= + +13 Jul 2017 + + * #1083(1): Correct ‘py31compat.makedirs’ to correctly honor + ‘exist_ok’ parameter. + + * #1083(2): Also use makedirs compatibility throughout setuptools. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1083 + + (2) https://github.com/pypa/setuptools/issues/1083 + + +File: setuptools.info, Node: v36 1 0, Next: v36 0 1, Prev: v36 1 1, Up: History<2> + +9.122 v36.1.0 +============= + +13 Jul 2017 + + * #1083(1): Avoid race condition on directory creation in + ‘pkg_resources.ensure_directory’. + + * Removed deprecation of and restored support for ‘upload_docs’ + command for sites other than PyPI. Only warehouse is dropping + support, but services like devpi(2) continue to support docs built + by setuptools’ plugins. See this comment(3) for more context on + the motivation for this change. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1083 + + (2) http://doc.devpi.net/latest/ + + (3) +https://bitbucket.org/hpk42/devpi/issues/388/support-rtd-model-for-building-uploading#comment-34292423 + + +File: setuptools.info, Node: v36 0 1, Next: v36 0 0, Prev: v36 1 0, Up: History<2> + +9.123 v36.0.1 +============= + +01 Jun 2017 + + * #1042(1): Fix import in py27compat module that still referenced six + directly, rather than through the externs module (vendored packages + hook). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1042 + + +File: setuptools.info, Node: v36 0 0, Next: v35 0 2, Prev: v36 0 1, Up: History<2> + +9.124 v36.0.0 +============= + +30 May 2017 + + * #980(1) and others: Once again, Setuptools vendors all of its + dependencies. It seems to be the case that in the Python + ecosystem, all build tools must run without any dependencies + (build, runtime, or otherwise). At such a point that a mechanism + exists that allows build tools to have dependencies, Setuptools + will adopt it. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/980 + + +File: setuptools.info, Node: v35 0 2, Next: v35 0 1, Prev: v36 0 0, Up: History<2> + +9.125 v35.0.2 +============= + +27 Apr 2017 + + * #1015(1): Fix test failures on Python 3.7. + + * #1024(2): Add workaround for Jython #2581(3) in monkey module. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1015 + + (2) https://github.com/pypa/setuptools/issues/1024 + + (3) http://bugs.jython.org/issue2581 + + +File: setuptools.info, Node: v35 0 1, Next: v35 0 0, Prev: v35 0 2, Up: History<2> + +9.126 v35.0.1 +============= + +18 Apr 2017 + + * #992(1): Revert change introduced in v34.4.1, now considered + invalid. + + * #1016(2): Revert change introduced in v35.0.0 per #1014(3), + referencing #436(4). The approach had unintended consequences, + causing sdist installs to be missing files. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/992 + + (2) https://github.com/pypa/setuptools/issues/1016 + + (3) https://github.com/pypa/setuptools/issues/1014 + + (4) https://github.com/pypa/setuptools/issues/436 + + +File: setuptools.info, Node: v35 0 0, Next: v34 4 1, Prev: v35 0 1, Up: History<2> + +9.127 v35.0.0 +============= + +15 Apr 2017 + + * #436(1): In egg_info.manifest_maker, no longer read the file list + from the manifest file, and instead re-build it on each build. In + this way, files removed from the specification will not linger in + the manifest. As a result, any files manually added to the + manifest will be removed on subsequent egg_info invocations. No + projects should be manually adding files to the manifest and should + instead use MANIFEST.in or SCM file finders to force inclusion of + files in the manifest. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/436 + + +File: setuptools.info, Node: v34 4 1, Next: v34 4 0, Prev: v35 0 0, Up: History<2> + +9.128 v34.4.1 +============= + +10 Apr 2017 + + * #1008(1): In MSVC support, use always the last version available + for Windows SDK and UCRT SDK. + + * #1008(2): In MSVC support, fix “vcruntime140.dll” returned path + with Visual Studio 2017. + + * #992(3): In msvc.msvc9_query_vcvarsall, ensure the returned dicts + have str values and not Unicode for compatibility with os.environ. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1008 + + (2) https://github.com/pypa/setuptools/issues/1008 + + (3) https://github.com/pypa/setuptools/issues/992 + + +File: setuptools.info, Node: v34 4 0, Next: v34 3 3, Prev: v34 4 1, Up: History<2> + +9.129 v34.4.0 +============= + +07 Apr 2017 + + * #995(1): In MSVC support, add support for “Microsoft Visual Studio + 2017” and “Microsoft Visual Studio Build Tools 2017”. + + * #999(2) via #1007(3): Extend support for declarative package config + in a setup.cfg file to include the options ‘python_requires’ and + ‘py_modules’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/995 + + (2) https://github.com/pypa/setuptools/issues/999 + + (3) https://github.com/pypa/setuptools/issues/1007 + + +File: setuptools.info, Node: v34 3 3, Next: v34 3 2, Prev: v34 4 0, Up: History<2> + +9.130 v34.3.3 +============= + +26 Mar 2017 + + * #967(1) (and #997(2)): Explicitly import submodules of packaging to + account for environments where the imports of those submodules is + not implied by other behavior. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/967 + + (2) https://github.com/pypa/setuptools/issues/997 + + +File: setuptools.info, Node: v34 3 2, Next: v34 3 1, Prev: v34 3 3, Up: History<2> + +9.131 v34.3.2 +============= + +11 Mar 2017 + + * #993(1): Fix documentation upload by correcting rendering of + content-type in _build_multipart on Python 3. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/993 + + +File: setuptools.info, Node: v34 3 1, Next: v34 3 0, Prev: v34 3 2, Up: History<2> + +9.132 v34.3.1 +============= + +02 Mar 2017 + + * #988(1): Trap ‘os.unlink’ same as ‘os.remove’ in ‘auto_chmod’ error + handler. + + * #983(2): Fixes to invalid escape sequence deprecations on Python + 3.6. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/988 + + (2) https://github.com/pypa/setuptools/issues/983 + + +File: setuptools.info, Node: v34 3 0, Next: v34 2 0, Prev: v34 3 1, Up: History<2> + +9.133 v34.3.0 +============= + +23 Feb 2017 + + * #941(1): In the upload command, if the username is blank, default + to ‘getpass.getuser()’. + + * #971(2): Correct distutils findall monkeypatch to match appropriate + versions (namely Python 3.4.6). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/941 + + (2) https://github.com/pypa/setuptools/issues/971 + + +File: setuptools.info, Node: v34 2 0, Next: v34 1 1, Prev: v34 3 0, Up: History<2> + +9.134 v34.2.0 +============= + +12 Feb 2017 + + * #966(1): Add support for reading dist-info metadata and thus + locating Distributions from zip files. + + * #968(2): Allow ‘+’ and ‘!’ in egg fragments so that it can take + package names that contain PEP 440(3) conforming version + specifiers. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/966 + + (2) https://github.com/pypa/setuptools/issues/968 + + (3) https://www.python.org/dev/peps/pep-0440/ + + +File: setuptools.info, Node: v34 1 1, Next: v34 1 0, Prev: v34 2 0, Up: History<2> + +9.135 v34.1.1 +============= + +03 Feb 2017 + + * #953(1): More aggressively employ the compatibility issue + originally added in #706(2). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/953 + + (2) https://github.com/pypa/setuptools/issues/706 + + +File: setuptools.info, Node: v34 1 0, Next: v34 0 3, Prev: v34 1 1, Up: History<2> + +9.136 v34.1.0 +============= + +28 Jan 2017 + + * #930(1): ‘build_info’ now accepts two new parameters to optimize + and customize the building of C libraries. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/930 + + +File: setuptools.info, Node: v34 0 3, Next: v34 0 2, Prev: v34 1 0, Up: History<2> + +9.137 v34.0.3 +============= + +28 Jan 2017 + + * #947(1): Loosen restriction on the version of six required, + restoring compatibility with environments relying on six 1.6.0 and + later. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/947 + + +File: setuptools.info, Node: v34 0 2, Next: v34 0 1, Prev: v34 0 3, Up: History<2> + +9.138 v34.0.2 +============= + +24 Jan 2017 + + * #882(1): Ensure extras are honored when building the working set. + + * #913(2): Fix issue in develop if package directory has a trailing + slash. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/882 + + (2) https://github.com/pypa/setuptools/issues/913 + + +File: setuptools.info, Node: v34 0 1, Next: v34 0 0, Prev: v34 0 2, Up: History<2> + +9.139 v34.0.1 +============= + +23 Jan 2017 + + * #935(1): Fix glob syntax in graft. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/935 + + +File: setuptools.info, Node: v34 0 0, Next: v33 1 1, Prev: v34 0 1, Up: History<2> + +9.140 v34.0.0 +============= + +23 Jan 2017 + + * #581(1): Instead of vendoring the growing list of dependencies that + Setuptools requires to function, Setuptools now requires these + dependencies just like any other project. Unlike other projects, + however, Setuptools cannot rely on ‘setup_requires’ to demand the + dependencies it needs to install because its own machinery would be + necessary to pull those dependencies if not present (a + bootstrapping problem). As a result, Setuptools no longer supports + self upgrade or installation in the general case. Instead, users + are directed to use pip to install and upgrade using the ‘wheel’ + distributions of setuptools. + + Users are welcome to contrive other means to install or upgrade + Setuptools using other means, such as pre-installing the Setuptools + dependencies with pip or a bespoke bootstrap tool, but such usage + is not recommended and is not supported. + + As discovered in #940(2), not all versions of pip will successfully + install Setuptools from its pre-built wheel. If you encounter + issues with “No module named six” or “No module named packaging”, + especially following a line “Running setup.py egg_info for package + setuptools”, then your pip is not new enough. + + There’s an additional issue in pip where setuptools is upgraded + concurrently with other source packages, described in pip #4253(3). + The proposed workaround is to always upgrade Setuptools first prior + to upgrading other packages that would upgrade Setuptools. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/581 + + (2) https://github.com/pypa/setuptools/issues/940 + + (3) https://github.com/pypa/setuptools/issues/4253 + + +File: setuptools.info, Node: v33 1 1, Next: v33 1 0, Prev: v34 0 0, Up: History<2> + +9.141 v33.1.1 +============= + +16 Jan 2017 + + * #921(1): Correct issue where certifi fallback not being reached on + Windows. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/921 + + +File: setuptools.info, Node: v33 1 0, Next: v33 0 0, Prev: v33 1 1, Up: History<2> + +9.142 v33.1.0 +============= + +15 Jan 2017 + +Installation via pip, as indicated in the Python Packaging User’s +Guide(1), is the officially-supported mechanism for installing +Setuptools, and this recommendation is now explicit in the much more +concise README. + +Other edits and tweaks were made to the documentation. The codebase is +unchanged. + + ---------- Footnotes ---------- + + (1) https://packaging.python.org/installing/ + + +File: setuptools.info, Node: v33 0 0, Next: v32 3 1, Prev: v33 1 0, Up: History<2> + +9.143 v33.0.0 +============= + +01 Jan 2017 + + * #619(1): Removed support for the ‘tag_svn_revision’ distribution + option. If Subversion tagging support is still desired, consider + adding the functionality to setuptools_svn in setuptools_svn #2(2). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/619 + + (2) https://github.com/jaraco/setuptools_svn/issues/2 + + +File: setuptools.info, Node: v32 3 1, Next: v32 3 0, Prev: v33 0 0, Up: History<2> + +9.144 v32.3.1 +============= + +28 Dec 2016 + + * #866(1): Use ‘dis.Bytecode’ on Python 3.4 and later in + ‘setuptools.depends’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/866 + + +File: setuptools.info, Node: v32 3 0, Next: v32 2 0, Prev: v32 3 1, Up: History<2> + +9.145 v32.3.0 +============= + +24 Dec 2016 + + * #889(1): Backport proposed fix for disabling interpolation in + distutils.Distribution.parse_config_files. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/889 + + +File: setuptools.info, Node: v32 2 0, Next: v32 1 3, Prev: v32 3 0, Up: History<2> + +9.146 v32.2.0 +============= + +22 Dec 2016 + + * #884(1): Restore support for running the tests under + pytest-runner(2) by ensuring that PYTHONPATH is honored in tests + invoking a subprocess. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/884 + + (2) https://github.com/pytest-dev/pytest-runner + + +File: setuptools.info, Node: v32 1 3, Next: v32 1 2, Prev: v32 2 0, Up: History<2> + +9.147 v32.1.3 +============= + +21 Dec 2016 + + * #706(1): Add rmtree compatibility shim for environments where + rmtree fails when passed a unicode string. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/706 + + +File: setuptools.info, Node: v32 1 2, Next: v32 1 1, Prev: v32 1 3, Up: History<2> + +9.148 v32.1.2 +============= + +18 Dec 2016 + + * #893(1): Only release sdist in zip format as warehouse now + disallows releasing two different formats. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/893 + + +File: setuptools.info, Node: v32 1 1, Next: v32 1 0, Prev: v32 1 2, Up: History<2> + +9.149 v32.1.1 +============= + +18 Dec 2016 + + * #704(1): More selectively ensure that ‘rmtree’ is not invoked with + a byte string, enabling it to remove files that are non-ascii, even + on Python 2. + + * #712(2): In ‘sandbox.run_setup’, ensure that ‘__file__’ is always a + ‘str’, modeling the behavior observed by the interpreter when + invoking scripts and modules. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/704 + + (2) https://github.com/pypa/setuptools/issues/712 + + +File: setuptools.info, Node: v32 1 0, Next: v32 0 0, Prev: v32 1 1, Up: History<2> + +9.150 v32.1.0 +============= + +16 Dec 2016 + + * #891(1): In ‘test’ command on test failure, raise DistutilsError, + suppression invocation of subsequent commands. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/891 + + +File: setuptools.info, Node: v32 0 0, Next: v31 0 1, Prev: v32 1 0, Up: History<2> + +9.151 v32.0.0 +============= + +14 Dec 2016 + + * #890(1): Revert #849(2). ‘global-exclude .foo’ will not match all + ‘*.foo’ files any more. Package authors must add an explicit + wildcard, such as ‘global-exclude *.foo’, to match all ‘.foo’ + files. See #886(3), #849(4). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/890 + + (2) https://github.com/pypa/setuptools/issues/849 + + (3) https://github.com/pypa/setuptools/issues/886 + + (4) https://github.com/pypa/setuptools/issues/849 + + +File: setuptools.info, Node: v31 0 1, Next: v31 0 0, Prev: v32 0 0, Up: History<2> + +9.152 v31.0.1 +============= + +14 Dec 2016 + + * #885(1): Fix regression where ‘pkg_resources._rebuild_mod_path’ + would fail when a namespace package’s ‘__path__’ was not a list + with a sort attribute. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/885 + + +File: setuptools.info, Node: v31 0 0, Next: v30 4 0, Prev: v31 0 1, Up: History<2> + +9.153 v31.0.0 +============= + +11 Dec 2016 + + * #250(1): Install ‘-nspkg.pth’ files for packages installed with + ‘setup.py develop’. These .pth files allow namespace packages + installed by pip or develop to co-mingle. This change required the + removal of the change for #805(2) and pip #1924(3), introduced in + 28.3.0 and implicated in #870(4), but means that namespace packages + not in a site packages directory will no longer work on Python + earlier than 3.5, whereas before they would work on Python not + earlier than 3.3. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/250 + + (2) https://github.com/pypa/setuptools/issues/805 + + (3) https://github.com/pypa/setuptools/issues/1924 + + (4) https://github.com/pypa/setuptools/issues/870 + + +File: setuptools.info, Node: v30 4 0, Next: v30 3 0, Prev: v31 0 0, Up: History<2> + +9.154 v30.4.0 +============= + +10 Dec 2016 + + * #879(1): For declarative config: + + - read_configuration() now accepts ignore_option_errors + argument. This allows scraping tools to read metadata without + a need to download entire packages. E.g. we can gather some + stats right from GitHub repos just by downloading setup.cfg. + + - packages find: directive now supports fine tuning from a + subsection. The same arguments as for find() are accepted. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/879 + + +File: setuptools.info, Node: v30 3 0, Next: v30 2 1, Prev: v30 4 0, Up: History<2> + +9.155 v30.3.0 +============= + +08 Dec 2016 + + * #394(1) via #862(2): Added support for declarative package config + in a setup.cfg file(3). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/394 + + (2) https://github.com/pypa/setuptools/issues/862 + + (3) +https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files + + +File: setuptools.info, Node: v30 2 1, Next: v30 2 0, Prev: v30 3 0, Up: History<2> + +9.156 v30.2.1 +============= + +08 Dec 2016 + + * #850(1): In test command, invoke unittest.main with indication not + to exit the process. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/850 + + +File: setuptools.info, Node: v30 2 0, Next: v30 1 0, Prev: v30 2 1, Up: History<2> + +9.157 v30.2.0 +============= + +04 Dec 2016 + + * #854(1): Bump to vendored Packaging 16.8(2). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/854 + + (2) https://github.com/pypa/packaging/blob/16.8/CHANGELOG.rst + + +File: setuptools.info, Node: v30 1 0, Next: v30 0 0, Prev: v30 2 0, Up: History<2> + +9.158 v30.1.0 +============= + +03 Dec 2016 + + * #846(1): Also trap ‘socket.error’ when opening URLs in + package_index. + + * #849(2): Manifest processing now matches the filename pattern + anywhere in the filename and not just at the start. Restores + behavior found prior to 28.5.0. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/846 + + (2) https://github.com/pypa/setuptools/issues/849 + + +File: setuptools.info, Node: v30 0 0, Next: v29 0 1, Prev: v30 1 0, Up: History<2> + +9.159 v30.0.0 +============= + +01 Dec 2016 + + * #864(1): Drop support for Python 3.2. Systems requiring Python 3.2 + support must use ‘setuptools < 30’. + + * #825(2): Suppress warnings for single files. + + * #830(3) via #843(4): Once again restored inclusion of data files to + sdists, but now trap TypeError caused by techniques employed rjsmin + and similar. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/864 + + (2) https://github.com/pypa/setuptools/issues/825 + + (3) https://github.com/pypa/setuptools/issues/830 + + (4) https://github.com/pypa/setuptools/issues/843 + + +File: setuptools.info, Node: v29 0 1, Next: v29 0 0, Prev: v30 0 0, Up: History<2> + +9.160 v29.0.1 +============= + +26 Nov 2016 + + * #861(1): Re-release of v29.0.1 with the executable script launchers + bundled. Now, launchers are included by default and users that + want to disable this behavior must set the environment variable + ‘SETUPTOOLS_INSTALL_WINDOWS_SPECIFIC_FILES’ to a false value like + “false” or “0”. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/861 + + +File: setuptools.info, Node: v29 0 0, Next: v28 8 0, Prev: v29 0 1, Up: History<2> + +9.161 v29.0.0 +============= + +25 Nov 2016 + + * #841(1): Drop special exception for packages invoking win32com + during the build/install process. See Distribute #118(2) for + history. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/841 + + (2) https://bitbucket.org/tarek/distribute/issue/118 + + +File: setuptools.info, Node: v28 8 0, Next: v28 7 1, Prev: v29 0 0, Up: History<2> + +9.162 v28.8.0 +============= + +04 Nov 2016 + + * #629(1): Per the discussion, refine the sorting to use version + value order for more accurate detection of the latest available + version when scanning for packages. See also #829(2). + + * #837(3): Rely on the config var “SO” for Python 3.3.0 only when + determining the ext filename. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/629 + + (2) https://github.com/pypa/setuptools/issues/829 + + (3) https://github.com/pypa/setuptools/issues/837 + + +File: setuptools.info, Node: v28 7 1, Next: v28 7 0, Prev: v28 8 0, Up: History<2> + +9.163 v28.7.1 +============= + +29 Oct 2016 + + * #827(1): Update PyPI root for dependency links. + + * #833(2): Backed out changes from #830(3) as the implementation + seems to have problems in some cases. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/827 + + (2) https://github.com/pypa/setuptools/issues/833 + + (3) https://github.com/pypa/setuptools/issues/830 + + +File: setuptools.info, Node: v28 7 0, Next: v28 6 1, Prev: v28 7 1, Up: History<2> + +9.164 v28.7.0 +============= + +28 Oct 2016 + + * #832(1): Moved much of the namespace package handling functionality + into a separate module for re-use in something like #789(2). + + * #830(3): ‘sdist’ command no longer suppresses the inclusion of data + files, re-aligning with the expectation of distutils and addressing + #274(4) and #521(5). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/832 + + (2) https://github.com/pypa/setuptools/issues/789 + + (3) https://github.com/pypa/setuptools/issues/830 + + (4) https://github.com/pypa/setuptools/issues/274 + + (5) https://github.com/pypa/setuptools/issues/521 + + +File: setuptools.info, Node: v28 6 1, Next: v28 6 0, Prev: v28 7 0, Up: History<2> + +9.165 v28.6.1 +============= + +19 Oct 2016 + + * #816(1): Fix manifest file list order in tests. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/816 + + +File: setuptools.info, Node: v28 6 0, Next: v28 5 0, Prev: v28 6 1, Up: History<2> + +9.166 v28.6.0 +============= + +16 Oct 2016 + + * #629(1): When scanning for packages, ‘pkg_resources’ now ignores + empty egg-info directories and gives precedence to packages whose + versions are lexicographically greatest, a rough approximation for + preferring the latest available version. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/629 + + +File: setuptools.info, Node: v28 5 0, Next: v28 4 0, Prev: v28 6 0, Up: History<2> + +9.167 v28.5.0 +============= + +14 Oct 2016 + + * #810(1): Tests are now invoked with tox and not setup.py test. + + * #249(2) and #450(3) via #764(4): Avoid scanning the whole tree when + building the manifest. Also fixes a long-standing bug where + patterns in ‘MANIFEST.in’ had implicit wildcard matching. This + caused ‘global-exclude .foo’ to exclude all ‘*.foo’ files, but also + ‘global-exclude bar.py’ to exclude ‘foo_bar.py’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/810 + + (2) https://github.com/pypa/setuptools/issues/249 + + (3) https://github.com/pypa/setuptools/issues/450 + + (4) https://github.com/pypa/setuptools/issues/764 + + +File: setuptools.info, Node: v28 4 0, Next: v28 3 0, Prev: v28 5 0, Up: History<2> + +9.168 v28.4.0 +============= + +14 Oct 2016 + + * #732(1): Now extras with a hyphen are honored per PEP 426(2). + + * #811(3): Update to pyparsing 2.1.10. + + * Updated ‘setuptools.command.sdist’ to re-use most of the + functionality directly from ‘distutils.command.sdist’ for the + ‘add_defaults’ method with strategic overrides. See #750(4) for + rationale. + + * #760(5) via #762(6): Look for certificate bundle where SUSE Linux + typically presents it. Use ‘certifi.where()’ to locate the bundle. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/732 + + (2) https://www.python.org/dev/peps/pep-0426/ + + (3) https://github.com/pypa/setuptools/issues/811 + + (4) https://github.com/pypa/setuptools/issues/750 + + (5) https://github.com/pypa/setuptools/issues/760 + + (6) https://github.com/pypa/setuptools/issues/762 + + +File: setuptools.info, Node: v28 3 0, Next: v28 1 0, Prev: v28 4 0, Up: History<2> + +9.169 v28.3.0 +============= + +07 Oct 2016 + + * #809(1): In ‘find_packages()’, restore support for excluding a + parent package without excluding a child package. + + * #805(2): Disable ‘-nspkg.pth’ behavior on Python 3.3+ where + PEP-420(3) functionality is adequate. Fixes pip #1924(4). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/809 + + (2) https://github.com/pypa/setuptools/issues/805 + + (3) https://www.python.org/dev/peps/pep-0420/ + + (4) https://github.com/pypa/setuptools/issues/1924 + + +File: setuptools.info, Node: v28 1 0, Next: v28 0 0, Prev: v28 3 0, Up: History<2> + +9.170 v28.1.0 +============= + +01 Oct 2016 + + * #803(1): Bump certifi to 2016.9.26. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/803 + + +File: setuptools.info, Node: v28 0 0, Next: v27 3 1, Prev: v28 1 0, Up: History<2> + +9.171 v28.0.0 +============= + +27 Sep 2016 + + * #733(1): Do not search excluded directories for packages. This + introduced a backwards incompatible change in ‘find_packages()’ so + that ‘find_packages(exclude=['foo']) == []’, excluding subpackages + of ‘foo’. Previously, ‘find_packages(exclude=['foo']) == + ['foo.bar']’, even though the parent ‘foo’ package was excluded. + + * #795(2): Bump certifi. + + * #719(3): Suppress decoding errors and instead log a warning when + metadata cannot be decoded. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/733 + + (2) https://github.com/pypa/setuptools/issues/795 + + (3) https://github.com/pypa/setuptools/issues/719 + + +File: setuptools.info, Node: v27 3 1, Next: v27 3 0, Prev: v28 0 0, Up: History<2> + +9.172 v27.3.1 +============= + +27 Sep 2016 + + * #790(1): In MSVC monkeypatching, explicitly patch each function by + name in the target module instead of inferring the module from the + function’s ‘__module__’. Improves compatibility with other + packages that might have previously patched distutils functions + (i.e. NumPy). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/790 + + +File: setuptools.info, Node: v27 3 0, Next: v27 2 0, Prev: v27 3 1, Up: History<2> + +9.173 v27.3.0 +============= + +20 Sep 2016 + + * #794(1): In test command, add installed eggs to PYTHONPATH when + invoking tests so that subprocesses will also have the dependencies + available. Fixes tox 330(2). + + * #795(3): Update vendored pyparsing 2.1.9. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/794 + + (2) https://github.com/tox-dev/tox/issues/330 + + (3) https://github.com/pypa/setuptools/issues/795 + + +File: setuptools.info, Node: v27 2 0, Next: v27 1 2, Prev: v27 3 0, Up: History<2> + +9.174 v27.2.0 +============= + +14 Sep 2016 + + * #520(1) and #513(2): Suppress ValueErrors in + fixup_namespace_packages when lookup fails. + + * Nicer, more consistent interfaces for msvc monkeypatching. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/520 + + (2) https://github.com/pypa/setuptools/issues/513 + + +File: setuptools.info, Node: v27 1 2, Next: v27 1 1, Prev: v27 2 0, Up: History<2> + +9.175 v27.1.2 +============= + +09 Sep 2016 + + * #779(1) via #781(2): Fix circular import. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/779 + + (2) https://github.com/pypa/setuptools/issues/781 + + +File: setuptools.info, Node: v27 1 1, Next: v27 1 0, Prev: v27 1 2, Up: History<2> + +9.176 v27.1.1 +============= + +09 Sep 2016 + + * #778(1): Fix MSVC monkeypatching. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/778 + + +File: setuptools.info, Node: v27 1 0, Next: v27 0 0, Prev: v27 1 1, Up: History<2> + +9.177 v27.1.0 +============= + +09 Sep 2016 + + * Introduce the (private) ‘monkey’ module to encapsulate the + distutils monkeypatching behavior. + + +File: setuptools.info, Node: v27 0 0, Next: v26 1 1, Prev: v27 1 0, Up: History<2> + +9.178 v27.0.0 +============= + +09 Sep 2016 + + * Now use Warehouse by default for ‘upload’, patching + ‘distutils.config.PyPIRCCommand’ to affect default behavior. + + Any config in .pypirc should be updated to replace + + ‘https://pypi.python.org/pypi/’ + + with + + ‘https://upload.pypi.org/legacy/’ + + Similarly, any passwords stored in the keyring should be updated to + use this new value for “system”. + + The ‘upload_docs’ command will continue to use the python.org site, + but the command is now deprecated. Users are urged to use Read The + Docs instead. + + * #776(1): Use EXT_SUFFIX for py_limited_api renaming. + + * #774(2) and #775(3): Use LegacyVersion from packaging when + detecting numpy versions. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/776 + + (2) https://github.com/pypa/setuptools/issues/774 + + (3) https://github.com/pypa/setuptools/issues/775 + + +File: setuptools.info, Node: v26 1 1, Next: v26 1 0, Prev: v27 0 0, Up: History<2> + +9.179 v26.1.1 +============= + +29 Aug 2016 + + * Re-release of 26.1.0 with pytest pinned to allow for automated + deployment and thus proper packaging environment variables, fixing + issues with missing executable launchers. + + +File: setuptools.info, Node: v26 1 0, Next: v26 0 0, Prev: v26 1 1, Up: History<2> + +9.180 v26.1.0 +============= + +28 Aug 2016 + + * #763(1): ‘pkg_resources.get_default_cache’ now defers to the + appdirs project(2) to resolve the cache directory. Adds a vendored + dependency on appdirs to pkg_resources. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/763 + + (2) https://pypi.org/project/appdirs + + +File: setuptools.info, Node: v26 0 0, Next: v25 4 0, Prev: v26 1 0, Up: History<2> + +9.181 v26.0.0 +============= + +20 Aug 2016 + + * #748(1): By default, sdists are now produced in gzipped tarfile + format by default on all platforms, adding forward compatibility + for the same behavior in Python 3.6 (See Python #27819(2)). + + * #459(3) via #736(4): On Windows with script launchers, sys.argv[0] + now reflects the name of the entry point, consistent with the + behavior in distlib and pip wrappers. + + * #752(5) via #753(6): When indicating ‘py_limited_api’ to Extension, + it must be passed as a keyword argument. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/748 + + (2) http://bugs.python.org/issue27819 + + (3) https://github.com/pypa/setuptools/issues/459 + + (4) https://github.com/pypa/setuptools/issues/736 + + (5) https://github.com/pypa/setuptools/issues/752 + + (6) https://github.com/pypa/setuptools/issues/753 + + +File: setuptools.info, Node: v25 4 0, Next: v25 3 0, Prev: v26 0 0, Up: History<2> + +9.182 v25.4.0 +============= + +19 Aug 2016 + + * Add Extension(py_limited_api=True). When set to a truthy value, + that extension gets a filename appropriate for code using + Py_LIMITED_API. When used correctly this allows a single compiled + extension to work on all future versions of CPython 3. The + py_limited_api argument only controls the filename. To be + compatible with multiple versions of Python 3, the C extension will + also need to set -DPy_LIMITED_API=… and be modified to use only the + functions in the limited API. + + +File: setuptools.info, Node: v25 3 0, Next: v25 2 0, Prev: v25 4 0, Up: History<2> + +9.183 v25.3.0 +============= + +19 Aug 2016 + + * #739(1) Fix unquoted libpaths by fixing compatibility between + ‘numpy.distutils’ and ‘distutils._msvccompiler’ for numpy < 1.11.2 + (Fix issue #728(2), error also fixed in Numpy). + + * #731(3): Bump certifi. + + * Style updates. See #740(4), #741(5), #743(6), #744(7), #742(8), + #747(9). + + * #735(10): include license file. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/739 + + (2) https://github.com/pypa/setuptools/issues/728 + + (3) https://github.com/pypa/setuptools/issues/731 + + (4) https://github.com/pypa/setuptools/issues/740 + + (5) https://github.com/pypa/setuptools/issues/741 + + (6) https://github.com/pypa/setuptools/issues/743 + + (7) https://github.com/pypa/setuptools/issues/744 + + (8) https://github.com/pypa/setuptools/issues/742 + + (9) https://github.com/pypa/setuptools/issues/747 + + (10) https://github.com/pypa/setuptools/issues/735 + + +File: setuptools.info, Node: v25 2 0, Next: v25 1 6, Prev: v25 3 0, Up: History<2> + +9.184 v25.2.0 +============= + +12 Aug 2016 + + * #612(1) via #730(2): Add a LICENSE file which needs to be provided + by the terms of the MIT license. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/612 + + (2) https://github.com/pypa/setuptools/issues/730 + + +File: setuptools.info, Node: v25 1 6, Next: v25 1 5, Prev: v25 2 0, Up: History<2> + +9.185 v25.1.6 +============= + +05 Aug 2016 + + * #725(1): revert ‘library_dir_option’ patch (Error is related to + ‘numpy.distutils’ and make errors on non Numpy users). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/725 + + +File: setuptools.info, Node: v25 1 5, Next: v25 1 4, Prev: v25 1 6, Up: History<2> + +9.186 v25.1.5 +============= + +05 Aug 2016 + + * #720(1) + + * #723(2): Improve patch for ‘library_dir_option’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/720 + + (2) https://github.com/pypa/setuptools/issues/723 + + +File: setuptools.info, Node: v25 1 4, Next: v25 1 3, Prev: v25 1 5, Up: History<2> + +9.187 v25.1.4 +============= + +04 Aug 2016 + + * #717(1) + + * #713(2) + + * #707(3): Fix Python 2 compatibility for MSVC by catching errors + properly. + + * #715(4): Fix unquoted libpaths by patching ‘library_dir_option’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/717 + + (2) https://github.com/pypa/setuptools/issues/713 + + (3) https://github.com/pypa/setuptools/issues/707 + + (4) https://github.com/pypa/setuptools/issues/715 + + +File: setuptools.info, Node: v25 1 3, Next: v25 1 2, Prev: v25 1 4, Up: History<2> + +9.188 v25.1.3 +============= + +02 Aug 2016 + + * #714(1) and #704(2): Revert fix as it breaks other components + downstream that can’t handle unicode. See #709(3), #710(4), and + #712(5). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/714 + + (2) https://github.com/pypa/setuptools/issues/704 + + (3) https://github.com/pypa/setuptools/issues/709 + + (4) https://github.com/pypa/setuptools/issues/710 + + (5) https://github.com/pypa/setuptools/issues/712 + + +File: setuptools.info, Node: v25 1 2, Next: v25 1 1, Prev: v25 1 3, Up: History<2> + +9.189 v25.1.2 +============= + +01 Aug 2016 + + * #704(1): Fix errors when installing a zip sdist that contained + files named with non-ascii characters on Windows would crash the + install when it attempted to clean up the build. + + * #646(2): MSVC compatibility - catch errors properly in + RegistryInfo.lookup. + + * #702(3): Prevent UnboundLocalError when initial working_set is + empty. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/704 + + (2) https://github.com/pypa/setuptools/issues/646 + + (3) https://github.com/pypa/setuptools/issues/702 + + +File: setuptools.info, Node: v25 1 1, Next: v25 1 0, Prev: v25 1 2, Up: History<2> + +9.190 v25.1.1 +============= + +28 Jul 2016 + + * #686(1): Fix issue in sys.path ordering by pkg_resources when + rewrite technique is “raw”. + + * #699(2): Fix typo in msvc support. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/686 + + (2) https://github.com/pypa/setuptools/issues/699 + + +File: setuptools.info, Node: v25 1 0, Next: v25 0 2, Prev: v25 1 1, Up: History<2> + +9.191 v25.1.0 +============= + +25 Jul 2016 + + * #609(1): Setuptools will now try to download a distribution from + the next possible download location if the first download fails. + This means you can now specify multiple links as ‘dependency_links’ + and all links will be tried until a working download link is + encountered. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/609 + + +File: setuptools.info, Node: v25 0 2, Next: v25 0 1, Prev: v25 1 0, Up: History<2> + +9.192 v25.0.2 +============= + +25 Jul 2016 + + * #688(1): Fix AttributeError in setup.py when invoked not from the + current directory. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/688 + + +File: setuptools.info, Node: v25 0 1, Next: v25 0 0, Prev: v25 0 2, Up: History<2> + +9.193 v25.0.1 +============= + +25 Jul 2016 + + * Cleanup of setup.py script. + + * Fixed documentation builders by allowing setup.py to be imported + without having bootstrapped the metadata. + + * More style cleanup. See #677(1), #678(2), #679(3), #681(4), + #685(5). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/677 + + (2) https://github.com/pypa/setuptools/issues/678 + + (3) https://github.com/pypa/setuptools/issues/679 + + (4) https://github.com/pypa/setuptools/issues/681 + + (5) https://github.com/pypa/setuptools/issues/685 + + +File: setuptools.info, Node: v25 0 0, Next: v24 3 1, Prev: v25 0 1, Up: History<2> + +9.194 v25.0.0 +============= + +23 Jul 2016 + + * #674(1): Default ‘sys.path’ manipulation by easy-install.pth is now + “raw”, meaning that when writing easy-install.pth during any + install operation, the ‘sys.path’ will not be rewritten and will no + longer give preference to easy_installed packages. + + To retain the old behavior when using any easy_install operation + (including ‘setup.py install’ when setuptools is present), set the + environment variable: + + SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite + + This project hopes that that few if any environments find it + necessary to retain the old behavior, and intends to drop support + for it altogether in a future release. Please report any relevant + concerns in the ticket for this change. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/674 + + +File: setuptools.info, Node: v24 3 1, Next: v24 3 0, Prev: v25 0 0, Up: History<2> + +9.195 v24.3.1 +============= + +23 Jul 2016 + + * #398(1): Fix shebang handling on Windows in script headers where + spaces in ‘sys.executable’ would produce an improperly-formatted + shebang header, introduced in 12.0 with the fix for #188(2). + + * #663(3), #670(4): More style updates. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/398 + + (2) https://github.com/pypa/setuptools/issues/188 + + (3) https://github.com/pypa/setuptools/issues/663 + + (4) https://github.com/pypa/setuptools/issues/670 + + +File: setuptools.info, Node: v24 3 0, Next: v24 2 1, Prev: v24 3 1, Up: History<2> + +9.196 v24.3.0 +============= + +21 Jul 2016 + + * #516(1): Disable ‘os.link’ to avoid hard linking in + ‘sdist.make_distribution’, avoiding errors on systems that support + hard links but not on the file system in which the build is + occurring. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/516 + + +File: setuptools.info, Node: v24 2 1, Next: v24 2 0, Prev: v24 3 0, Up: History<2> + +9.197 v24.2.1 +============= + +21 Jul 2016 + + * #667(1): Update Metadata-Version to 1.2 when ‘python_requires’ is + supplied. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/667 + + +File: setuptools.info, Node: v24 2 0, Next: v24 1 1, Prev: v24 2 1, Up: History<2> + +9.198 v24.2.0 +============= + +20 Jul 2016 + + * #631(1): Add support for ‘python_requires’ keyword. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/631 + + +File: setuptools.info, Node: v24 1 1, Next: v24 1 0, Prev: v24 2 0, Up: History<2> + +9.199 v24.1.1 +============= + +20 Jul 2016 + + * More style updates. See #660(1), #661(2), #641(3). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/660 + + (2) https://github.com/pypa/setuptools/issues/661 + + (3) https://github.com/pypa/setuptools/issues/641 + + +File: setuptools.info, Node: v24 1 0, Next: v24 0 3, Prev: v24 1 1, Up: History<2> + +9.200 v24.1.0 +============= + +20 Jul 2016 + + * #659(1): ‘setup.py’ now will fail fast and with a helpful error + message when the necessary metadata is missing. + + * More style updates. See #656(2), #635(3), #640(4), #644(5), + #650(6), #652(7), and #655(8). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/659 + + (2) https://github.com/pypa/setuptools/issues/656 + + (3) https://github.com/pypa/setuptools/issues/635 + + (4) https://github.com/pypa/setuptools/issues/640 + + (5) https://github.com/pypa/setuptools/issues/644 + + (6) https://github.com/pypa/setuptools/issues/650 + + (7) https://github.com/pypa/setuptools/issues/652 + + (8) https://github.com/pypa/setuptools/issues/655 + + +File: setuptools.info, Node: v24 0 3, Next: v24 0 2, Prev: v24 1 0, Up: History<2> + +9.201 v24.0.3 +============= + +14 Jul 2016 + + * Updated style in much of the codebase to match community + expectations. See #632(1), #633(2), #634(3), #637(4), #639(5), + #638(6), #642(7), #648(8). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/632 + + (2) https://github.com/pypa/setuptools/issues/633 + + (3) https://github.com/pypa/setuptools/issues/634 + + (4) https://github.com/pypa/setuptools/issues/637 + + (5) https://github.com/pypa/setuptools/issues/639 + + (6) https://github.com/pypa/setuptools/issues/638 + + (7) https://github.com/pypa/setuptools/issues/642 + + (8) https://github.com/pypa/setuptools/issues/648 + + +File: setuptools.info, Node: v24 0 2, Next: v24 0 1, Prev: v24 0 3, Up: History<2> + +9.202 v24.0.2 +============= + +04 Jul 2016 + + * If MSVC++14 is needed ‘setuptools.msvc’ now redirect user to Visual + C++ Build Tools web page. + + +File: setuptools.info, Node: v24 0 1, Next: v24 0 0, Prev: v24 0 2, Up: History<2> + +9.203 v24.0.1 +============= + +03 Jul 2016 + + * #625(1) and #626(2): Fixes on ‘setuptools.msvc’ mainly for Python 2 + and Linux. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/625 + + (2) https://github.com/pypa/setuptools/issues/626 + + +File: setuptools.info, Node: v24 0 0, Next: v23 2 1, Prev: v24 0 1, Up: History<2> + +9.204 v24.0.0 +============= + +02 Jul 2016 + + * Pull Request #174(1): Add more aggressive support for standalone + Microsoft Visual C++ compilers in msvc9compiler patch. + Particularly : Windows SDK 6.1 and 7.0 (MSVC++ 9.0), Windows SDK + 7.1 (MSVC++ 10.0), Visual C++ Build Tools 2015 (MSVC++14) + + * Renamed ‘setuptools.msvc9_support’ to ‘setuptools.msvc’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/174 + + +File: setuptools.info, Node: v23 2 1, Next: v23 1 0, Prev: v24 0 0, Up: History<2> + +9.205 v23.2.1 +============= + +02 Jul 2016 + +Re-release of v23.2.0, which was missing the intended commits. + + * #623(1): Remove used of deprecated ‘U’ flag when reading manifests. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/623 + + +File: setuptools.info, Node: v23 1 0, Next: v23 0 0, Prev: v23 2 1, Up: History<2> + +9.206 v23.1.0 +============= + +24 Jun 2016 + + * #619(1): Deprecated ‘tag_svn_revision’ distribution option. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/619 + + +File: setuptools.info, Node: v23 0 0, Next: v22 0 5, Prev: v23 1 0, Up: History<2> + +9.207 v23.0.0 +============= + +09 Jun 2016 + + * #611(1): Removed ARM executables for CLI and GUI script launchers + on Windows. If this was a feature you cared about, please comment + in the ticket. + + * #604(2): Removed docs building support. The project now relies on + documentation hosted at ‘https://setuptools.readthedocs.io/’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/611 + + (2) https://github.com/pypa/setuptools/issues/604 + + +File: setuptools.info, Node: v22 0 5, Next: v22 0 4, Prev: v23 0 0, Up: History<2> + +9.208 v22.0.5 +============= + +03 Jun 2016 + + * #604(1): Restore repository for upload_docs command to restore + publishing of docs during release. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/604 + + +File: setuptools.info, Node: v22 0 4, Next: v22 0 3, Prev: v22 0 5, Up: History<2> + +9.209 v22.0.4 +============= + +03 Jun 2016 + + * #589(1): Upload releases to pypi.io using the upload hostname and + legacy path. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/589 + + +File: setuptools.info, Node: v22 0 3, Next: v22 0 2, Prev: v22 0 4, Up: History<2> + +9.210 v22.0.3 +============= + +03 Jun 2016 + + * #589(1): Releases are now uploaded to pypi.io (Warehouse) even when + releases are made on Twine via Travis. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/589 + + +File: setuptools.info, Node: v22 0 2, Next: v22 0 1, Prev: v22 0 3, Up: History<2> + +9.211 v22.0.2 +============= + +03 Jun 2016 + + * #589(1): Releases are now uploaded to pypi.io (Warehouse). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/589 + + +File: setuptools.info, Node: v22 0 1, Next: v22 0 0, Prev: v22 0 2, Up: History<2> + +9.212 v22.0.1 +============= + +03 Jun 2016 + + * #190(1): On Python 2, if unicode is passed for packages to + ‘build_py’ command, it will be handled just as with text on Python + 3. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/190 + + +File: setuptools.info, Node: v22 0 0, Next: v21 2 2, Prev: v22 0 1, Up: History<2> + +9.213 v22.0.0 +============= + +01 Jun 2016 + +Intended to be v21.3.0, but jaraco accidentally released as a major +bump. + + * #598(1): Setuptools now lists itself first in the User-Agent for + web requests, better following the guidelines in RFC 7231(2). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/598 + + (2) https://tools.ietf.org/html/rfc7231#section-5.5.3 + + +File: setuptools.info, Node: v21 2 2, Next: v21 2 1, Prev: v22 0 0, Up: History<2> + +9.214 v21.2.2 +============= + +29 May 2016 + + * Minor fixes to changelog and docs. + + +File: setuptools.info, Node: v21 2 1, Next: v21 2 0, Prev: v21 2 2, Up: History<2> + +9.215 v21.2.1 +============= + +22 May 2016 + + * #261(1): Exclude directories when resolving globs in package_data. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/261 + + +File: setuptools.info, Node: v21 2 0, Next: v21 1 0, Prev: v21 2 1, Up: History<2> + +9.216 v21.2.0 +============= + +21 May 2016 + + * #539(1): In the easy_install get_site_dirs, honor all paths found + in ‘site.getsitepackages’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/539 + + +File: setuptools.info, Node: v21 1 0, Next: v21 0 0, Prev: v21 2 0, Up: History<2> + +9.217 v21.1.0 +============= + +18 May 2016 + + * #572(1): In build_ext, now always import ‘_CONFIG_VARS’ from + ‘distutils’ rather than from ‘sysconfig’ to allow + ‘distutils.sysconfig.customize_compiler’ configure the OS X + compiler for ‘-dynamiclib’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/572 + + +File: setuptools.info, Node: v21 0 0, Next: v20 10 0, Prev: v21 1 0, Up: History<2> + +9.218 v21.0.0 +============= + +02 May 2016 + + * Removed ez_setup.py from Setuptools sdist. The bootstrap script + will be maintained in its own branch and should be generally be + retrieved from its canonical location at + ‘https://bootstrap.pypa.io/ez_setup.py’. + + +File: setuptools.info, Node: v20 10 0, Next: v20 9 0, Prev: v21 0 0, Up: History<2> + +9.219 v20.10.0 +============== + +25 Apr 2016 + + * #553(1): egg_info section is now generated in a deterministic + order, matching the order generated by earlier versions of Python. + Except on Python 2.6, order is preserved when existing settings are + present. + + * #556(2): Update to Packaging 16.7(3), restoring support for + deprecated ‘python_implmentation’ marker. + + * #555(4): Upload command now prompts for a password when uploading + to PyPI (or other repository) if no password is present in .pypirc + or in the keyring. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/553 + + (2) https://github.com/pypa/setuptools/issues/556 + + (3) https://github.com/pypa/packaging/blob/16.7/CHANGELOG.rst + + (4) https://github.com/pypa/setuptools/issues/555 + + +File: setuptools.info, Node: v20 9 0, Next: v20 8 1, Prev: v20 10 0, Up: History<2> + +9.220 v20.9.0 +============= + +16 Apr 2016 + + * #548(1): Update certify version to 2016.2.28 + + * #545(2): Safely handle deletion of non-zip eggs in rotate command. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/548 + + (2) https://github.com/pypa/setuptools/issues/545 + + +File: setuptools.info, Node: v20 8 1, Next: v20 8 0, Prev: v20 9 0, Up: History<2> + +9.221 v20.8.1 +============= + +15 Apr 2016 + + * Issue #544(1): Fix issue with extra environment marker processing + in WorkingSet due to refactor in v20.7.0. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/544 + + +File: setuptools.info, Node: v20 8 0, Next: v20 7 0, Prev: v20 8 1, Up: History<2> + +9.222 v20.8.0 +============= + +15 Apr 2016 + + * Issue #543(1): Re-release so that latest release doesn’t cause déjà + vu with distribute and setuptools 0.7 in older environments. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/543 + + +File: setuptools.info, Node: v20 7 0, Next: v20 6 8, Prev: v20 8 0, Up: History<2> + +9.223 v20.7.0 +============= + +10 Apr 2016 + + * Refactored extra environment marker processing in WorkingSet. + + * Issue #533(1): Fixed intermittent test failures. + + * Issue #536(2): In msvc9_support, trap additional exceptions that + might occur when importing ‘distutils.msvc9compiler’ in mingw + environments. + + * Issue #537(3): Provide better context when package metadata fails + to decode in UTF-8. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/533 + + (2) https://github.com/pypa/setuptools/issues/536 + + (3) https://github.com/pypa/setuptools/issues/537 + + +File: setuptools.info, Node: v20 6 8, Next: v20 6 7, Prev: v20 7 0, Up: History<2> + +9.224 v20.6.8 +============= + +09 May 2016 + + * Issue #523(1): Restored support for environment markers, now + honoring ‘extra’ environment markers. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/523 + + +File: setuptools.info, Node: v20 6 7, Next: v20 6 6, Prev: v20 6 8, Up: History<2> + +9.225 v20.6.7 +============= + +31 Mar 2016 + + * Issue #523(1): Disabled support for environment markers introduced + in v20.5. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/523 + + +File: setuptools.info, Node: v20 6 6, Next: v20 6 0, Prev: v20 6 7, Up: History<2> + +9.226 v20.6.6 +============= + +30 Mar 2016 + + * Issue #503(1): Restore support for PEP 345(2) environment markers + by updating to Packaging 16.6(3). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/503 + + (2) https://www.python.org/dev/peps/pep-0345/ + + (3) https://github.com/pypa/packaging/blob/16.6/CHANGELOG.rst + + +File: setuptools.info, Node: v20 6 0, Next: 20 5, Prev: v20 6 6, Up: History<2> + +9.227 v20.6.0 +============= + +29 Mar 2016 + + * New release process that relies on bumpversion(1) and Travis CI for + continuous deployment. + + * Project versioning semantics now follow semver(2) precisely. The + ‘v’ prefix on version numbers now also allows version numbers to be + referenced in the changelog, e.g. + ‘http://setuptools.readthedocs.io/en/latest/history.html#v20-6-0’. + + ---------- Footnotes ---------- + + (1) https://github.com/peritus/bumpversion + + (2) https://semver.org + + +File: setuptools.info, Node: 20 5, Next: 20 4, Prev: v20 6 0, Up: History<2> + +9.228 20.5 +========== + +29 Mar 2016 + + * BB Pull Request #185(1), #470(2): Add support for environment + markers in requirements in install_requires, setup_requires, + tests_require as well as adding a test for the existing + extra_requires machinery. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/185 + + (2) https://github.com/pypa/setuptools/issues/470 + + +File: setuptools.info, Node: 20 4, Next: 20 3 1, Prev: 20 5, Up: History<2> + +9.229 20.4 +========== + +29 Mar 2016 + + * Issue #422(1): Moved hosting to Github(2) from Bitbucket(3). + Issues have been migrated, though all issues and comments are + attributed to bb-migration. So if you have a particular issue or + issues to which you’ve been subscribed, you will want to “watch” + the equivalent issue in Github. The Bitbucket project will be + retained for the indefinite future, but Github now hosts the + canonical project repository. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/422 + + (2) https://github.com/pypa/setuptools + + (3) https://bitbucket.org/pypa/setuptools + + +File: setuptools.info, Node: 20 3 1, Next: 20 3, Prev: 20 4, Up: History<2> + +9.230 20.3.1 +============ + +18 Mar 2016 + + * Issue #519(1): Remove import hook when reloading the + ‘pkg_resources’ module. + + * BB Pull Request #184(2): Update documentation in ‘pkg_resources’ + around new ‘Requirement’ implementation. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/519 + + (2) https://bitbucket.org/pypa/setuptools/pull-request/184 + + +File: setuptools.info, Node: 20 3, Next: 20 2 2, Prev: 20 3 1, Up: History<2> + +9.231 20.3 +========== + +15 Mar 2016 + + * BB Pull Request #179(1): ‘pkg_resources.Requirement’ objects are + now a subclass of ‘packaging.requirements.Requirement’, allowing + any environment markers and url (if any) to be affiliated with the + requirement + + * BB Pull Request #179(2): Restore use of RequirementParseError + exception unintentionally dropped in 20.2. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/179 + + (2) https://bitbucket.org/pypa/setuptools/pull-request/179 + + +File: setuptools.info, Node: 20 2 2, Next: 20 2 1, Prev: 20 3, Up: History<2> + +9.232 20.2.2 +============ + +27 Feb 2016 + + * Issue #502(1): Correct regression in parsing of multiple version + specifiers separated by commas and spaces. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/502 + + +File: setuptools.info, Node: 20 2 1, Next: 20 2, Prev: 20 2 2, Up: History<2> + +9.233 20.2.1 +============ + +24 Feb 2016 + + * Issue #499(1): Restore compatibility for legacy versions by bumping + to packaging 16.4(2). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/499 + + (2) https://github.com/pypa/packaging/blob/16.4/CHANGELOG.rst + + +File: setuptools.info, Node: 20 2, Next: 20 1 1, Prev: 20 2 1, Up: History<2> + +9.234 20.2 +========== + +19 Feb 2016 + + * Changelog now includes release dates and links to PEPs. + + * BB Pull Request #173(1): Replace dual PEP 345(2) _markerlib + implementation and PEP 426(3) implementation of environment marker + support from packaging 16.1(4) and PEP 508(5). Fixes Issue + #122(6). See also BB Pull Request #175(7), BB Pull Request + #168(8), and BB Pull Request #164(9). Additionally: + + - ‘Requirement.parse’ no longer retains the order of + extras. + + - ‘parse_requirements’ now requires that all versions be + PEP-440(10) compliant, as revealed in #499(11). Packages + released with invalid local versions should be + re-released using the proper local version syntax, e.g. + ‘mypkg-1.0+myorg.1’. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/173 + + (2) https://www.python.org/dev/peps/pep-0345/ + + (3) https://www.python.org/dev/peps/pep-0426/ + + (4) https://github.com/pypa/packaging/blob/16.1/CHANGELOG.rst + + (5) https://www.python.org/dev/peps/pep-0508/ + + (6) https://github.com/pypa/setuptools/issues/122 + + (7) https://bitbucket.org/pypa/setuptools/pull-request/175 + + (8) https://bitbucket.org/pypa/setuptools/pull-request/168 + + (9) https://bitbucket.org/pypa/setuptools/pull-request/164 + + (10) https://www.python.org/dev/peps/pep-0440/ + + (11) https://github.com/pypa/setuptools/issues/499 + + +File: setuptools.info, Node: 20 1 1, Next: 20 1, Prev: 20 2, Up: History<2> + +9.235 20.1.1 +============ + +12 Feb 2016 + + * Update ‘upload_docs’ command to also honor keyring for password + resolution. + + +File: setuptools.info, Node: 20 1, Next: 20 0, Prev: 20 1 1, Up: History<2> + +9.236 20.1 +========== + +11 Feb 2016 + + * Added support for using passwords from keyring in the upload + command. See the upload docs(1) for details. + + ---------- Footnotes ---------- + + (1) +https://setuptools.readthedocs.io/en/latest/setuptools.html#upload-upload-source-and-or-egg-distributions-to-pypi + + +File: setuptools.info, Node: 20 0, Next: 19 7, Prev: 20 1, Up: History<2> + +9.237 20.0 +========== + +07 Feb 2016 + + * Issue #118(1): Once again omit the package metadata (egg-info) from + the list of outputs in ‘--record’. This version of setuptools can + no longer be used to upgrade pip earlier than 6.0. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/118 + + +File: setuptools.info, Node: 19 7, Next: 19 6 2, Prev: 20 0, Up: History<2> + +9.238 19.7 +========== + +03 Feb 2016 + + * Off-project PR: 0dcee79(1) and f9bd9b9(2) For FreeBSD, also honor + root certificates from ca_root_nss(3). + + ---------- Footnotes ---------- + + (1) +https://github.com/pypa/setuptools/commit/0dcee791dfdcfacddaaec79b29f30a347a147413 + + (2) +https://github.com/pypa/setuptools/commit/f9bd9b9f5df54ef5a0bf8d16c3a889ab8c640580 + + (3) +https://github.com/pypa/setuptools/commit/3ae46c30225eb46e1f5aada1a19e88b79f04dc72 + + +File: setuptools.info, Node: 19 6 2, Next: 19 6 1, Prev: 19 7, Up: History<2> + +9.239 19.6.2 +============ + +31 Jan 2016 + + * Issue #491(1): Correct regression incurred in 19.4 where a + double-namespace package installed using pip would cause a + TypeError. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/491 + + +File: setuptools.info, Node: 19 6 1, Next: 19 6, Prev: 19 6 2, Up: History<2> + +9.240 19.6.1 +============ + +29 Jan 2016 + + * Restore compatibility for PyPy 3 compatibility lost in 19.4.1 + addressing Issue #487(1). + + * ‘setuptools.launch’ shim now loads scripts in a new namespace, + avoiding getting relative imports from the setuptools package on + Python 2. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/487 + + +File: setuptools.info, Node: 19 6, Next: 19 5, Prev: 19 6 1, Up: History<2> + +9.241 19.6 +========== + +24 Jan 2016 + + * Added a new entry script ‘setuptools.launch’, implementing the shim + found in ‘pip.util.setuptools_build’. Use this command to launch + distutils-only packages under setuptools in the same way that pip + does, causing the setuptools monkeypatching of distutils to be + invoked prior to invoking a script. Useful for debugging or + otherwise installing a distutils-only package under setuptools when + pip isn’t available or otherwise does not expose the desired + functionality. For example: + + $ python -m setuptools.launch setup.py develop + + * Issue #488(1): Fix dual manifestation of Extension class in + extension packages installed as dependencies when Cython is + present. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/488 + + +File: setuptools.info, Node: 19 5, Next: 19 4 1, Prev: 19 6, Up: History<2> + +9.242 19.5 +========== + +23 Jan 2016 + + * Issue #486(1): Correct TypeError when getfilesystemencoding returns + None. + + * Issue #139(2): Clarified the license as MIT. + + * BB Pull Request #169(3): Removed special handling of command spec + in scripts for Jython. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/486 + + (2) https://github.com/pypa/setuptools/issues/139 + + (3) https://bitbucket.org/pypa/setuptools/pull-request/169 + + +File: setuptools.info, Node: 19 4 1, Next: 19 4, Prev: 19 5, Up: History<2> + +9.243 19.4.1 +============ + +23 Jan 2016 + + * Issue #487(1): Use direct invocation of ‘importlib.machinery’ in + ‘pkg_resources’ to avoid missing detection on relevant platforms. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/487 + + +File: setuptools.info, Node: 19 4, Next: 19 3, Prev: 19 4 1, Up: History<2> + +9.244 19.4 +========== + +16 Jan 2016 + + * Issue #341(1): Correct error in path handling of package data files + in ‘build_py’ command when package is empty. + + * Distribute #323(2), Issue #141(3), Issue #207(4), and BB Pull + Request #167(5): Another implementation of + ‘pkg_resources.WorkingSet’ and ‘pkg_resources.Distribution’ that + supports replacing an extant package with a new one, allowing for + setup_requires dependencies to supersede installed packages for the + session. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/341 + + (2) https://bitbucket.org/tarek/distribute/issue/323 + + (3) https://github.com/pypa/setuptools/issues/141 + + (4) https://github.com/pypa/setuptools/issues/207 + + (5) https://bitbucket.org/pypa/setuptools/pull-request/167 + + +File: setuptools.info, Node: 19 3, Next: 19 2, Prev: 19 4, Up: History<2> + +9.245 19.3 +========== + +06 Jan 2016 + + * Issue #229(1): Implement new technique for readily incorporating + dependencies conditionally from vendored copies or primary + locations. Adds a new dependency on six. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/229 + + +File: setuptools.info, Node: 19 2, Next: 19 1 1, Prev: 19 3, Up: History<2> + +9.246 19.2 +========== + +25 Dec 2015 + + * BB Pull Request #163(1): Add get_command_list method to + Distribution. + + * BB Pull Request #162(2): Add missing whitespace to multiline string + literals. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/163 + + (2) https://bitbucket.org/pypa/setuptools/pull-request/162 + + +File: setuptools.info, Node: 19 1 1, Next: 19 1, Prev: 19 2, Up: History<2> + +9.247 19.1.1 +============ + +16 Dec 2015 + + * Issue #476(1): Cast version to string (using default encoding) to + avoid creating Unicode types on Python 2 clients. + + * Issue #477(2): In Powershell downloader, use explicit rendering of + strings, rather than rely on ‘repr’, which can be incorrect + (especially on Python 2). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/476 + + (2) https://github.com/pypa/setuptools/issues/477 + + +File: setuptools.info, Node: 19 1, Next: 19 0, Prev: 19 1 1, Up: History<2> + +9.248 19.1 +========== + +16 Dec 2015 + + * Issue #215(1): The bootstrap script ‘ez_setup.py’ now automatically + detects the latest version of setuptools (using PyPI JSON API) + rather than hard-coding a particular value. + + * Issue #475(2): Fix incorrect usage in _translate_metadata2. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/215 + + (2) https://github.com/pypa/setuptools/issues/475 + + +File: setuptools.info, Node: 19 0, Next: 18 8 1, Prev: 19 1, Up: History<2> + +9.249 19.0 +========== + +15 Dec 2015 + + * Issue #442(1): Use RawConfigParser for parsing .pypirc file. + Interpolated values are no longer honored in .pypirc files. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/442 + + +File: setuptools.info, Node: 18 8 1, Next: 18 8, Prev: 19 0, Up: History<2> + +9.250 18.8.1 +============ + +13 Dec 2015 + + * Issue #440(1): Prevent infinite recursion when a SandboxViolation + or other UnpickleableException occurs in a sandbox context with + setuptools hidden. Fixes regression introduced in Setuptools 12.0. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/440 + + +File: setuptools.info, Node: 18 8, Next: 18 7 1, Prev: 18 8 1, Up: History<2> + +9.251 18.8 +========== + +11 Dec 2015 + + * Deprecated ‘egg_info.get_pkg_info_revision’. + + * Issue #471(1): Don’t rely on repr for an HTML attribute value in + package_index. + + * Issue #419(2): Avoid errors in FileMetadata when the metadata + directory is broken. + + * Issue #472(3): Remove deprecated use of ‘U’ in mode parameter when + opening files. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/471 + + (2) https://github.com/pypa/setuptools/issues/419 + + (3) https://github.com/pypa/setuptools/issues/472 + + +File: setuptools.info, Node: 18 7 1, Next: 18 7, Prev: 18 8, Up: History<2> + +9.252 18.7.1 +============ + +01 Dec 2015 + + * Issue #469(1): Refactored logic for Issue #419(2) fix to re-use + metadata loading from Provider. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/469 + + (2) https://github.com/pypa/setuptools/issues/419 + + +File: setuptools.info, Node: 18 7, Next: 18 6 1, Prev: 18 7 1, Up: History<2> + +9.253 18.7 +========== + +28 Nov 2015 + + * Update dependency on certify. + + * BB Pull Request #160(1): Improve detection of gui script in + ‘easy_install._adjust_header’. + + * Made ‘test.test_args’ a non-data property; alternate fix for the + issue reported in BB Pull Request #155(2). + + * Issue #453(3): In ‘ez_setup’ bootstrap module, unload all + ‘pkg_resources’ modules following download. + + * BB Pull Request #158(4): Honor PEP-488(5) when excluding files for + namespace packages. + + * Issue #419(6) and BB Pull Request #144(7): Add experimental support + for reading the version info from distutils-installed metadata + rather than using the version in the filename. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/160 + + (2) https://bitbucket.org/pypa/setuptools/pull-request/155 + + (3) https://github.com/pypa/setuptools/issues/453 + + (4) https://bitbucket.org/pypa/setuptools/pull-request/158 + + (5) https://www.python.org/dev/peps/pep-0488/ + + (6) https://github.com/pypa/setuptools/issues/419 + + (7) https://bitbucket.org/pypa/setuptools/pull-request/144 + + +File: setuptools.info, Node: 18 6 1, Next: 18 6, Prev: 18 7, Up: History<2> + +9.254 18.6.1 +============ + +24 Nov 2015 + + * Issue #464(1): Correct regression in invocation of superclass on + old-style class on Python 2. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/464 + + +File: setuptools.info, Node: 18 6, Next: 18 5, Prev: 18 6 1, Up: History<2> + +9.255 18.6 +========== + +24 Nov 2015 + + * Issue #439(1): When installing entry_point scripts under + development, omit the version number of the package, allowing any + version of the package to be used. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/439 + + +File: setuptools.info, Node: 18 5, Next: 18 4, Prev: 18 6, Up: History<2> + +9.256 18.5 +========== + +01 Nov 2015 + + * In preparation for dropping support for Python 3.2, a warning is + now logged when pkg_resources is imported on Python 3.2 or earlier + Python 3 versions. + + * Add support for python_platform_implementation environment + marker(1). + + * Fix dictionary mutation during iteration(2). + + ---------- Footnotes ---------- + + (1) +https://github.com/pypa/setuptools/commit/94416707fd59a65f4a8f7f70541d6b3fc018b626 + + (2) +https://github.com/pypa/setuptools/commit/57ebfa41e0f96b97e599ecd931b7ae8a143e096e + + +File: setuptools.info, Node: 18 4, Next: 18 3 2, Prev: 18 5, Up: History<2> + +9.257 18.4 +========== + +10 Oct 2015 + + * Issue #446(1): Test command now always invokes unittest, even if no + test suite is supplied. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/446 + + +File: setuptools.info, Node: 18 3 2, Next: 18 3 1, Prev: 18 4, Up: History<2> + +9.258 18.3.2 +============ + +19 Sep 2015 + + * Correct another regression in setuptools.findall where the fix for + Python #12885(1) was lost. + + ---------- Footnotes ---------- + + (1) http://bugs.python.org/issue12885 + + +File: setuptools.info, Node: 18 3 1, Next: 18 3, Prev: 18 3 2, Up: History<2> + +9.259 18.3.1 +============ + +07 Sep 2015 + + * Issue #425(1): Correct regression in setuptools.findall. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/425 + + +File: setuptools.info, Node: 18 3, Next: 18 2, Prev: 18 3 1, Up: History<2> + +9.260 18.3 +========== + +06 Sep 2015 + + * BB Pull Request #135(1): Setuptools now allows disabling of the + manipulation of the sys.path during the processing of the + easy-install.pth file. To do so, set the environment variable + ‘SETUPTOOLS_SYS_PATH_TECHNIQUE’ to anything but “rewrite” (consider + “raw”). During any install operation with manipulation disabled, + setuptools packages will be appended to sys.path naturally. + + Future versions may change the default behavior to disable + manipulation. If so, the default behavior can be retained by + setting the variable to “rewrite”. + + * Issue #257(2): ‘easy_install --version’ now shows more detail about + the installation location and Python version. + + * Refactor setuptools.findall in preparation for re-submission back + to distutils. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/135 + + (2) https://github.com/pypa/setuptools/issues/257 + + +File: setuptools.info, Node: 18 2, Next: 18 1, Prev: 18 3, Up: History<2> + +9.261 18.2 +========== + +19 Aug 2015 + + * Issue #412(1): More efficient directory search in ‘find_packages’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/412 + + +File: setuptools.info, Node: 18 1, Next: 18 0 1, Prev: 18 2, Up: History<2> + +9.262 18.1 +========== + +02 Aug 2015 + + * Upgrade to vendored packaging 15.3(1). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/packaging/blob/15.3/CHANGELOG.rst + + +File: setuptools.info, Node: 18 0 1, Next: 18 0, Prev: 18 1, Up: History<2> + +9.263 18.0.1 +============ + +24 Jun 2015 + + * Issue #401(1): Fix failure in test suite. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/401 + + +File: setuptools.info, Node: 18 0, Next: 17 1 1, Prev: 18 0 1, Up: History<2> + +9.264 18.0 +========== + +13 Jun 2015 + + * Dropped support for builds with Pyrex. Only Cython is supported. + + * Issue #288(1): Detect Cython later in the build process, after + ‘setup_requires’ dependencies are resolved. Projects backed by + Cython can now be readily built with a ‘setup_requires’ dependency. + For example: + + ext = setuptools.Extension('mylib', ['src/CythonStuff.pyx', 'src/CStuff.c']) + setuptools.setup( + ... + ext_modules=[ext], + setup_requires=['cython'], + ) + + For compatibility with older versions of setuptools, packagers + should still include ‘src/CythonMod.c’ in the source distributions + or require that Cython be present before building source + distributions. However, for systems with this build of setuptools, + Cython will be downloaded on demand. + + * Issue #396(2): Fixed test failure on OS X. + + * BB Pull Request #136(3): Remove excessive quoting from shebang + headers for Jython. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/288 + + (2) https://github.com/pypa/setuptools/issues/396 + + (3) https://bitbucket.org/pypa/setuptools/pull-request/136 + + +File: setuptools.info, Node: 17 1 1, Next: 17 1, Prev: 18 0, Up: History<2> + +9.265 17.1.1 +============ + +08 Jun 2015 + + * Backed out unintended changes to pkg_resources, restoring removal + of deprecated imp module (ref(1)). + + ---------- Footnotes ---------- + + (1) +https://bitbucket.org/pypa/setuptools/commits/f572ec9563d647fa8d4ffc534f2af8070ea07a8b#comment-1881283 + + +File: setuptools.info, Node: 17 1, Next: 17 0, Prev: 17 1 1, Up: History<2> + +9.266 17.1 +========== + +07 Jun 2015 + + * Issue #380(1): Add support for range operators on environment + marker evaluation. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/380 + + +File: setuptools.info, Node: 17 0, Next: 16 0, Prev: 17 1, Up: History<2> + +9.267 17.0 +========== + +28 May 2015 + + * Issue #378(1): Do not use internal importlib._bootstrap module. + + * Issue #390(2): Disallow console scripts with path separators in the + name. Removes unintended functionality and brings behavior into + parity with pip. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/378 + + (2) https://github.com/pypa/setuptools/issues/390 + + +File: setuptools.info, Node: 16 0, Next: 15 2, Prev: 17 0, Up: History<2> + +9.268 16.0 +========== + +18 May 2015 + + * BB Pull Request #130(1): Better error messages for errors in parsed + requirements. + + * BB Pull Request #133(2): Removed ‘setuptools.tests’ from the + installed packages. + + * BB Pull Request #129(3): Address deprecation warning due to usage + of imp module. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/130 + + (2) https://bitbucket.org/pypa/setuptools/pull-request/133 + + (3) https://bitbucket.org/pypa/setuptools/pull-request/129 + + +File: setuptools.info, Node: 15 2, Next: 15 1, Prev: 16 0, Up: History<2> + +9.269 15.2 +========== + +26 Apr 2015 + + * Issue #373(1): Provisionally expose + ‘pkg_resources._initialize_master_working_set’, allowing for + imperative re-initialization of the master working set. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/373 + + +File: setuptools.info, Node: 15 1, Next: 15 0, Prev: 15 2, Up: History<2> + +9.270 15.1 +========== + +15 Apr 2015 + + * Updated to Packaging 15.1(1) to address Packaging #28(2). + + * Fix ‘setuptools.sandbox._execfile()’ with Python 3.1. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/packaging/blob/15.1/CHANGELOG.rst + + (2) https://github.com/pypa/packaging/issues/28 + + +File: setuptools.info, Node: 15 0, Next: 14 3 1, Prev: 15 1, Up: History<2> + +9.271 15.0 +========== + +03 Apr 2015 + + * BB Pull Request #126(1): DistributionNotFound message now lists the + package or packages that required it. E.g.: + + pkg_resources.DistributionNotFound: The 'colorama>=0.3.1' distribution was not found and is required by smlib.log. + + Note that zc.buildout once dependended on the string rendering of + this message to determine the package that was not found. This + expectation has since been changed, but older versions of buildout + may experience problems. See Buildout #242(2) for details. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/126 + + (2) https://github.com/buildout/buildout/issues/242 + + +File: setuptools.info, Node: 14 3 1, Next: 14 3, Prev: 15 0, Up: History<2> + +9.272 14.3.1 +============ + +20 Mar 2015 + + * Issue #307(1): Removed PEP-440(2) warning during parsing of + versions in ‘pkg_resources.Distribution’. + + * Issue #364(3): Replace deprecated usage with recommended usage of + ‘EntryPoint.load’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/307 + + (2) https://www.python.org/dev/peps/pep-0440/ + + (3) https://github.com/pypa/setuptools/issues/364 + + +File: setuptools.info, Node: 14 3, Next: 14 2, Prev: 14 3 1, Up: History<2> + +9.273 14.3 +========== + +15 Mar 2015 + + * Issue #254(1): When creating temporary egg cache on Unix, use mode + 755 for creating the directory to avoid the subsequent warning if + the directory is group writable. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/254 + + +File: setuptools.info, Node: 14 2, Next: 14 1 1, Prev: 14 3, Up: History<2> + +9.274 14.2 +========== + +15 Mar 2015 + + * Issue #137(1): Update ‘Distribution.hashcmp’ so that Distributions + with None for pyversion or platform can be compared against + Distributions defining those attributes. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/137 + + +File: setuptools.info, Node: 14 1 1, Next: 14 1, Prev: 14 2, Up: History<2> + +9.275 14.1.1 +============ + +14 Mar 2015 + + * Issue #360(1): Removed undesirable behavior from test runs, + preventing write tests and installation to system site packages. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/360 + + +File: setuptools.info, Node: 14 1, Next: 14 0, Prev: 14 1 1, Up: History<2> + +9.276 14.1 +========== + +14 Mar 2015 + + * BB Pull Request #125(1): Add ‘__ne__’ to Requirement class. + + * Various refactoring of easy_install. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/125 + + +File: setuptools.info, Node: 14 0, Next: 13 0 2, Prev: 14 1, Up: History<2> + +9.277 14.0 +========== + +06 Mar 2015 + + * Bootstrap script now accepts ‘--to-dir’ to customize save directory + or allow for re-use of existing repository of setuptools versions. + See BB Pull Request #112(1) for background. + + * Issue #285(2): ‘easy_install’ no longer will default to installing + packages to the “user site packages” directory if it is itself + installed there. Instead, the user must pass ‘--user’ in all cases + to install packages to the user site packages. This behavior now + matches that of “pip install”. To configure an environment to + always install to the user site packages, consider using the + “install-dir” and “scripts-dir” parameters to easy_install through + an appropriate distutils config file. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/112 + + (2) https://github.com/pypa/setuptools/issues/285 + + +File: setuptools.info, Node: 13 0 2, Next: 13 0 1, Prev: 14 0, Up: History<2> + +9.278 13.0.2 +============ + +06 Mar 2015 + + * Issue #359(1): Include pytest.ini in the sdist so invocation of + py.test on the sdist honors the pytest configuration. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/359 + + +File: setuptools.info, Node: 13 0 1, Next: 13 0, Prev: 13 0 2, Up: History<2> + +9.279 13.0.1 +============ + +05 Mar 2015 + +Re-release of 13.0. Intermittent connectivity issues caused the release +process to fail and PyPI uploads no longer accept files for 13.0. + + +File: setuptools.info, Node: 13 0, Next: 12 4, Prev: 13 0 1, Up: History<2> + +9.280 13.0 +========== + +05 Mar 2015 + + * Issue #356(1): Back out BB Pull Request #119(2) as it requires + Setuptools 10 or later as the source during an upgrade. + + * Removed build_py class from setup.py. According to 892f439d216e, + this functionality was added to support upgrades from old + Distribute versions, 0.6.5 and 0.6.6. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/356 + + (2) https://bitbucket.org/pypa/setuptools/pull-request/119 + + +File: setuptools.info, Node: 12 4, Next: 12 3, Prev: 13 0, Up: History<2> + +9.281 12.4 +========== + +04 Mar 2015 + + * BB Pull Request #119(1): Restore writing of ‘setup_requires’ to + metadata (previously added in 8.4 and removed in 9.0). + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/119 + + +File: setuptools.info, Node: 12 3, Next: 12 2, Prev: 12 4, Up: History<2> + +9.282 12.3 +========== + +26 Feb 2015 + + * Documentation is now linked using the rst.linker package. + + * Fix ‘setuptools.command.easy_install.extract_wininst_cfg()’ with + Python 2.6 and 2.7. + + * Issue #354(1). Added documentation on building setuptools + documentation. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/354 + + +File: setuptools.info, Node: 12 2, Next: 12 1, Prev: 12 3, Up: History<2> + +9.283 12.2 +========== + +16 Feb 2015 + + * Issue #345(1): Unload all modules under pkg_resources during + ‘ez_setup.use_setuptools()’. + + * Issue #336(2): Removed deprecation from ‘ez_setup.use_setuptools’, + as it is clearly still used by buildout’s bootstrap. ‘ez_setup’ + remains deprecated for use by individual packages. + + * Simplified implementation of ‘ez_setup.use_setuptools’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/345 + + (2) https://github.com/pypa/setuptools/issues/336 + + +File: setuptools.info, Node: 12 1, Next: 12 0 5, Prev: 12 2, Up: History<2> + +9.284 12.1 +========== + +10 Feb 2015 + + * BB Pull Request #118(1): Soften warning for non-normalized versions + in Distribution. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/118 + + +File: setuptools.info, Node: 12 0 5, Next: 12 0 4, Prev: 12 1, Up: History<2> + +9.285 12.0.5 +============ + +26 Jan 2015 + + * Issue #339(1): Correct Attribute reference in + ‘cant_write_to_target’. + + * Issue #336(2): Deprecated ‘ez_setup.use_setuptools’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/339 + + (2) https://github.com/pypa/setuptools/issues/336 + + +File: setuptools.info, Node: 12 0 4, Next: 12 0 3, Prev: 12 0 5, Up: History<2> + +9.286 12.0.4 +============ + +20 Jan 2015 + + * Issue #335(1): Fix script header generation on Windows. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/335 + + +File: setuptools.info, Node: 12 0 3, Next: 12 0 2, Prev: 12 0 4, Up: History<2> + +9.287 12.0.3 +============ + +18 Jan 2015 + + * Fixed incorrect class attribute in ‘install_scripts’. Tests would + be nice. + + +File: setuptools.info, Node: 12 0 2, Next: 12 0 1, Prev: 12 0 3, Up: History<2> + +9.288 12.0.2 +============ + +18 Jan 2015 + + * Issue #331(1): Fixed ‘install_scripts’ command on Windows systems + corrupting the header. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/331 + + +File: setuptools.info, Node: 12 0 1, Next: 12 0, Prev: 12 0 2, Up: History<2> + +9.289 12.0.1 +============ + +16 Jan 2015 + + * Restore ‘setuptools.command.easy_install.sys_executable’ for pbr + compatibility. For the future, tools should construct a + CommandSpec explicitly. + + +File: setuptools.info, Node: 12 0, Next: 11 3 1, Prev: 12 0 1, Up: History<2> + +9.290 12.0 +========== + +16 Jan 2015 + + * Issue #188(1): Setuptools now support multiple entities in the + value for ‘build.executable’, such that an executable of + “/usr/bin/env my-python” may be specified. This means that systems + with a specified executable whose name has spaces in the path must + be updated to escape or quote that value. + + * Deprecated ‘easy_install.ScriptWriter.get_writer’, replaced by + ‘.best()’ with slightly different semantics (no force_windows + flag). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/188 + + +File: setuptools.info, Node: 11 3 1, Next: 11 3, Prev: 12 0, Up: History<2> + +9.291 11.3.1 +============ + +06 Jan 2015 + + * Issue #327(1): Formalize and restore support for any printable + character in an entry point name. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/327 + + +File: setuptools.info, Node: 11 3, Next: 11 2, Prev: 11 3 1, Up: History<2> + +9.292 11.3 +========== + +05 Jan 2015 + + * Expose ‘EntryPoint.resolve’ in place of EntryPoint._load, + implementing the simple, non-requiring load. Deprecated all uses + of ‘EntryPoint._load’ except for calling with no parameters, which + is just a shortcut for ‘ep.require(); ep.resolve();’. + + Apps currently invoking ‘ep.load(require=False)’ should instead do + the following if wanting to avoid the deprecating warning: + + getattr(ep, "resolve", lambda: ep.load(require=False))() + + +File: setuptools.info, Node: 11 2, Next: 11 1, Prev: 11 3, Up: History<2> + +9.293 11.2 +========== + +05 Jan 2015 + + * Pip #2326(1): Report deprecation warning at stacklevel 2 for easier + diagnosis. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/pip/issues/2326 + + +File: setuptools.info, Node: 11 1, Next: 11 0, Prev: 11 2, Up: History<2> + +9.294 11.1 +========== + +04 Jan 2015 + + * Issue #281(1): Since Setuptools 6.1 (Issue #268(2)), a ValueError + would be raised in certain cases where VersionConflict was raised + with two arguments, which occurred in + ‘pkg_resources.WorkingSet.find’. This release adds support for + indicating the dependent packages while maintaining support for a + VersionConflict when no dependent package context is known. New + unit tests now capture the expected interface. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/281 + + (2) https://github.com/pypa/setuptools/issues/268 + + +File: setuptools.info, Node: 11 0, Next: 10 2 1, Prev: 11 1, Up: History<2> + +9.295 11.0 +========== + +02 Jan 2015 + + * Interop #3(1): Upgrade to Packaging 15.0(2); updates to PEP 440(3) + so that >1.7 does not exclude 1.7.1 but does exclude 1.7.0 and + 1.7.0.post1. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/interoperability-peps/issues/3 + + (2) https://github.com/pypa/packaging/blob/15.0/CHANGELOG.rst + + (3) https://www.python.org/dev/peps/pep-0440/ + + +File: setuptools.info, Node: 10 2 1, Next: 10 2, Prev: 11 0, Up: History<2> + +9.296 10.2.1 +============ + +02 Jan 2015 + + * Issue #323(1): Fix regression in entry point name parsing. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/323 + + +File: setuptools.info, Node: 10 2, Next: 10 1, Prev: 10 2 1, Up: History<2> + +9.297 10.2 +========== + +02 Jan 2015 + + * Deprecated use of EntryPoint.load(require=False). Passing a + boolean to a function to select behavior is an anti-pattern. + Instead use ‘Entrypoint._load()’. + + * Substantial refactoring of all unit tests. Tests are now much + leaner and re-use a lot of fixtures and contexts for better clarity + of purpose. + + +File: setuptools.info, Node: 10 1, Next: 10 0 1, Prev: 10 2, Up: History<2> + +9.298 10.1 +========== + +31 Dec 2014 + + * Issue #320(1): Added a compatibility implementation of + ‘sdist._default_revctrl’ so that systems relying on that interface + do not fail (namely, Ubuntu 12.04 and similar Debian releases). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/320 + + +File: setuptools.info, Node: 10 0 1, Next: 10 0, Prev: 10 1, Up: History<2> + +9.299 10.0.1 +============ + +30 Dec 2014 + + * Issue #319(1): Fixed issue installing pure distutils packages. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/319 + + +File: setuptools.info, Node: 10 0, Next: 9 1, Prev: 10 0 1, Up: History<2> + +9.300 10.0 +========== + +30 Dec 2014 + + * Issue #313(1): Removed built-in support for subversion. Projects + wishing to retain support for subversion will need to use a third + party library. The extant implementation is being ported to + setuptools_svn(2). + + * Issue #315(3): Updated setuptools to hide its own loaded modules + during installation of another package. This change will enable + setuptools to upgrade (or downgrade) itself even when its own + metadata and implementation change. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/313 + + (2) https://pypi.org/project/setuptools_svn/ + + (3) https://github.com/pypa/setuptools/issues/315 + + +File: setuptools.info, Node: 9 1, Next: 9 0 1, Prev: 10 0, Up: History<2> + +9.301 9.1 +========= + +29 Dec 2014 + + * Prefer vendored packaging library as recommended(1). + + ---------- Footnotes ---------- + + (1) +https://github.com/pypa/setuptools/commit/170657b68f4b92e7e1bf82f5e19a831f5744af67 + + +File: setuptools.info, Node: 9 0 1, Next: 9 0, Prev: 9 1, Up: History<2> + +9.302 9.0.1 +=========== + +29 Dec 2014 + + * Issue #312(1): Restored presence of pkg_resources API tests + (doctest) to sdist. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/312 + + +File: setuptools.info, Node: 9 0, Next: 8 4, Prev: 9 0 1, Up: History<2> + +9.303 9.0 +========= + +28 Dec 2014 + + * Issue #314(1): Disabled support for ‘setup_requires’ metadata to + avoid issue where Setuptools was unable to upgrade over earlier + versions. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/314 + + +File: setuptools.info, Node: 8 4, Next: 8 3, Prev: 9 0, Up: History<2> + +9.304 8.4 +========= + +26 Dec 2014 + + * BB Pull Request #106(1): Now write ‘setup_requires’ metadata. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/106 + + +File: setuptools.info, Node: 8 3, Next: 8 2 1, Prev: 8 4, Up: History<2> + +9.305 8.3 +========= + +24 Dec 2014 + + * Issue #311(1): Decoupled pkg_resources from setuptools once again. + ‘pkg_resources’ is now a package instead of a module. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/311 + + +File: setuptools.info, Node: 8 2 1, Next: 8 2, Prev: 8 3, Up: History<2> + +9.306 8.2.1 +=========== + +18 Dec 2014 + + * Issue #306(1): Suppress warnings about Version format except in + select scenarios (such as installation). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/306 + + +File: setuptools.info, Node: 8 2, Next: 8 1, Prev: 8 2 1, Up: History<2> + +9.307 8.2 +========= + +18 Dec 2014 + + * BB Pull Request #85(1): Search egg-base when adding egg-info to + manifest. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/85 + + +File: setuptools.info, Node: 8 1, Next: 8 0 4, Prev: 8 2, Up: History<2> + +9.308 8.1 +========= + +18 Dec 2014 + + * Upgrade ‘packaging’ to 14.5, giving preference to “rc” as + designator for release candidates over “c”. + + * PEP-440(1) warnings are now raised as their own class, + ‘pkg_resources.PEP440Warning’, instead of RuntimeWarning. + + * Disabled warnings on empty versions. + + ---------- Footnotes ---------- + + (1) https://www.python.org/dev/peps/pep-0440/ + + +File: setuptools.info, Node: 8 0 4, Next: 8 0 3, Prev: 8 1, Up: History<2> + +9.309 8.0.4 +=========== + +15 Dec 2014 + + * Upgrade ‘packaging’ to 14.4, fixing an error where there is a + different result for if 2.0.5 is contained within >2.0dev and + >2.0.dev even though normalization rules should have made them + equal. + + * Issue #296(1): Add warning when a version is parsed as legacy. + This warning will make it easier for developers to recognize + deprecated version numbers. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/296 + + +File: setuptools.info, Node: 8 0 3, Next: 8 0 2, Prev: 8 0 4, Up: History<2> + +9.310 8.0.3 +=========== + +15 Dec 2014 + + * Issue #296(1): Restored support for ‘__hash__’ on parse_version + results. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/296 + + +File: setuptools.info, Node: 8 0 2, Next: 8 0 1, Prev: 8 0 3, Up: History<2> + +9.311 8.0.2 +=========== + +14 Dec 2014 + + * Issue #296(1): Restored support for ‘__getitem__’ and sort + operations on parse_version result. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/296 + + +File: setuptools.info, Node: 8 0 1, Next: 8 0, Prev: 8 0 2, Up: History<2> + +9.312 8.0.1 +=========== + +13 Dec 2014 + + * Issue #296(1): Restore support for iteration over parse_version + result, but deprecated that usage with a warning. Fixes failure + with buildout. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/296 + + +File: setuptools.info, Node: 8 0, Next: 7 0, Prev: 8 0 1, Up: History<2> + +9.313 8.0 +========= + +13 Dec 2014 + + * Implement PEP 440(1) within pkg_resources and setuptools. This + change deprecates some version numbers such that they will no + longer be installable without using the ‘===’ escape hatch. See + the changes to test_resources(2) for specific examples of version + numbers and specifiers that are no longer supported. Setuptools + now “vendors” the packaging(3) library. + + ---------- Footnotes ---------- + + (1) https://www.python.org/dev/peps/pep-0440/ + + (2) +https://bitbucket.org/pypa/setuptools/commits/dcd552da643c4448056de84c73d56da6d70769d5#chg-setuptools/tests/test_resources.py + + (3) https://github.com/pypa/packaging + + +File: setuptools.info, Node: 7 0, Next: 6 1, Prev: 8 0, Up: History<2> + +9.314 7.0 +========= + +19 Oct 2014 + + * Issue #80(1), Issue #209(2): Eggs that are downloaded for + ‘setup_requires’, ‘test_requires’, etc. are now placed in a + ‘./.eggs’ directory instead of directly in the current directory. + This choice of location means the files can be readily managed + (removed, ignored). Additionally, later phases or invocations of + setuptools will not detect the package as already installed and + ignore it for permanent install (See #209(3)). + + This change is indicated as backward-incompatible as installations + that depend on the installation in the current directory will need + to account for the new location. Systems that ignore ‘*.egg’ will + probably need to be adapted to ignore ‘.eggs’. The files will need + to be manually moved or will be retrieved again. Most use cases + will require no attention. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/80 + + (2) https://github.com/pypa/setuptools/issues/209 + + (3) https://github.com/pypa/setuptools/issues/209 + + +File: setuptools.info, Node: 6 1, Next: 6 0 2, Prev: 7 0, Up: History<2> + +9.315 6.1 +========= + +11 Oct 2014 + + * Issue #268(1): When resolving package versions, a VersionConflict + now reports which package previously required the conflicting + version. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/268 + + +File: setuptools.info, Node: 6 0 2, Next: 6 0 1, Prev: 6 1, Up: History<2> + +9.316 6.0.2 +=========== + +29 Sep 2014 + + * Issue #262(1): Fixed regression in pip install due to egg-info + directories being omitted. Re-opens Issue #118(2). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/262 + + (2) https://github.com/pypa/setuptools/issues/118 + + +File: setuptools.info, Node: 6 0 1, Next: 6 0, Prev: 6 0 2, Up: History<2> + +9.317 6.0.1 +=========== + +27 Sep 2014 + + * Issue #259(1): Fixed regression with namespace package handling on + ‘single version, externally managed’ installs. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/259 + + +File: setuptools.info, Node: 6 0, Next: 5 8, Prev: 6 0 1, Up: History<2> + +9.318 6.0 +========= + +27 Sep 2014 + + * Issue #100(1): When building a distribution, Setuptools will no + longer match default files using platform-dependent case + sensitivity, but rather will only match the files if their case + matches exactly. As a result, on Windows and other + case-insensitive file systems, files with names such as + ‘readme.txt’ or ‘README.TXT’ will be omitted from the distribution + and a warning will be issued indicating that ‘README.txt’ was not + found. Other filenames affected are: + + - README.rst + + - README + + - setup.cfg + + - setup.py (or the script name) + + - test/test*.py + + Any users producing distributions with filenames that match those + above case-insensitively, but not case-sensitively, should rename + those files in their repository for better portability. + + * BB Pull Request #72(2): When using + ‘single_version_externally_managed’, the exclusion list now + includes Python 3.2 ‘__pycache__’ entries. + + * BB Pull Request #76(3) and BB Pull Request #78(4): lines in + top_level.txt are now ordered deterministically. + + * Issue #118(5): The egg-info directory is now no longer included in + the list of outputs. + + * Issue #258(6): Setuptools now patches distutils msvc9compiler to + recognize the specially-packaged compiler package for easy + extension module support on Python 2.6, 2.7, and 3.2. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/100 + + (2) https://bitbucket.org/pypa/setuptools/pull-request/72 + + (3) https://bitbucket.org/pypa/setuptools/pull-request/76 + + (4) https://bitbucket.org/pypa/setuptools/pull-request/78 + + (5) https://github.com/pypa/setuptools/issues/118 + + (6) https://github.com/pypa/setuptools/issues/258 + + +File: setuptools.info, Node: 5 8, Next: 5 7, Prev: 6 0, Up: History<2> + +9.319 5.8 +========= + +18 Sep 2014 + + * Issue #237(1): ‘pkg_resources’ now uses explicit detection of + Python 2 vs. Python 3, supporting environments where builtins have + been patched to make Python 3 look more like Python 2. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/237 + + +File: setuptools.info, Node: 5 7, Next: 5 6, Prev: 5 8, Up: History<2> + +9.320 5.7 +========= + +15 Aug 2014 + + * Issue #240(1): Based on real-world performance measures against + 5.4, zip manifests are now cached in all circumstances. The + ‘PKG_RESOURCES_CACHE_ZIP_MANIFESTS’ environment variable is no + longer relevant. The observed “memory increase” referenced in the + 5.4 release notes and detailed in Issue #154(2) was likely not an + increase over the status quo, but rather only an increase over not + storing the zip info at all. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/240 + + (2) https://github.com/pypa/setuptools/issues/154 + + +File: setuptools.info, Node: 5 6, Next: 5 5 1, Prev: 5 7, Up: History<2> + +9.321 5.6 +========= + +14 Aug 2014 + + * Issue #242(1): Use absolute imports in svn_utils to avoid issues if + the installing package adds an xml module to the path. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/242 + + +File: setuptools.info, Node: 5 5 1, Next: 5 5, Prev: 5 6, Up: History<2> + +9.322 5.5.1 +=========== + +10 Aug 2014 + + * Issue #239(1): Fix typo in 5.5 such that fix did not take. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/239 + + +File: setuptools.info, Node: 5 5, Next: 5 4 2, Prev: 5 5 1, Up: History<2> + +9.323 5.5 +========= + +10 Aug 2014 + + * Issue #239(1): Setuptools now includes the setup_requires directive + on Distribution objects and validates the syntax just like + install_requires and tests_require directives. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/239 + + +File: setuptools.info, Node: 5 4 2, Next: 5 4 1, Prev: 5 5, Up: History<2> + +9.324 5.4.2 +=========== + +01 Aug 2014 + + * Issue #236(1): Corrected regression in execfile implementation for + Python 2.6. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/236 + + +File: setuptools.info, Node: 5 4 1, Next: 5 4, Prev: 5 4 2, Up: History<2> + +9.325 5.4.1 +=========== + +06 Jul 2014 + + * Python #7776(1): (ssl_support) Correct usage of host for validation + when tunneling for HTTPS. + + ---------- Footnotes ---------- + + (1) http://bugs.python.org/issue7776 + + +File: setuptools.info, Node: 5 4, Next: 5 3, Prev: 5 4 1, Up: History<2> + +9.326 5.4 +========= + +05 Jul 2014 + + * Issue #154(1): ‘pkg_resources’ will now cache the zip manifests + rather than re-processing the same file from disk multiple times, + but only if the environment variable + ‘PKG_RESOURCES_CACHE_ZIP_MANIFESTS’ is set. Clients that package + many modules in the same zip file will see some improvement in + startup time by enabling this feature. This feature is not enabled + by default because it causes a substantial increase in memory + usage. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/154 + + +File: setuptools.info, Node: 5 3, Next: 5 2, Prev: 5 4, Up: History<2> + +9.327 5.3 +========= + +28 Jun 2014 + + * Issue #185(1): Make svn tagging work on the new style SVN metadata. + Thanks cazabon! + + * Prune revision control directories (e.g .svn) from base path as + well as sub-directories. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/185 + + +File: setuptools.info, Node: 5 2, Next: 5 1, Prev: 5 3, Up: History<2> + +9.328 5.2 +========= + +22 Jun 2014 + + * Added a Developer Guide(1) to the official documentation. + + * Some code refactoring and cleanup was done with no intended + behavioral changes. + + * During install_egg_info, the generated lines for namespace package + .pth files are now processed even during a dry run. + + ---------- Footnotes ---------- + + (1) https://setuptools.readthedocs.io/en/latest/developer-guide.html + + +File: setuptools.info, Node: 5 1, Next: 5 0 2, Prev: 5 2, Up: History<2> + +9.329 5.1 +========= + +15 Jun 2014 + + * Issue #202(1): Implemented more robust cache invalidation for the + ZipImporter, building on the work in Issue #168(2). Special thanks + to Jurko Gospodnetic and PJE. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/202 + + (2) https://github.com/pypa/setuptools/issues/168 + + +File: setuptools.info, Node: 5 0 2, Next: 5 0 1, Prev: 5 1, Up: History<2> + +9.330 5.0.2 +=========== + +15 Jun 2014 + + * Issue #220(1): Restored script templates. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/220 + + +File: setuptools.info, Node: 5 0 1, Next: 5 0, Prev: 5 0 2, Up: History<2> + +9.331 5.0.1 +=========== + +14 Jun 2014 + + * Renamed script templates to end with .tmpl now that they no longer + need to be processed by 2to3. Fixes spurious syntax errors during + build/install. + + +File: setuptools.info, Node: 5 0, Next: 3 7 1 and 3 8 1 and 4 0 1, Prev: 5 0 1, Up: History<2> + +9.332 5.0 +========= + +14 Jun 2014 + + * Issue #218(1): Re-release of 3.8.1 to signal that it supersedes + 4.x. + + * Incidentally, script templates were updated not to include the + triple-quote escaping. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/218 + + +File: setuptools.info, Node: 3 7 1 and 3 8 1 and 4 0 1, Next: 4 0, Prev: 5 0, Up: History<2> + +9.333 3.7.1 and 3.8.1 and 4.0.1 +=============================== + + * Issue #213(1): Use legacy StringIO behavior for compatibility under + pbr. + + * Issue #218(2): Setuptools 3.8.1 superseded 4.0.1, and 4.x was + removed from the available versions to install. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/213 + + (2) https://github.com/pypa/setuptools/issues/218 + + +File: setuptools.info, Node: 4 0, Next: 3 8, Prev: 3 7 1 and 3 8 1 and 4 0 1, Up: History<2> + +9.334 4.0 +========= + +01 Jun 2014 + + * Issue #210(1): ‘setup.py develop’ now copies scripts in binary mode + rather than text mode, matching the behavior of the ‘install’ + command. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/210 + + +File: setuptools.info, Node: 3 8, Next: 3 7, Prev: 4 0, Up: History<2> + +9.335 3.8 +========= + +01 Jun 2014 + + * Extend Issue #197(1) workaround to include all Python 3 versions + prior to 3.2.2. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/197 + + +File: setuptools.info, Node: 3 7, Next: 3 6, Prev: 3 8, Up: History<2> + +9.336 3.7 +========= + +28 May 2014 + + * Issue #193(1): Improved handling of Unicode filenames when building + manifests. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/193 + + +File: setuptools.info, Node: 3 6, Next: 3 5 2, Prev: 3 7, Up: History<2> + +9.337 3.6 +========= + +07 May 2014 + + * Issue #203(1): Honor proxy settings for Powershell downloader in + the bootstrap routine. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/203 + + +File: setuptools.info, Node: 3 5 2, Next: 3 5 1, Prev: 3 6, Up: History<2> + +9.338 3.5.2 +=========== + +07 May 2014 + + * Issue #168(1): More robust handling of replaced zip files and stale + caches. Fixes ZipImportError complaining about a ‘bad local + header’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/168 + + +File: setuptools.info, Node: 3 5 1, Next: 3 5, Prev: 3 5 2, Up: History<2> + +9.339 3.5.1 +=========== + +04 May 2014 + + * Issue #199(1): Restored ‘install._install’ for compatibility with + earlier NumPy versions. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/199 + + +File: setuptools.info, Node: 3 5, Next: 3 4 4, Prev: 3 5 1, Up: History<2> + +9.340 3.5 +========= + +03 May 2014 + + * Issue #195(1): Follow symbolic links in find_packages (restoring + behavior broken in 3.4). + + * Issue #197(2): On Python 3.1, PKG-INFO is now saved in a UTF-8 + encoding instead of ‘sys.getpreferredencoding’ to match the + behavior on Python 2.6-3.4. + + * Issue #192(3): Preferred bootstrap location is now + ‘https://bootstrap.pypa.io/ez_setup.py’ (mirrored from former + location). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/195 + + (2) https://github.com/pypa/setuptools/issues/197 + + (3) https://github.com/pypa/setuptools/issues/192 + + +File: setuptools.info, Node: 3 4 4, Next: 3 4 3, Prev: 3 5, Up: History<2> + +9.341 3.4.4 +=========== + +11 Apr 2014 + + * Issue #184(1): Correct failure where find_package over-matched + packages when directory traversal isn’t short-circuited. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/184 + + +File: setuptools.info, Node: 3 4 3, Next: 3 4 2, Prev: 3 4 4, Up: History<2> + +9.342 3.4.3 +=========== + +07 Apr 2014 + + * Issue #183(1): Really fix test command with Python 3.1. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/183 + + +File: setuptools.info, Node: 3 4 2, Next: 3 4 1, Prev: 3 4 3, Up: History<2> + +9.343 3.4.2 +=========== + +06 Apr 2014 + + * Issue #183(1): Fix additional regression in test command on Python + 3.1. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/183 + + +File: setuptools.info, Node: 3 4 1, Next: 3 4, Prev: 3 4 2, Up: History<2> + +9.344 3.4.1 +=========== + +30 Mar 2014 + + * Issue #180(1): Fix regression in test command not caught by + py.test-run tests. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/180 + + +File: setuptools.info, Node: 3 4, Next: 3 3, Prev: 3 4 1, Up: History<2> + +9.345 3.4 +========= + +30 Mar 2014 + + * Issue #176(1): Add parameter to the test command to support a + custom test runner: –test-runner or -r. + + * Issue #177(2): Now assume most common invocation to install command + on platforms/environments without stack support (issuing a + warning). Setuptools now installs naturally on IronPython. + Behavior on CPython should be unchanged. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/176 + + (2) https://github.com/pypa/setuptools/issues/177 + + +File: setuptools.info, Node: 3 3, Next: 3 2, Prev: 3 4, Up: History<2> + +9.346 3.3 +========= + +16 Mar 2014 + + * Add ‘include’ parameter to ‘setuptools.find_packages()’. + + +File: setuptools.info, Node: 3 2, Next: 3 1, Prev: 3 3, Up: History<2> + +9.347 3.2 +========= + +14 Mar 2014 + + * BB Pull Request #39(1): Add support for C++ targets from Cython + ‘.pyx’ files. + + * Issue #162(2): Update dependency on certifi to 1.0.1. + + * Issue #164(3): Update dependency on wincertstore to 0.2. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/39 + + (2) https://github.com/pypa/setuptools/issues/162 + + (3) https://github.com/pypa/setuptools/issues/164 + + +File: setuptools.info, Node: 3 1, Next: 3 0 2, Prev: 3 2, Up: History<2> + +9.348 3.1 +========= + +08 Mar 2014 + + * Issue #161(1): Restore Features functionality to allow backward + compatibility (for Features) until the uses of that functionality + is sufficiently removed. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/161 + + +File: setuptools.info, Node: 3 0 2, Next: 3 0 1, Prev: 3 1, Up: History<2> + +9.349 3.0.2 +=========== + +06 Mar 2014 + + * Correct typo in previous bugfix. + + +File: setuptools.info, Node: 3 0 1, Next: 3 0, Prev: 3 0 2, Up: History<2> + +9.350 3.0.1 +=========== + +06 Mar 2014 + + * Issue #157(1): Restore support for Python 2.6 in bootstrap script + where ‘zipfile.ZipFile’ does not yet have support for context + managers. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/157 + + +File: setuptools.info, Node: 3 0, Next: 2 2, Prev: 3 0 1, Up: History<2> + +9.351 3.0 +========= + +04 Mar 2014 + + * Issue #125(1): Prevent Subversion support from creating a + ~/.subversion directory just for checking the presence of a + Subversion repository. + + * Issue #12(2): Namespace packages are now imported lazily. That is, + the mere declaration of a namespace package in an egg on ‘sys.path’ + no longer causes it to be imported when ‘pkg_resources’ is + imported. Note that this change means that all of a namespace + package’s ‘__init__.py’ files must include a ‘declare_namespace()’ + call in order to ensure that they will be handled properly at + runtime. In 2.x it was possible to get away without including the + declaration, but only at the cost of forcing namespace packages to + be imported early, which 3.0 no longer does. + + * Issue #148(3): When building (bdist_egg), setuptools no longer adds + ‘__init__.py’ files to namespace packages. Any packages that rely + on this behavior will need to create ‘__init__.py’ files and + include the ‘declare_namespace()’. + + * Issue #7(4): Setuptools itself is now distributed as a zip archive + in addition to tar archive. ez_setup.py now uses zip archive. + This approach avoids the potential security vulnerabilities + presented by use of tar archives in ez_setup.py. It also leverages + the security features added to ZipFile.extract in Python 2.7.4. + + * Issue #65(5): Removed deprecated Features functionality. + + * BB Pull Request #28(6): Remove backport of ‘_bytecode_filenames’ + which is available in Python 2.6 and later, but also has better + compatibility with Python 3 environments. + + * Issue #156(7): Fix spelling of __PYVENV_LAUNCHER__ variable. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/125 + + (2) https://github.com/pypa/setuptools/issues/12 + + (3) https://github.com/pypa/setuptools/issues/148 + + (4) https://github.com/pypa/setuptools/issues/7 + + (5) https://github.com/pypa/setuptools/issues/65 + + (6) https://bitbucket.org/pypa/setuptools/pull-request/28 + + (7) https://github.com/pypa/setuptools/issues/156 + + +File: setuptools.info, Node: 2 2, Next: 2 1 2, Prev: 3 0, Up: History<2> + +9.352 2.2 +========= + +07 Feb 2014 + + * Issue #141(1): Restored fix for allowing setup_requires + dependencies to override installed dependencies during setup. + + * Issue #128(2): Fixed issue where only the first dependency link was + honored in a distribution where multiple dependency links were + supplied. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/141 + + (2) https://github.com/pypa/setuptools/issues/128 + + +File: setuptools.info, Node: 2 1 2, Next: 2 1 1, Prev: 2 2, Up: History<2> + +9.353 2.1.2 +=========== + +05 Feb 2014 + + * Issue #144(1): Read long_description using codecs module to avoid + errors installing on systems where LANG=C. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/144 + + +File: setuptools.info, Node: 2 1 1, Next: 2 1, Prev: 2 1 2, Up: History<2> + +9.354 2.1.1 +=========== + +05 Feb 2014 + + * Issue #139(1): Fix regression in re_finder for CVS repos (and maybe + Git repos as well). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/139 + + +File: setuptools.info, Node: 2 1, Next: 2 0 2, Prev: 2 1 1, Up: History<2> + +9.355 2.1 +========= + +07 Jan 2014 + + * Issue #129(1): Suppress inspection of ‘*.whl’ files when searching + for files in a zip-imported file. + + * Issue #131(2): Fix RuntimeError when constructing an egg fetcher. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/129 + + (2) https://github.com/pypa/setuptools/issues/131 + + +File: setuptools.info, Node: 2 0 2, Next: 2 0 1, Prev: 2 1, Up: History<2> + +9.356 2.0.2 +=========== + +29 Dec 2013 + + * Fix NameError during installation with Python implementations (e.g. + Jython) not containing parser module. + + * Fix NameError in ‘sdist:re_finder’. + + +File: setuptools.info, Node: 2 0 1, Next: 2 0, Prev: 2 0 2, Up: History<2> + +9.357 2.0.1 +=========== + +15 Dec 2013 + + * Issue #124(1): Fixed error in list detection in upload_docs. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/124 + + +File: setuptools.info, Node: 2 0, Next: 1 4 2, Prev: 2 0 1, Up: History<2> + +9.358 2.0 +========= + +07 Dec 2013 + + * Issue #121(1): Exempt lib2to3 pickled grammars from + DirectorySandbox. + + * Issue #41(2): Dropped support for Python 2.4 and Python 2.5. + Clients requiring setuptools for those versions of Python should + use setuptools 1.x. + + * Removed ‘setuptools.command.easy_install.HAS_USER_SITE’. Clients + expecting this boolean variable should use ‘site.ENABLE_USER_SITE’ + instead. + + * Removed ‘pkg_resources.ImpWrapper’. Clients that expected this + class should use ‘pkgutil.ImpImporter’ instead. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/121 + + (2) https://github.com/pypa/setuptools/issues/41 + + +File: setuptools.info, Node: 1 4 2, Next: 1 4 1, Prev: 2 0, Up: History<2> + +9.359 1.4.2 +=========== + +01 Dec 2013 + + * Issue #116(1): Correct TypeError when reading a local package index + on Python 3. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/116 + + +File: setuptools.info, Node: 1 4 1, Next: 1 4, Prev: 1 4 2, Up: History<2> + +9.360 1.4.1 +=========== + +23 Nov 2013 + + * Issue #114(1): Use ‘sys.getfilesystemencoding’ for decoding config + in ‘bdist_wininst’ distributions. + + * Issue #105(2) and Issue #113(3): Establish a more robust technique + for determining the terminal encoding: + + 1. Try ``getpreferredencoding`` + 2. If that returns US_ASCII or None, try the encoding from + ``getdefaultlocale``. If that encoding was a "fallback" because Python + could not figure it out from the environment or OS, encoding remains + unresolved. + 3. If the encoding is resolved, then make sure Python actually implements + the encoding. + 4. On the event of an error or unknown codec, revert to fallbacks + (UTF-8 on Darwin, ASCII on everything else). + 5. On the encoding is 'mac-roman' on Darwin, use UTF-8 as 'mac-roman' was + a bug on older Python releases. + + On a side note, it would seem that the encoding only matters for when SVN + does not yet support ``--xml`` and when getting repository and svn version + numbers. The ``--xml`` technique should yield UTF-8 according to some + messages on the SVN mailing lists. So if the version numbers are always + 7-bit ASCII clean, it may be best to only support the file parsing methods + for legacy SVN releases and support for SVN without the subprocess command + would simple go away as support for the older SVNs does. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/114 + + (2) https://github.com/pypa/setuptools/issues/105 + + (3) https://github.com/pypa/setuptools/issues/113 + + +File: setuptools.info, Node: 1 4, Next: 1 3 2, Prev: 1 4 1, Up: History<2> + +9.361 1.4 +========= + +17 Nov 2013 + + * Issue #27(1): ‘easy_install’ will now use credentials from .pypirc + if present for connecting to the package index. + + * BB Pull Request #21(2): Omit unwanted newlines in + ‘package_index._encode_auth’ when the username/password pair length + indicates wrapping. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/27 + + (2) https://bitbucket.org/pypa/setuptools/pull-request/21 + + +File: setuptools.info, Node: 1 3 2, Next: 1 3 1, Prev: 1 4, Up: History<2> + +9.362 1.3.2 +=========== + +09 Nov 2013 + + * Issue #99(1): Fix filename encoding issues in SVN support. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/99 + + +File: setuptools.info, Node: 1 3 1, Next: 1 3, Prev: 1 3 2, Up: History<2> + +9.363 1.3.1 +=========== + +07 Nov 2013 + + * Remove exuberant warning in SVN support when SVN is not used. + + +File: setuptools.info, Node: 1 3, Next: 1 2, Prev: 1 3 1, Up: History<2> + +9.364 1.3 +========= + +03 Nov 2013 + + * Address security vulnerability in SSL match_hostname check as + reported in Python #17997(1). + + * Prefer backports.ssl_match_hostname(2) for backport implementation + if present. + + * Correct NameError in ‘ssl_support’ module (‘socket.error’). + + ---------- Footnotes ---------- + + (1) http://bugs.python.org/issue17997 + + (2) https://pypi.org/project/backports.ssl_match_hostname/ + + +File: setuptools.info, Node: 1 2, Next: 1 1 7, Prev: 1 3, Up: History<2> + +9.365 1.2 +========= + +02 Nov 2013 + + * Issue #26(1): Add support for SVN 1.7. Special thanks to Philip + Thiem for the contribution. + + * Issue #93(2): Wheels are now distributed with every release. Note + that as reported in Issue #108(3), as of Pip 1.4, scripts aren’t + installed properly from wheels. Therefore, if using Pip to install + setuptools from a wheel, the ‘easy_install’ command will not be + available. + + * Setuptools “natural” launcher support, introduced in 1.0, is now + officially supported. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/26 + + (2) https://github.com/pypa/setuptools/issues/93 + + (3) https://github.com/pypa/setuptools/issues/108 + + +File: setuptools.info, Node: 1 1 7, Next: 1 1 6, Prev: 1 2, Up: History<2> + +9.366 1.1.7 +=========== + +11 Apr 2013 + + * Fixed behavior of NameError handling in ‘script template (dev).py’ + (script launcher for ‘develop’ installs). + + * ‘ez_setup.py’ now ensures partial downloads are cleaned up + following a failed download. + + * Distribute #363(1) and Issue #55(2): Skip an sdist test that fails + on locales other than UTF-8. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/363 + + (2) https://github.com/pypa/setuptools/issues/55 + + +File: setuptools.info, Node: 1 1 6, Next: 1 1 5, Prev: 1 1 7, Up: History<2> + +9.367 1.1.6 +=========== + +18 Sep 2013 + + * Distribute #349(1): ‘sandbox.execfile’ now opens the target file in + binary mode, thus honoring a BOM in the file when compiled. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/349 + + +File: setuptools.info, Node: 1 1 5, Next: 1 1 4, Prev: 1 1 6, Up: History<2> + +9.368 1.1.5 +=========== + +12 Sep 2013 + + * Issue #69(1): Second attempt at fix (logic was reversed). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/69 + + +File: setuptools.info, Node: 1 1 4, Next: 1 1 3, Prev: 1 1 5, Up: History<2> + +9.369 1.1.4 +=========== + +07 Sep 2013 + + * Issue #77(1): Fix error in upload command (Python 2.4). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/77 + + +File: setuptools.info, Node: 1 1 3, Next: 1 1 2, Prev: 1 1 4, Up: History<2> + +9.370 1.1.3 +=========== + +06 Sep 2013 + + * Fix NameError in previous patch. + + +File: setuptools.info, Node: 1 1 2, Next: 1 1 1, Prev: 1 1 3, Up: History<2> + +9.371 1.1.2 +=========== + +06 Sep 2013 + + * Issue #69(1): Correct issue where 404 errors are returned for URLs + with fragments in them (such as #egg=). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/69 + + +File: setuptools.info, Node: 1 1 1, Next: 1 1, Prev: 1 1 2, Up: History<2> + +9.372 1.1.1 +=========== + +03 Sep 2013 + + * Issue #75(1): Add ‘--insecure’ option to ez_setup.py to accommodate + environments where a trusted SSL connection cannot be validated. + + * Issue #76(2): Fix AttributeError in upload command with Python 2.4. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/75 + + (2) https://github.com/pypa/setuptools/issues/76 + + +File: setuptools.info, Node: 1 1, Next: 1 0, Prev: 1 1 1, Up: History<2> + +9.373 1.1 +========= + +26 Aug 2013 + + * Issue #71(1) (Distribute #333(2)): EasyInstall now puts less + emphasis on the condition when a host is blocked via + ‘--allow-hosts’. + + * Issue #72(3): Restored Python 2.4 compatibility in ‘ez_setup.py’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/71 + + (2) https://bitbucket.org/tarek/distribute/issue/333 + + (3) https://github.com/pypa/setuptools/issues/72 + + +File: setuptools.info, Node: 1 0, Next: 0 9 8, Prev: 1 1, Up: History<2> + +9.374 1.0 +========= + +17 Aug 2013 + + * Issue #60(1): On Windows, Setuptools supports deferring to another + launcher, such as Vinay Sajip’s pylauncher(2) (included with Python + 3.3) to launch console and GUI scripts and not install its own + launcher executables. This experimental functionality is currently + only enabled if the ‘SETUPTOOLS_LAUNCHER’ environment variable is + set to “natural”. In the future, this behavior may become default, + but only after it has matured and seen substantial adoption. The + ‘SETUPTOOLS_LAUNCHER’ also accepts “executable” to force the + default behavior of creating launcher executables. + + * Issue #63(3): Bootstrap script (ez_setup.py) now prefers + Powershell, curl, or wget for retrieving the Setuptools tarball for + improved security of the install. The script will still fall back + to a simple ‘urlopen’ on platforms that do not have these tools. + + * Issue #65(4): Deprecated the ‘Features’ functionality. + + * Issue #52(5): In ‘VerifyingHTTPSConn’, handle a tunnelled (proxied) + connection. + +* Menu: + +* Backward-Incompatible Changes:: + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/60 + + (2) https://bitbucket.org/pypa/pylauncher + + (3) https://github.com/pypa/setuptools/issues/63 + + (4) https://github.com/pypa/setuptools/issues/65 + + (5) https://github.com/pypa/setuptools/issues/52 + + +File: setuptools.info, Node: Backward-Incompatible Changes, Up: 1 0 + +9.374.1 Backward-Incompatible Changes +------------------------------------- + +This release includes a couple of backward-incompatible changes, but +most if not all users will find 1.0 a drop-in replacement for 0.9. + + * Issue #50(1): Normalized API of environment marker support. + Specifically, removed line number and filename from SyntaxErrors + when returned from ‘pkg_resources.invalid_marker’. Any clients + depending on the specific string representation of exceptions + returned by that function may need to be updated to account for + this change. + + * Issue #50(2): SyntaxErrors generated by + ‘pkg_resources.invalid_marker’ are normalized for + cross-implementation consistency. + + * Removed ‘--ignore-conflicts-at-my-risk’ and ‘--delete-conflicting’ + options to easy_install. These options have been deprecated since + 0.6a11. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/50 + + (2) https://github.com/pypa/setuptools/issues/50 + + +File: setuptools.info, Node: 0 9 8, Next: 0 9 7, Prev: 1 0, Up: History<2> + +9.375 0.9.8 +=========== + +25 Jul 2013 + + * Issue #53(1): Fix NameErrors in ‘_vcs_split_rev_from_url’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/53 + + +File: setuptools.info, Node: 0 9 7, Next: 0 9 6, Prev: 0 9 8, Up: History<2> + +9.376 0.9.7 +=========== + +22 Jul 2013 + + * Issue #49(1): Correct AttributeError on PyPy where a hashlib.HASH + object does not have a ‘.name’ attribute. + + * Issue #34(2): Documentation now refers to bootstrap script in code + repository referenced by bookmark. + + * Add underscore-separated keys to environment markers (markerlib). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/49 + + (2) https://github.com/pypa/setuptools/issues/34 + + +File: setuptools.info, Node: 0 9 6, Next: 0 9 5, Prev: 0 9 7, Up: History<2> + +9.377 0.9.6 +=========== + +17 Jul 2013 + + * Issue #44(1): Test failure on Python 2.4 when MD5 hash doesn’t have + a ‘.name’ attribute. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/44 + + +File: setuptools.info, Node: 0 9 5, Next: 0 9 4, Prev: 0 9 6, Up: History<2> + +9.378 0.9.5 +=========== + +15 Jul 2013 + + * Python #17980(1): Fix security vulnerability in SSL certificate + validation. + + ---------- Footnotes ---------- + + (1) http://bugs.python.org/issue17980 + + +File: setuptools.info, Node: 0 9 4, Next: 0 9 3, Prev: 0 9 5, Up: History<2> + +9.379 0.9.4 +=========== + +15 Jul 2013 + + * Issue #43(1): Fix issue (introduced in 0.9.1) with version + resolution when upgrading over other releases of Setuptools. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/43 + + +File: setuptools.info, Node: 0 9 3, Next: 0 9 2, Prev: 0 9 4, Up: History<2> + +9.380 0.9.3 +=========== + +15 Jul 2013 + + * Issue #42(1): Fix new ‘AttributeError’ introduced in last fix. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/42 + + +File: setuptools.info, Node: 0 9 2, Next: 0 9 1, Prev: 0 9 3, Up: History<2> + +9.381 0.9.2 +=========== + +15 Jul 2013 + + * Issue #42(1): Fix regression where blank checksums would trigger an + ‘AttributeError’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/42 + + +File: setuptools.info, Node: 0 9 1, Next: 0 9, Prev: 0 9 2, Up: History<2> + +9.382 0.9.1 +=========== + +13 Jul 2013 + + * Distribute #386(1): Allow other positional and keyword arguments to + os.open. + + * Corrected dependency on certifi mis-referenced in 0.9. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/386 + + +File: setuptools.info, Node: 0 9, Next: 0 8, Prev: 0 9 1, Up: History<2> + +9.383 0.9 +========= + +13 Jul 2013 + + * ‘package_index’ now validates hashes other than MD5 in download + links. + + +File: setuptools.info, Node: 0 8, Next: 0 7 8, Prev: 0 9, Up: History<2> + +9.384 0.8 +========= + +05 Jul 2013 + + * Code base now runs on Python 2.4 - Python 3.3 without Python 2to3 + conversion. + + +File: setuptools.info, Node: 0 7 8, Next: 0 7 7, Prev: 0 8, Up: History<2> + +9.385 0.7.8 +=========== + +04 Jul 2013 + + * Distribute #375(1): Yet another fix for yet another regression. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/375 + + +File: setuptools.info, Node: 0 7 7, Next: 0 7 6, Prev: 0 7 8, Up: History<2> + +9.386 0.7.7 +=========== + +02 Jul 2013 + + * Distribute #375(1): Repair AttributeError created in last release + (redo). + + * Issue #30(2): Added test for get_cache_path. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/375 + + (2) https://github.com/pypa/setuptools/issues/30 + + +File: setuptools.info, Node: 0 7 6, Next: 0 7 5, Prev: 0 7 7, Up: History<2> + +9.387 0.7.6 +=========== + +02 Jul 2013 + + * Distribute #375(1): Repair AttributeError created in last release. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/375 + + +File: setuptools.info, Node: 0 7 5, Next: 0 7 4, Prev: 0 7 6, Up: History<2> + +9.388 0.7.5 +=========== + +29 Jun 2013 + + * Issue #21(1): Restore Python 2.4 compatibility in + ‘test_easy_install’. + + * Distribute #375(2): Merged additional warning from Distribute + 0.6.46. + + * Now honor the environment variable + ‘SETUPTOOLS_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT’ in addition to + the now deprecated + ‘DISTRIBUTE_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT’. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/21 + + (2) https://bitbucket.org/tarek/distribute/issue/375 + + +File: setuptools.info, Node: 0 7 4, Next: 0 7 3, Prev: 0 7 5, Up: History<2> + +9.389 0.7.4 +=========== + +19 Jun 2013 + + * Issue #20(1): Fix comparison of parsed SVN version on Python 3. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/20 + + +File: setuptools.info, Node: 0 7 3, Next: 0 7 2, Prev: 0 7 4, Up: History<2> + +9.390 0.7.3 +=========== + +18 Jun 2013 + + * Issue #1(1): Disable installation of Windows-specific files on + non-Windows systems. + + * Use new sysconfig module with Python 2.7 or >=3.2. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/1 + + +File: setuptools.info, Node: 0 7 2, Next: 0 7 1, Prev: 0 7 3, Up: History<2> + +9.391 0.7.2 +=========== + +09 Jun 2013 + + * Issue #14(1): Use markerlib when the ‘parser’ module is not + available. + + * Issue #10(2): ‘ez_setup.py’ now uses HTTPS to download setuptools + from PyPI. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/14 + + (2) https://github.com/pypa/setuptools/issues/10 + + +File: setuptools.info, Node: 0 7 1, Next: 0 7, Prev: 0 7 2, Up: History<2> + +9.392 0.7.1 +=========== + +03 Jun 2013 + + * Fix NameError (Issue #3(1)) again - broken in bad merge. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/3 + + +File: setuptools.info, Node: 0 7, Next: 0 7b4, Prev: 0 7 1, Up: History<2> + +9.393 0.7 +========= + +02 Jun 2013 + + * Merged Setuptools and Distribute. See docs/merge.txt for details. + +Added several features that were slated for setuptools 0.6c12: + + * Index URL now defaults to HTTPS. + + * Added experimental environment marker support. Now clients may + designate a PEP-426(1) environment marker for “extra” dependencies. + Setuptools uses this feature in ‘setup.py’ for optional SSL and + certificate validation support on older platforms. Based on + Distutils-SIG discussions, the syntax is somewhat tentative. There + should probably be a PEP with a firmer spec before the feature + should be considered suitable for use. + + * Added support for SSL certificate validation when installing + packages from an HTTPS service. + + ---------- Footnotes ---------- + + (1) https://www.python.org/dev/peps/pep-0426/ + + +File: setuptools.info, Node: 0 7b4, Next: 0 6 49, Prev: 0 7, Up: History<2> + +9.394 0.7b4 +=========== + + * Issue #3(1): Fixed NameError in SSL support. + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/3 + + +File: setuptools.info, Node: 0 6 49, Next: 0 6 48, Prev: 0 7b4, Up: History<2> + +9.395 0.6.49 +============ + +04 Jul 2013 + + * Move warning check in ‘get_cache_path’ to follow the directory + creation to avoid errors when the cache path does not yet exist. + Fixes the error reported in Distribute #375(1). + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/375 + + +File: setuptools.info, Node: 0 6 48, Next: 0 6 47, Prev: 0 6 49, Up: History<2> + +9.396 0.6.48 +============ + +02 Jul 2013 + + * Correct AttributeError in ‘ResourceManager.get_cache_path’ + introduced in 0.6.46 (redo). + + +File: setuptools.info, Node: 0 6 47, Next: 0 6 46, Prev: 0 6 48, Up: History<2> + +9.397 0.6.47 +============ + +02 Jul 2013 + + * Correct AttributeError in ‘ResourceManager.get_cache_path’ + introduced in 0.6.46. + + +File: setuptools.info, Node: 0 6 46, Next: 0 6 45, Prev: 0 6 47, Up: History<2> + +9.398 0.6.46 +============ + +29 Jun 2013 + + * Distribute #375(1): Issue a warning if the PYTHON_EGG_CACHE or + otherwise customized egg cache location specifies a directory + that’s group- or world-writable. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/375 + + +File: setuptools.info, Node: 0 6 45, Next: 0 6 44, Prev: 0 6 46, Up: History<2> + +9.399 0.6.45 +============ + +29 May 2013 + + * Distribute #379(1): ‘distribute_setup.py’ now traps VersionConflict + as well, restoring ability to upgrade from an older setuptools + version. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/379 + + +File: setuptools.info, Node: 0 6 44, Next: 0 6 43, Prev: 0 6 45, Up: History<2> + +9.400 0.6.44 +============ + +28 May 2013 + + * ‘distribute_setup.py’ has been updated to allow Setuptools 0.7 to + satisfy use_setuptools. + + +File: setuptools.info, Node: 0 6 43, Next: 0 6 42, Prev: 0 6 44, Up: History<2> + +9.401 0.6.43 +============ + +24 May 2013 + + * Distribute #378(1): Restore support for Python 2.4 Syntax + (regression in 0.6.42). + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/378 + + +File: setuptools.info, Node: 0 6 42, Next: 0 6 41, Prev: 0 6 43, Up: History<2> + +9.402 0.6.42 +============ + +24 May 2013 + + * External links finder no longer yields duplicate links. + + * Distribute #337(1): Moved site.py to setuptools/site-patch.py + (graft of very old patch from setuptools trunk which inspired PR + #31(2)). + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/337 + + (2) https://github.com/pypa/setuptools/issues/31 + + +File: setuptools.info, Node: 0 6 41, Next: 0 6 40, Prev: 0 6 42, Up: History<2> + +9.403 0.6.41 +============ + +24 May 2013 + + * Distribute #27(1): Use public api for loading resources from zip + files rather than the private method ‘_zip_directory_cache’. + + * Added a new function ‘easy_install.get_win_launcher’ which may be + used by third-party libraries such as buildout to get a suitable + script launcher. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/27 + + +File: setuptools.info, Node: 0 6 40, Next: 0 6 39, Prev: 0 6 41, Up: History<2> + +9.404 0.6.40 +============ + +14 May 2013 + + * Distribute #376(1): brought back cli.exe and gui.exe that were + deleted in the previous release. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/376 + + +File: setuptools.info, Node: 0 6 39, Next: 0 6 38, Prev: 0 6 40, Up: History<2> + +9.405 0.6.39 +============ + +12 May 2013 + + * Add support for console launchers on ARM platforms. + + * Fix possible issue in GUI launchers where the subsystem was not + supplied to the linker. + + * Launcher build script now refactored for robustness. + + * Distribute #375(1): Resources extracted from a zip egg to the file + system now also check the contents of the file against the zip + contents during each invocation of get_resource_filename. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/375 + + +File: setuptools.info, Node: 0 6 38, Next: 0 6 37, Prev: 0 6 39, Up: History<2> + +9.406 0.6.38 +============ + +05 May 2013 + + * Distribute #371(1): The launcher manifest file is now installed + properly. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/371 + + +File: setuptools.info, Node: 0 6 37, Next: 0 6 36, Prev: 0 6 38, Up: History<2> + +9.407 0.6.37 +============ + +04 May 2013 + + * Distribute #143(1): Launcher scripts, including easy_install + itself, are now accompanied by a manifest on 32-bit Windows + environments to avoid the Installer Detection Technology and thus + undesirable UAC elevation described in this Microsoft article(2). + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/143 + + (2) +http://technet.microsoft.com/en-us/library/cc709628%28WS.10%29.aspx + + +File: setuptools.info, Node: 0 6 36, Next: 0 6 35, Prev: 0 6 37, Up: History<2> + +9.408 0.6.36 +============ + +05 Apr 2013 + + * BB Pull Request #35(1): In Buildout #64(2), it was reported that + under Python 3, installation of distutils scripts could attempt to + copy the ‘__pycache__’ directory as a file, causing an error, + apparently only under Windows. Easy_install now skips all + directories when processing metadata scripts. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/35 + + (2) https://github.com/buildout/buildout/issues/64 + + +File: setuptools.info, Node: 0 6 35, Next: 0 6 34, Prev: 0 6 36, Up: History<2> + +9.409 0.6.35 +============ + +16 Feb 2013 + +Note this release is backward-incompatible with distribute 0.6.23-0.6.34 +in how it parses version numbers. + + * Distribute #278(1): Restored compatibility with distribute 0.6.22 + and setuptools 0.6. Updated the documentation to match more + closely with the version parsing as intended in setuptools 0.6. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/278 + + +File: setuptools.info, Node: 0 6 34, Next: 0 6 33, Prev: 0 6 35, Up: History<2> + +9.410 0.6.34 +============ + +30 Dec 2012 + + * Distribute #341(1): 0.6.33 fails to build under Python 2.4. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/341 + + +File: setuptools.info, Node: 0 6 33, Next: 0 6 32, Prev: 0 6 34, Up: History<2> + +9.411 0.6.33 +============ + +29 Dec 2012 + + * Fix 2 errors with Jython 2.5. + + * Fix 1 failure with Jython 2.5 and 2.7. + + * Disable workaround for Jython scripts on Linux systems. + + * Distribute #336(1): ‘setup.py’ no longer masks failure exit code + when tests fail. + + * Fix issue in pkg_resources where try/except around a + platform-dependent import would trigger hook load failures on + Mercurial. See pull request 32 for details. + + * Distribute #341(2): Fix a ResourceWarning. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/336 + + (2) https://bitbucket.org/tarek/distribute/issue/341 + + +File: setuptools.info, Node: 0 6 32, Next: 0 6 31, Prev: 0 6 33, Up: History<2> + +9.412 0.6.32 +============ + +26 Nov 2012 + + * Fix test suite with Python 2.6. + + * Fix some DeprecationWarnings and ResourceWarnings. + + * Distribute #335(1): Backed out ‘setup_requires’ superceding + installed requirements until regression can be addressed. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/335 + + +File: setuptools.info, Node: 0 6 31, Next: 0 6 30, Prev: 0 6 32, Up: History<2> + +9.413 0.6.31 +============ + +24 Nov 2012 + + * Distribute #303(1): Make sure the manifest only ever contains UTF-8 + in Python 3. + + * Distribute #329(2): Properly close files created by tests for + compatibility with Jython. + + * Work around Jython #1980(3) and Jython #1981(4). + + * Distribute #334(5): Provide workaround for packages that reference + ‘sys.__stdout__’ such as numpy does. This change should address + virtualenv ‘#359(6) + <‘https://github.com/pypa/virtualenv/issues/359’>‘_ as long as the + system encoding is UTF-8 or the IO encoding is specified in the + environment, i.e.: + + PYTHONIOENCODING=utf8 pip install numpy + + * Fix for encoding issue when installing from Windows executable on + Python 3. + + * Distribute #323(7): Allow ‘setup_requires’ requirements to + supercede installed requirements. Added some new keyword arguments + to existing pkg_resources methods. Also had to updated how + __path__ is handled for namespace packages to ensure that when a + new egg distribution containing a namespace package is placed on + sys.path, the entries in __path__ are found in the same order they + would have been in had that egg been on the path when pkg_resources + was first imported. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/303 + + (2) https://bitbucket.org/tarek/distribute/issue/329 + + (3) http://bugs.jython.org/issue1980 + + (4) http://bugs.jython.org/issue1981 + + (5) https://bitbucket.org/tarek/distribute/issue/334 + + (6) https://github.com/pypa/setuptools/issues/359 + + (7) https://bitbucket.org/tarek/distribute/issue/323 + + +File: setuptools.info, Node: 0 6 30, Next: 0 6 29, Prev: 0 6 31, Up: History<2> + +9.414 0.6.30 +============ + +22 Oct 2012 + + * Distribute #328(1): Clean up temporary directories in + distribute_setup.py. + + * Fix fatal bug in distribute_setup.py. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/328 + + +File: setuptools.info, Node: 0 6 29, Next: 0 6 28, Prev: 0 6 30, Up: History<2> + +9.415 0.6.29 +============ + +21 Oct 2012 + + * BB Pull Request #14(1): Honor file permissions in zip files. + + * Distribute #327(2): Merged pull request #24(3) to fix a dependency + problem with pip. + + * Merged pull request #23(4) to fix + ‘https://github.com/pypa/virtualenv/issues/301’. + + * If Sphinx is installed, the ‘upload_docs’ command now runs + ‘build_sphinx’ to produce uploadable documentation. + + * Distribute #326(5): ‘upload_docs’ provided mangled auth credentials + under Python 3. + + * Distribute #320(6): Fix check for “createable” in + distribute_setup.py. + + * Distribute #305(7): Remove a warning that was triggered during + normal operations. + + * Distribute #311(8): Print metadata in UTF-8 independent of + platform. + + * Distribute #303(9): Read manifest file with UTF-8 encoding under + Python 3. + + * Distribute #301(10): Allow to run tests of namespace packages when + using 2to3. + + * Distribute #304(11): Prevent import loop in site.py under Python + 3.3. + + * Distribute #283(12): Reenable scanning of ‘*.pyc’ / ‘*.pyo’ files + on Python 3.3. + + * Distribute #299(13): The develop command didn’t work on Python 3, + when using 2to3, as the egg link would go to the Python 2 source. + Linking to the 2to3’d code in build/lib makes it work, although you + will have to rebuild the module before testing it. + + * Distribute #306(14): Even if 2to3 is used, we build in-place under + Python 2. + + * Distribute #307(15): Prints the full path when .svn/entries is + broken. + + * Distribute #313(16): Support for sdist subcommands (Python 2.7) + + * Distribute #314(17): test_local_index() would fail an OS X. + + * Distribute #310(18): Non-ascii characters in a namespace + __init__.py causes errors. + + * Distribute #218(19): Improved documentation on behavior of + ‘package_data’ and ‘include_package_data’. Files indicated by + ‘package_data’ are now included in the manifest. + + * ‘distribute_setup.py’ now allows a ‘--download-base’ argument for + retrieving distribute from a specified location. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/pypa/setuptools/pull-request/14 + + (2) https://bitbucket.org/tarek/distribute/issue/327 + + (3) https://github.com/pypa/setuptools/issues/24 + + (4) https://github.com/pypa/setuptools/issues/23 + + (5) https://bitbucket.org/tarek/distribute/issue/326 + + (6) https://bitbucket.org/tarek/distribute/issue/320 + + (7) https://bitbucket.org/tarek/distribute/issue/305 + + (8) https://bitbucket.org/tarek/distribute/issue/311 + + (9) https://bitbucket.org/tarek/distribute/issue/303 + + (10) https://bitbucket.org/tarek/distribute/issue/301 + + (11) https://bitbucket.org/tarek/distribute/issue/304 + + (12) https://bitbucket.org/tarek/distribute/issue/283 + + (13) https://bitbucket.org/tarek/distribute/issue/299 + + (14) https://bitbucket.org/tarek/distribute/issue/306 + + (15) https://bitbucket.org/tarek/distribute/issue/307 + + (16) https://bitbucket.org/tarek/distribute/issue/313 + + (17) https://bitbucket.org/tarek/distribute/issue/314 + + (18) https://bitbucket.org/tarek/distribute/issue/310 + + (19) https://bitbucket.org/tarek/distribute/issue/218 + + +File: setuptools.info, Node: 0 6 28, Next: 0 6 27, Prev: 0 6 29, Up: History<2> + +9.416 0.6.28 +============ + +22 Jul 2012 + + * Distribute #294(1): setup.py can now be invoked from any directory. + + * Scripts are now installed honoring the umask. + + * Added support for .dist-info directories. + + * Distribute #283(2): Fix and disable scanning of ‘*.pyc’ / ‘*.pyo’ + files on Python 3.3. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/294 + + (2) https://bitbucket.org/tarek/distribute/issue/283 + + +File: setuptools.info, Node: 0 6 27, Next: 0 6 26, Prev: 0 6 28, Up: History<2> + +9.417 0.6.27 +============ + +18 May 2012 + + * Support current snapshots of CPython 3.3. + + * Distribute now recognizes README.rst as a standard, default readme + file. + + * Exclude ‘encodings’ modules when removing modules from sys.modules. + Workaround for #285(1). + + * Distribute #231(2): Don’t fiddle with system python when used with + buildout (bootstrap.py) + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/285 + + (2) https://bitbucket.org/tarek/distribute/issue/231 + + +File: setuptools.info, Node: 0 6 26, Next: 0 6 25, Prev: 0 6 27, Up: History<2> + +9.418 0.6.26 +============ + +08 Apr 2012 + + * Distribute #183(1): Symlinked files are now extracted from source + distributions. + + * Distribute #227(2): Easy_install fetch parameters are now passed + during the installation of a source distribution; now fulfillment + of setup_requires dependencies will honor the parameters passed to + easy_install. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/183 + + (2) https://bitbucket.org/tarek/distribute/issue/227 + + +File: setuptools.info, Node: 0 6 25, Next: 0 6 24, Prev: 0 6 26, Up: History<2> + +9.419 0.6.25 +============ + +08 Feb 2012 + + * Distribute #258(1): Workaround a cache issue + + * Distribute #260(2): distribute_setup.py now accepts the –user + parameter for Python 2.6 and later. + + * Distribute #262(3): package_index.open_with_auth no longer throws + LookupError on Python 3. + + * Distribute #269(4): AttributeError when an exception occurs reading + Manifest.in on late releases of Python. + + * Distribute #272(5): Prevent TypeError when namespace package names + are unicode and single-install-externally-managed is used. Also + fixes PIP issue 449. + + * Distribute #273(6): Legacy script launchers now install with + Python2/3 support. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/258 + + (2) https://bitbucket.org/tarek/distribute/issue/260 + + (3) https://bitbucket.org/tarek/distribute/issue/262 + + (4) https://bitbucket.org/tarek/distribute/issue/269 + + (5) https://bitbucket.org/tarek/distribute/issue/272 + + (6) https://bitbucket.org/tarek/distribute/issue/273 + + +File: setuptools.info, Node: 0 6 24, Next: 0 6 23, Prev: 0 6 25, Up: History<2> + +9.420 0.6.24 +============ + +14 Oct 2011 + + * Distribute #249(1): Added options to exclude 2to3 fixers + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/249 + + +File: setuptools.info, Node: 0 6 23, Next: 0 6 21, Prev: 0 6 24, Up: History<2> + +9.421 0.6.23 +============ + +22 Sep 2011 + + * Distribute #244(1): Fixed a test + + * Distribute #243(2): Fixed a test + + * Distribute #239(3): Fixed a test + + * Distribute #240(4): Fixed a test + + * Distribute #241(5): Fixed a test + + * Distribute #237(6): Fixed a test + + * Distribute #238(7): easy_install now uses 64bit executable wrappers + on 64bit Python + + * Distribute #208(8): Fixed parsed_versions, it now honors + post-releases as noted in the documentation + + * Distribute #207(9): Windows cli and gui wrappers pass CTRL-C to + child python process + + * Distribute #227(10): easy_install now passes its arguments to + setup.py bdist_egg + + * Distribute #225(11): Fixed a NameError on Python 2.5, 2.4 + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/244 + + (2) https://bitbucket.org/tarek/distribute/issue/243 + + (3) https://bitbucket.org/tarek/distribute/issue/239 + + (4) https://bitbucket.org/tarek/distribute/issue/240 + + (5) https://bitbucket.org/tarek/distribute/issue/241 + + (6) https://bitbucket.org/tarek/distribute/issue/237 + + (7) https://bitbucket.org/tarek/distribute/issue/238 + + (8) https://bitbucket.org/tarek/distribute/issue/208 + + (9) https://bitbucket.org/tarek/distribute/issue/207 + + (10) https://bitbucket.org/tarek/distribute/issue/227 + + (11) https://bitbucket.org/tarek/distribute/issue/225 + + +File: setuptools.info, Node: 0 6 21, Next: 0 6 20, Prev: 0 6 23, Up: History<2> + +9.422 0.6.21 +============ + +20 Aug 2011 + + * Distribute #225(1): FIxed a regression on py2.4 + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/225 + + +File: setuptools.info, Node: 0 6 20, Next: 0 6 19, Prev: 0 6 21, Up: History<2> + +9.423 0.6.20 +============ + +18 Aug 2011 + + * Distribute #135(1): Include url in warning when processing URLs in + package_index. + + * Distribute #212(2): Fix issue where easy_instal fails on Python 3 + on windows installer. + + * Distribute #213(3): Fix typo in documentation. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/135 + + (2) https://bitbucket.org/tarek/distribute/issue/212 + + (3) https://bitbucket.org/tarek/distribute/issue/213 + + +File: setuptools.info, Node: 0 6 19, Next: 0 6 18, Prev: 0 6 20, Up: History<2> + +9.424 0.6.19 +============ + +02 Jun 2011 + + * Distribute #206(1): AttributeError: ‘HTTPMessage’ object has no + attribute ‘getheaders’ + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/206 + + +File: setuptools.info, Node: 0 6 18, Next: 0 6 17, Prev: 0 6 19, Up: History<2> + +9.425 0.6.18 +============ + +01 Jun 2011 + + * Distribute #210(1): Fixed a regression introduced by Distribute + #204(2) fix. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/210 + + (2) https://bitbucket.org/tarek/distribute/issue/204 + + +File: setuptools.info, Node: 0 6 17, Next: 0 6 16, Prev: 0 6 18, Up: History<2> + +9.426 0.6.17 +============ + +30 May 2011 + + * Support ‘DISTRIBUTE_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT’ + environment variable to allow to disable installation of + easy_install-${version} script. + + * Support Python >=3.1.4 and >=3.2.1. + + * Distribute #204(1): Don’t try to import the parent of a namespace + package in declare_namespace + + * Distribute #196(2): Tolerate responses with multiple Content-Length + headers + + * Distribute #205(3): Sandboxing doesn’t preserve working_set. Leads + to setup_requires problems. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/204 + + (2) https://bitbucket.org/tarek/distribute/issue/196 + + (3) https://bitbucket.org/tarek/distribute/issue/205 + + +File: setuptools.info, Node: 0 6 16, Next: 0 6 15, Prev: 0 6 17, Up: History<2> + +9.427 0.6.16 +============ + +28 Apr 2011 + + * Builds sdist gztar even on Windows (avoiding Distribute #193(1)). + + * Distribute #192(2): Fixed metadata omitted on Windows when + package_dir specified with forward-slash. + + * Distribute #195(3): Cython build support. + + * Distribute #200(4): Issues with recognizing 64-bit packages on + Windows. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/193 + + (2) https://bitbucket.org/tarek/distribute/issue/192 + + (3) https://bitbucket.org/tarek/distribute/issue/195 + + (4) https://bitbucket.org/tarek/distribute/issue/200 + + +File: setuptools.info, Node: 0 6 15, Next: 0 6 14, Prev: 0 6 16, Up: History<2> + +9.428 0.6.15 +============ + +12 Mar 2011 + + * Fixed typo in bdist_egg + + * Several issues under Python 3 has been solved. + + * Distribute #146(1): Fixed missing DLL files after easy_install of + windows exe package. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/146 + + +File: setuptools.info, Node: 0 6 14, Next: 0 6 13, Prev: 0 6 15, Up: History<2> + +9.429 0.6.14 +============ + +15 Jul 2010 + + * Distribute #170(1): Fixed unittest failure. Thanks to Toshio. + + * Distribute #171(2): Fixed race condition in unittests cause + deadlocks in test suite. + + * Distribute #143(3): Fixed a lookup issue with easy_install. Thanks + to David and Zooko. + + * Distribute #174(4): Fixed the edit mode when its used with + setuptools itself + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/170 + + (2) https://bitbucket.org/tarek/distribute/issue/171 + + (3) https://bitbucket.org/tarek/distribute/issue/143 + + (4) https://bitbucket.org/tarek/distribute/issue/174 + + +File: setuptools.info, Node: 0 6 13, Next: 0 6 12, Prev: 0 6 14, Up: History<2> + +9.430 0.6.13 +============ + +31 May 2010 + + * Distribute #160(1): 2.7 gives ValueError(“Invalid IPv6 URL”) + + * Distribute #150(2): Fixed using ~/.local even in a + –no-site-packages virtualenv + + * Distribute #163(3): scan index links before external links, and + don’t use the md5 when comparing two distributions + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/160 + + (2) https://bitbucket.org/tarek/distribute/issue/150 + + (3) https://bitbucket.org/tarek/distribute/issue/163 + + +File: setuptools.info, Node: 0 6 12, Next: 0 6 11, Prev: 0 6 13, Up: History<2> + +9.431 0.6.12 +============ + +06 May 2010 + + * Distribute #149(1): Fixed various failures on 2.3/2.4 + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/149 + + +File: setuptools.info, Node: 0 6 11, Next: 0 6 10, Prev: 0 6 12, Up: History<2> + +9.432 0.6.11 +============ + +06 May 2010 + + * Found another case of SandboxViolation - fixed + + * Distribute #15(1) and Distribute #48(2): Introduced a socket + timeout of 15 seconds on url openings + + * Added indexsidebar.html into MANIFEST.in + + * Distribute #108(3): Fixed TypeError with Python3.1 + + * Distribute #121(4): Fixed –help install command trying to actually + install. + + * Distribute #112(5): Added an os.makedirs so that Tarek’s solution + will work. + + * Distribute #133(6): Added –no-find-links to easy_install + + * Added easy_install –user + + * Distribute #100(7): Fixed develop –user not taking ‘.’ in + PYTHONPATH into account + + * Distribute #134(8): removed spurious UserWarnings. Patch by + VanLindberg + + * Distribute #138(9): cant_write_to_target error when setup_requires + is used. + + * Distribute #147(10): respect the sys.dont_write_bytecode flag + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/15 + + (2) https://bitbucket.org/tarek/distribute/issue/48 + + (3) https://bitbucket.org/tarek/distribute/issue/108 + + (4) https://bitbucket.org/tarek/distribute/issue/121 + + (5) https://bitbucket.org/tarek/distribute/issue/112 + + (6) https://bitbucket.org/tarek/distribute/issue/133 + + (7) https://bitbucket.org/tarek/distribute/issue/100 + + (8) https://bitbucket.org/tarek/distribute/issue/134 + + (9) https://bitbucket.org/tarek/distribute/issue/138 + + (10) https://bitbucket.org/tarek/distribute/issue/147 + + +File: setuptools.info, Node: 0 6 10, Next: 0 6 9, Prev: 0 6 11, Up: History<2> + +9.433 0.6.10 +============ + +12 Dec 2009 + + * Reverted change made for the DistributionNotFound exception because + zc.buildout uses the exception message to get the name of the + distribution. + + +File: setuptools.info, Node: 0 6 9, Next: 0 6 8, Prev: 0 6 10, Up: History<2> + +9.434 0.6.9 +=========== + +12 Dec 2009 + + * Distribute #90(1): unknown setuptools version can be added in the + working set + + * Distribute #87(2): setupt.py doesn’t try to convert + distribute_setup.py anymore Initial Patch by arfrever. + + * Distribute #89(3): added a side bar with a download link to the + doc. + + * Distribute #86(4): fixed missing sentence in pkg_resources doc. + + * Added a nicer error message when a DistributionNotFound is raised. + + * Distribute #80(5): test_develop now works with Python 3.1 + + * Distribute #93(6): upload_docs now works if there is an empty + sub-directory. + + * Distribute #70(7): exec bit on non-exec files + + * Distribute #99(8): now the standalone easy_install command doesn’t + uses a “setup.cfg” if any exists in the working directory. It will + use it only if triggered by ‘install_requires’ from a setup.py call + (install, develop, etc). + + * Distribute #101(9): Allowing ‘os.devnull’ in Sandbox + + * Distribute #92(10): Fixed the “no eggs” found error with MacPort + (platform.mac_ver() fails) + + * Distribute #103(11): test_get_script_header_jython_workaround not + run anymore under py3 with C or POSIX local. Contributed by + Arfrever. + + * Distribute #104(12): remvoved the assertion when the installation + fails, with a nicer message for the end user. + + * Distribute #100(13): making sure there’s no SandboxViolation when + the setup script patches setuptools. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/90 + + (2) https://bitbucket.org/tarek/distribute/issue/87 + + (3) https://bitbucket.org/tarek/distribute/issue/89 + + (4) https://bitbucket.org/tarek/distribute/issue/86 + + (5) https://bitbucket.org/tarek/distribute/issue/80 + + (6) https://bitbucket.org/tarek/distribute/issue/93 + + (7) https://bitbucket.org/tarek/distribute/issue/70 + + (8) https://bitbucket.org/tarek/distribute/issue/99 + + (9) https://bitbucket.org/tarek/distribute/issue/101 + + (10) https://bitbucket.org/tarek/distribute/issue/92 + + (11) https://bitbucket.org/tarek/distribute/issue/103 + + (12) https://bitbucket.org/tarek/distribute/issue/104 + + (13) https://bitbucket.org/tarek/distribute/issue/100 + + +File: setuptools.info, Node: 0 6 8, Next: 0 6 7, Prev: 0 6 9, Up: History<2> + +9.435 0.6.8 +=========== + +01 Nov 2009 + + * Added “check_packages” in dist. (added in Setuptools 0.6c11) + + * Fixed the DONT_PATCH_SETUPTOOLS state. + + +File: setuptools.info, Node: 0 6 7, Next: 0 6 6, Prev: 0 6 8, Up: History<2> + +9.436 0.6.7 +=========== + +01 Nov 2009 + + * Distribute #58(1): Added –user support to the develop command + + * Distribute #11(2): Generated scripts now wrap their call to the + script entry point in the standard “if name == ‘main’” + + * Added the ‘DONT_PATCH_SETUPTOOLS’ environment variable, so + virtualenv can drive an installation that doesn’t patch a global + setuptools. + + * Reviewed unladen-swallow specific change from + ‘http://code.google.com/p/unladen-swallow/source/detail?spec=svn875&r=719’ + and determined that it no longer applies. Distribute should work + fine with Unladen Swallow 2009Q3. + + * Distribute #21(3): Allow PackageIndex.open_url to gracefully handle + all cases of a httplib.HTTPException instead of just InvalidURL and + BadStatusLine. + + * Removed virtual-python.py from this distribution and updated + documentation to point to the actively maintained virtualenv + instead. + + * Distribute #64(4): use_setuptools no longer rebuilds the distribute + egg every time it is run + + * use_setuptools now properly respects the requested version + + * use_setuptools will no longer try to import a distribute egg for + the wrong Python version + + * Distribute #74(5): no_fake should be True by default. + + * Distribute #72(6): avoid a bootstrapping issue with easy_install -U + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/58 + + (2) https://bitbucket.org/tarek/distribute/issue/11 + + (3) https://bitbucket.org/tarek/distribute/issue/21 + + (4) https://bitbucket.org/tarek/distribute/issue/64 + + (5) https://bitbucket.org/tarek/distribute/issue/74 + + (6) https://bitbucket.org/tarek/distribute/issue/72 + + +File: setuptools.info, Node: 0 6 6, Next: 0 6 5, Prev: 0 6 7, Up: History<2> + +9.437 0.6.6 +=========== + +15 Oct 2009 + + * Unified the bootstrap file so it works on both py2.x and py3k + without 2to3 (patch by Holger Krekel) + + +File: setuptools.info, Node: 0 6 5, Next: 0 6 4, Prev: 0 6 6, Up: History<2> + +9.438 0.6.5 +=========== + +15 Oct 2009 + + * Distribute #65(1): cli.exe and gui.exe are now generated at build + time, depending on the platform in use. + + * Distribute #67(2): Fixed doc typo (PEP 381(3)/PEP 382(4)). + + * Distribute no longer shadows setuptools if we require a 0.7-series + setuptools. And an error is raised when installing a 0.7 + setuptools with distribute. + + * When run from within buildout, no attempt is made to modify an + existing setuptools egg, whether in a shared egg directory or a + system setuptools. + + * Fixed a hole in sandboxing allowing builtin file to write outside + of the sandbox. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/65 + + (2) https://bitbucket.org/tarek/distribute/issue/67 + + (3) https://www.python.org/dev/peps/pep-0381/ + + (4) https://www.python.org/dev/peps/pep-0382/ + + +File: setuptools.info, Node: 0 6 4, Next: 0 6 3, Prev: 0 6 5, Up: History<2> + +9.439 0.6.4 +=========== + +10 Oct 2009 + + * Added the generation of ‘distribute_setup_3k.py’ during the + release. This closes Distribute #52(1). + + * Added an upload_docs command to easily upload project documentation + to PyPI’s ‘https://pythonhosted.org’. This close issue Distribute + #56(2). + + * Fixed a bootstrap bug on the use_setuptools() API. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/52 + + (2) https://bitbucket.org/tarek/distribute/issue/56 + + +File: setuptools.info, Node: 0 6 3, Next: 0 6 2, Prev: 0 6 4, Up: History<2> + +9.440 0.6.3 +=========== + +27 Sep 2009 + +* Menu: + +* setuptools:: +* bootstrapping:: + + +File: setuptools.info, Node: setuptools, Next: bootstrapping, Up: 0 6 3 + +9.440.1 setuptools +------------------ + + * Fixed a bunch of calls to file() that caused crashes on Python 3. + + +File: setuptools.info, Node: bootstrapping, Prev: setuptools, Up: 0 6 3 + +9.440.2 bootstrapping +--------------------- + + * Fixed a bug in sorting that caused bootstrap to fail on Python 3. + + +File: setuptools.info, Node: 0 6 2, Next: 0 6 1, Prev: 0 6 3, Up: History<2> + +9.441 0.6.2 +=========== + +26 Sep 2009 + +* Menu: + +* setuptools: setuptools<2>. +* bootstrapping: bootstrapping<2>. + + +File: setuptools.info, Node: setuptools<2>, Next: bootstrapping<2>, Up: 0 6 2 + +9.441.1 setuptools +------------------ + + * Added Python 3 support; see docs/python3.txt. This closes Old + Setuptools #39(1). + + * Added option to run 2to3 automatically when installing on Python 3. + This closes issue Distribute #31(2). + + * Fixed invalid usage of requirement.parse, that broke develop -d. + This closes Old Setuptools #44(3). + + * Fixed script launcher for 64-bit Windows. This closes Old + Setuptools #2(4). + + * KeyError when compiling extensions. This closes Old Setuptools + #41(5). + + ---------- Footnotes ---------- + + (1) http://bugs.python.org/setuptools/issue39 + + (2) https://bitbucket.org/tarek/distribute/issue/31 + + (3) http://bugs.python.org/setuptools/issue44 + + (4) http://bugs.python.org/setuptools/issue2 + + (5) http://bugs.python.org/setuptools/issue41 + + +File: setuptools.info, Node: bootstrapping<2>, Prev: setuptools<2>, Up: 0 6 2 + +9.441.2 bootstrapping +--------------------- + + * Fixed bootstrap not working on Windows. This closes issue + Distribute #49(1). + + * Fixed 2.6 dependencies. This closes issue Distribute #50(2). + + * Make sure setuptools is patched when running through easy_install + This closes Old Setuptools #40(3). + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/49 + + (2) https://bitbucket.org/tarek/distribute/issue/50 + + (3) http://bugs.python.org/setuptools/issue40 + + +File: setuptools.info, Node: 0 6 1, Next: 0 6, Prev: 0 6 2, Up: History<2> + +9.442 0.6.1 +=========== + +08 Sep 2009 + +* Menu: + +* setuptools: setuptools<3>. +* bootstrapping: bootstrapping<3>. + + +File: setuptools.info, Node: setuptools<3>, Next: bootstrapping<3>, Up: 0 6 1 + +9.442.1 setuptools +------------------ + + * package_index.urlopen now catches BadStatusLine and malformed url + errors. This closes Distribute #16(1) and Distribute #18(2). + + * zip_ok is now False by default. This closes Old Setuptools #33(3). + + * Fixed invalid URL error catching. Old Setuptools #20(4). + + * Fixed invalid bootstraping with easy_install installation + (Distribute #40(5)). Thanks to Florian Schulze for the help. + + * Removed buildout/bootstrap.py. A new repository will create a + specific bootstrap.py script. + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/16 + + (2) https://bitbucket.org/tarek/distribute/issue/18 + + (3) http://bugs.python.org/setuptools/issue33 + + (4) http://bugs.python.org/setuptools/issue20 + + (5) https://bitbucket.org/tarek/distribute/issue/40 + + +File: setuptools.info, Node: bootstrapping<3>, Prev: setuptools<3>, Up: 0 6 1 + +9.442.2 bootstrapping +--------------------- + + * The boostrap process leave setuptools alone if detected in the + system and –root or –prefix is provided, but is not in the same + location. This closes Distribute #10(1). + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/10 + + +File: setuptools.info, Node: 0 6, Next: 0 6c9, Prev: 0 6 1, Up: History<2> + +9.443 0.6 +========= + +09 Aug 2009 + +* Menu: + +* setuptools: setuptools<4>. +* pkg_resources:: +* easy_install:: + + +File: setuptools.info, Node: setuptools<4>, Next: pkg_resources, Up: 0 6 + +9.443.1 setuptools +------------------ + + * Packages required at build time where not fully present at install + time. This closes Distribute #12(1). + + * Protected against failures in tarfile extraction. This closes + Distribute #10(2). + + * Made Jython api_tests.txt doctest compatible. This closes + Distribute #7(3). + + * sandbox.py replaced builtin type file with builtin function open. + This closes Distribute #6(4). + + * Immediately close all file handles. This closes Distribute #3(5). + + * Added compatibility with Subversion 1.6. This references + Distribute #1(6). + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/12 + + (2) https://bitbucket.org/tarek/distribute/issue/10 + + (3) https://bitbucket.org/tarek/distribute/issue/7 + + (4) https://bitbucket.org/tarek/distribute/issue/6 + + (5) https://bitbucket.org/tarek/distribute/issue/3 + + (6) https://bitbucket.org/tarek/distribute/issue/1 + + +File: setuptools.info, Node: pkg_resources, Next: easy_install, Prev: setuptools<4>, Up: 0 6 + +9.443.2 pkg_resources +--------------------- + + * Avoid a call to /usr/bin/sw_vers on OSX and use the official + platform API instead. Based on a patch from ronaldoussoren. This + closes issue #5(1). + + * Fixed a SandboxViolation for mkdir that could occur in certain + cases. This closes Distribute #13(2). + + * Allow to find_on_path on systems with tight permissions to fail + gracefully. This closes Distribute #9(3). + + * Corrected inconsistency between documentation and code of + add_entry. This closes Distribute #8(4). + + * Immediately close all file handles. This closes Distribute #3(5). + + ---------- Footnotes ---------- + + (1) https://github.com/pypa/setuptools/issues/5 + + (2) https://bitbucket.org/tarek/distribute/issue/13 + + (3) https://bitbucket.org/tarek/distribute/issue/9 + + (4) https://bitbucket.org/tarek/distribute/issue/8 + + (5) https://bitbucket.org/tarek/distribute/issue/3 + + +File: setuptools.info, Node: easy_install, Prev: pkg_resources, Up: 0 6 + +9.443.3 easy_install +-------------------- + + * Immediately close all file handles. This closes Distribute #3(1). + + ---------- Footnotes ---------- + + (1) https://bitbucket.org/tarek/distribute/issue/3 + + +File: setuptools.info, Node: 0 6c9, Next: 0 6c7, Prev: 0 6, Up: History<2> + +9.444 0.6c9 +=========== + + * Fixed a missing files problem when using Windows source + distributions on non-Windows platforms, due to distutils not + handling manifest file line endings correctly. + + * Updated Pyrex support to work with Pyrex 0.9.6 and higher. + + * Minor changes for Jython compatibility, including skipping + tests that can’t work on Jython. + + * Fixed not installing eggs in ‘install_requires’ if they were + also used for ‘setup_requires’ or ‘tests_require’. + + * Fixed not fetching eggs in ‘install_requires’ when running + tests. + + * Allow ‘ez_setup.use_setuptools()’ to upgrade existing + setuptools installations when called from a standalone + ‘setup.py’. + + * Added a warning if a namespace package is declared, but its + parent package is not also declared as a namespace. + + * Support Subversion 1.5 + + * Removed use of deprecated ‘md5’ module if ‘hashlib’ is + available + + * Fixed ‘bdist_wininst upload’ trying to upload the ‘.exe’ twice + + * Fixed ‘bdist_egg’ putting a ‘native_libs.txt’ in the source + package’s ‘.egg-info’, when it should only be in the built + egg’s ‘EGG-INFO’. + + * Ensure that _full_name is set on all shared libs before + extensions are checked for shared lib usage. (Fixes a bug in + the experimental shared library build support.) + + * Fix to allow unpacked eggs containing native libraries to fail + more gracefully under Google App Engine (with an ‘ImportError’ + loading the C-based module, instead of getting a ‘NameError’). + + * Fixed ‘win32.exe’ support for .pth files, so unnecessary + directory nesting is flattened out in the resulting egg. + (There was a case-sensitivity problem that affected some + distributions, notably ‘pywin32’.) + + * Prevent ‘--help-commands’ and other junk from showing under + Python 2.5 when running ‘easy_install --help’. + + * Fixed GUI scripts sometimes not executing on Windows + + * Fixed not picking up dependency links from recursive + dependencies. + + * Only make ‘.py’, ‘.dll’ and ‘.so’ files executable when + unpacking eggs + + * Changes for Jython compatibility + + * Improved error message when a requirement is also a directory + name, but the specified directory is not a source package. + + * Fixed ‘--allow-hosts’ option blocking ‘file:’ URLs + + * Fixed HTTP SVN detection failing when the page title included + a project name (e.g. on SourceForge-hosted SVN) + + * Fix Jython script installation to handle ‘#!’ lines better + when ‘sys.executable’ is a script. + + * Removed use of deprecated ‘md5’ module if ‘hashlib’ is + available + + * Keep site directories (e.g. ‘site-packages’) from being + included in ‘.pth’ files. + + +File: setuptools.info, Node: 0 6c7, Next: 0 6c6, Prev: 0 6c9, Up: History<2> + +9.445 0.6c7 +=========== + + * Fixed ‘distutils.filelist.findall()’ crashing on broken + symlinks, and ‘egg_info’ command failing on new, uncommitted + SVN directories. + + * Fix import problems with nested namespace packages installed + via ‘--root’ or ‘--single-version-externally-managed’, due to + the parent package not having the child package as an + attribute. + + * ‘ftp:’ download URLs now work correctly. + + * The default ‘--index-url’ is now + ‘https://pypi.python.org/simple’, to use the Python Package + Index’s new simpler (and faster!) REST API. + + +File: setuptools.info, Node: 0 6c6, Next: 0 6c5, Prev: 0 6c7, Up: History<2> + +9.446 0.6c6 +=========== + + * Added ‘--egg-path’ option to ‘develop’ command, allowing you + to force ‘.egg-link’ files to use relative paths (allowing + them to be shared across platforms on a networked drive). + + * Fix not building binary RPMs correctly. + + * Fix “eggsecutables” (such as setuptools’ own egg) only being + runnable with bash-compatible shells. + + * Fix ‘#!’ parsing problems in Windows ‘.exe’ script wrappers, + when there was whitespace inside a quoted argument or at the + end of the ‘#!’ line (a regression introduced in 0.6c4). + + * Fix ‘test’ command possibly failing if an older version of the + project being tested was installed on ‘sys.path’ ahead of the + test source directory. + + * Fix ‘find_packages()’ treating ‘ez_setup’ and directories with + ‘.’ in their names as packages. + + * EasyInstall no longer aborts the installation process if a URL + it wants to retrieve can’t be downloaded, unless the URL is an + actual package download. Instead, it issues a warning and + tries to keep going. + + * Fixed distutils-style scripts originally built on Windows + having their line endings doubled when installed on any + platform. + + * Added ‘--local-snapshots-ok’ flag, to allow building eggs from + projects installed using ‘setup.py develop’. + + * Fixed not HTML-decoding URLs scraped from web pages + + +File: setuptools.info, Node: 0 6c5, Next: 0 6c4, Prev: 0 6c6, Up: History<2> + +9.447 0.6c5 +=========== + + * Fix uploaded ‘bdist_rpm’ packages being described as + ‘bdist_egg’ packages under Python versions less than 2.5. + + * Fix uploaded ‘bdist_wininst’ packages being described as + suitable for “any” version by Python 2.5, even if a + ‘--target-version’ was specified. + + * Fixed ‘.dll’ files on Cygwin not having executable permissions + when an egg is installed unzipped. + + +File: setuptools.info, Node: 0 6c4, Next: 0 6c3, Prev: 0 6c5, Up: History<2> + +9.448 0.6c4 +=========== + + * Overhauled Windows script wrapping to support ‘bdist_wininst’ + better. Scripts installed with ‘bdist_wininst’ will always + use ‘#!python.exe’ or ‘#!pythonw.exe’ as the executable name + (even when built on non-Windows platforms!), and the wrappers + will look for the executable in the script’s parent directory + (which should find the right version of Python). + + * Fix ‘upload’ command not uploading files built by ‘bdist_rpm’ + or ‘bdist_wininst’ under Python 2.3 and 2.4. + + * Add support for “eggsecutable” headers: a ‘#!/bin/sh’ script + that is prepended to an ‘.egg’ file to allow it to be run as a + script on Unix-ish platforms. (This is mainly so that + setuptools itself can have a single-file installer on Unix, + without doing multiple downloads, dealing with firewalls, + etc.) + + * Fix problem with empty revision numbers in Subversion 1.4 + ‘entries’ files + + * Use cross-platform relative paths in ‘easy-install.pth’ when + doing ‘develop’ and the source directory is a subdirectory of + the installation target directory. + + * Fix a problem installing eggs with a system packaging tool if + the project contained an implicit namespace package; for + example if the ‘setup()’ listed a namespace package ‘foo.bar’ + without explicitly listing ‘foo’ as a namespace package. + + * Added support for HTTP “Basic” authentication using + ‘http://user:pass@host’ URLs. If a password-protected page + contains links to the same host (and protocol), those links + will inherit the credentials used to access the original page. + + * Removed all special support for Sourceforge mirrors, as + Sourceforge’s mirror system now works well for non-browser + downloads. + + * Fixed not recognizing ‘win32.exe’ installers that included a + custom bitmap. + + * Fixed not allowing ‘os.open()’ of paths outside the sandbox, + even if they are opened read-only (e.g. reading + ‘/dev/urandom’ for random numbers, as is done by + ‘os.urandom()’ on some platforms). + + * Fixed a problem with ‘.pth’ testing on Windows when + ‘sys.executable’ has a space in it (e.g., the user installed + Python to a ‘Program Files’ directory). + + +File: setuptools.info, Node: 0 6c3, Next: 0 6c2, Prev: 0 6c4, Up: History<2> + +9.449 0.6c3 +=========== + + * Fixed breakages caused by Subversion 1.4’s new “working copy” + format + + * You can once again use “python -m easy_install” with Python + 2.4 and above. + + * Python 2.5 compatibility fixes added. + + +File: setuptools.info, Node: 0 6c2, Next: 0 6c1, Prev: 0 6c3, Up: History<2> + +9.450 0.6c2 +=========== + + * The ‘ez_setup’ module displays the conflicting version of + setuptools (and its installation location) when a script + requests a version that’s not available. + + * Running ‘setup.py develop’ on a setuptools-using project will + now install setuptools if needed, instead of only downloading + the egg. + + * Windows script wrappers now support quoted arguments and + arguments containing spaces. (Patch contributed by Jim + Fulton.) + + * The ‘ez_setup.py’ script now actually works when you put a + setuptools ‘.egg’ alongside it for bootstrapping an offline + machine. + + * A writable installation directory on ‘sys.path’ is no longer + required to download and extract a source distribution using + ‘--editable’. + + * Generated scripts now use ‘-x’ on the ‘#!’ line when + ‘sys.executable’ contains non-ASCII characters, to prevent + deprecation warnings about an unspecified encoding when the + script is run. + + +File: setuptools.info, Node: 0 6c1, Next: 0 6b4, Prev: 0 6c2, Up: History<2> + +9.451 0.6c1 +=========== + + * Fixed ‘AttributeError’ when trying to download a + ‘setup_requires’ dependency when a distribution lacks a + ‘dependency_links’ setting. + + * Made ‘zip-safe’ and ‘not-zip-safe’ flag files contain a single + byte, so as to play better with packaging tools that complain + about zero-length files. + + * Made ‘setup.py develop’ respect the ‘--no-deps’ option, which + it previously was ignoring. + + * Support ‘extra_path’ option to ‘setup()’ when ‘install’ is run + in backward-compatibility mode. + + * Source distributions now always include a ‘setup.cfg’ file + that explicitly sets ‘egg_info’ options such that they produce + an identical version number to the source distribution’s + version number. (Previously, the default version number could + be different due to the use of ‘--tag-date’, or if the version + was overridden on the command line that built the source + distribution.) + + * EasyInstall now includes setuptools version information in the + ‘User-Agent’ string sent to websites it visits. + + +File: setuptools.info, Node: 0 6b4, Next: 0 6b3, Prev: 0 6c1, Up: History<2> + +9.452 0.6b4 +=========== + + * Fix ‘register’ not obeying name/version set by ‘egg_info’ + command, if ‘egg_info’ wasn’t explicitly run first on the same + command line. + + * Added ‘--no-date’ and ‘--no-svn-revision’ options to + ‘egg_info’ command, to allow suppressing tags configured in + ‘setup.cfg’. + + * Fixed redundant warnings about missing ‘README’ file(s); it + should now appear only if you are actually a source + distribution. + + * Fix creating Python wrappers for non-Python scripts + + * Fix ‘ftp://’ directory listing URLs from causing a crash when + used in the “Home page” or “Download URL” slots on PyPI. + + * Fix ‘sys.path_importer_cache’ not being updated when an + existing zipfile or directory is deleted/overwritten. + + * Fix not recognizing HTML 404 pages from package indexes. + + * Allow ‘file://’ URLs to be used as a package index. URLs that + refer to directories will use an internally-generated + directory listing if there is no ‘index.html’ file in the + directory. + + * Allow external links in a package index to be specified using + ‘rel="homepage"’ or ‘rel="download"’, without needing the old + PyPI-specific visible markup. + + * Suppressed warning message about possibly-misspelled project + name, if an egg or link for that project name has already been + seen. + + +File: setuptools.info, Node: 0 6b3, Next: 0 6b2, Prev: 0 6b4, Up: History<2> + +9.453 0.6b3 +=========== + + * Fix ‘bdist_egg’ not including files in subdirectories of + ‘.egg-info’. + + * Allow ‘.py’ files found by the ‘include_package_data’ option + to be automatically included. Remove duplicate data file + matches if both ‘include_package_data’ and ‘package_data’ are + used to refer to the same files. + + * Fix local ‘--find-links’ eggs not being copied except with + ‘--always-copy’. + + * Fix sometimes not detecting local packages installed outside + of “site” directories. + + * Fix mysterious errors during initial ‘setuptools’ install, + caused by ‘ez_setup’ trying to run ‘easy_install’ twice, due + to a code fallthru after deleting the egg from which it’s + running. + + +File: setuptools.info, Node: 0 6b2, Next: 0 6b1, Prev: 0 6b3, Up: History<2> + +9.454 0.6b2 +=========== + + * Don’t install or update a ‘site.py’ patch when installing to a + ‘PYTHONPATH’ directory with ‘--multi-version’, unless an + ‘easy-install.pth’ file is already in use there. + + * Construct ‘.pth’ file paths in such a way that installing an + egg whose name begins with ‘import’ doesn’t cause a syntax + error. + + * Fixed a bogus warning message that wasn’t updated since the + 0.5 versions. + + +File: setuptools.info, Node: 0 6b1, Next: 0 6a11, Prev: 0 6b2, Up: History<2> + +9.455 0.6b1 +=========== + + * Strip ‘module’ from the end of compiled extension modules when + computing the name of a ‘.py’ loader/wrapper. (Python’s + import machinery ignores this suffix when searching for an + extension module.) + + * Better ambiguity management: accept ‘#egg’ name/version even + if processing what appears to be a correctly-named distutils + file, and ignore ‘.egg’ files with no ‘-’, since valid Python + ‘.egg’ files always have a version number (but Scheme eggs + often don’t). + + * Support ‘file://’ links to directories in ‘--find-links’, so + that easy_install can build packages from local source + checkouts. + + * Added automatic retry for Sourceforge mirrors. The new + download process is to first just try dl.sourceforge.net, then + randomly select mirror IPs and remove ones that fail, until + something works. The removed IPs stay removed for the + remainder of the run. + + * Ignore bdist_dumb distributions when looking at download URLs. + + +File: setuptools.info, Node: 0 6a11, Next: 0 6a10, Prev: 0 6b1, Up: History<2> + +9.456 0.6a11 +============ + + * Added ‘test_loader’ keyword to support custom test loaders + + * Added ‘setuptools.file_finders’ entry point group to allow + implementing revision control plugins. + + * Added ‘--identity’ option to ‘upload’ command. + + * Added ‘dependency_links’ to allow specifying URLs for + ‘--find-links’. + + * Enhanced test loader to scan packages as well as modules, and + call ‘additional_tests()’ if present to get non-unittest + tests. + + * Support namespace packages in conjunction with system + packagers, by omitting the installation of any ‘__init__.py’ + files for namespace packages, and adding a special ‘.pth’ file + to create a working package in ‘sys.modules’. + + * Made ‘--single-version-externally-managed’ automatic when + ‘--root’ is used, so that most system packagers won’t require + special support for setuptools. + + * Fixed ‘setup_requires’, ‘tests_require’, etc. not using + ‘setup.cfg’ or other configuration files for their option + defaults when installing, and also made the install use + ‘--multi-version’ mode so that the project directory doesn’t + need to support .pth files. + + * ‘MANIFEST.in’ is now forcibly closed when any errors occur + while reading it. Previously, the file could be left open and + the actual error would be masked by problems trying to remove + the open file on Windows systems. + + * Process ‘dependency_links.txt’ if found in a distribution, by + adding the URLs to the list for scanning. + + * Use relative paths in ‘.pth’ files when eggs are being + installed to the same directory as the ‘.pth’ file. This + maximizes portability of the target directory when building + applications that contain eggs. + + * Added ‘easy_install-N.N’ script(s) for convenience when using + multiple Python versions. + + * Added automatic handling of installation conflicts. Eggs are + now shifted to the front of sys.path, in an order consistent + with where they came from, making EasyInstall seamlessly + co-operate with system package managers. + + The ‘--delete-conflicting’ and ‘--ignore-conflicts-at-my-risk’ + options are now no longer necessary, and will generate + warnings at the end of a run if you use them. + + * Don’t recursively traverse subdirectories given to + ‘--find-links’. + + +File: setuptools.info, Node: 0 6a10, Next: 0 6a9, Prev: 0 6a11, Up: History<2> + +9.457 0.6a10 +============ + + * Fixed the ‘develop’ command ignoring ‘--find-links’. + + * Added exhaustive testing of the install directory, including a + spawn test for ‘.pth’ file support, and directory + writability/existence checks. This should virtually eliminate + the need to set or configure ‘--site-dirs’. + + * Added ‘--prefix’ option for more do-what-I-mean-ishness in the + absence of RTFM-ing. :) + + * Enhanced ‘PYTHONPATH’ support so that you don’t have to put + any eggs on it manually to make it work. ‘--multi-version’ is + no longer a silent default; you must explicitly use it if + installing to a non-PYTHONPATH, non-“site” directory. + + * Expand ‘$variables’ used in the ‘--site-dirs’, + ‘--build-directory’, ‘--install-dir’, and ‘--script-dir’ + options, whether on the command line or in configuration + files. + + * Improved SourceForge mirror processing to work faster and be + less affected by transient HTML changes made by SourceForge. + + * PyPI searches now use the exact spelling of requirements + specified on the command line or in a project’s + ‘install_requires’. Previously, a normalized form of the name + was used, which could lead to unnecessary full-index searches + when a project’s name had an underscore (‘_’) in it. + + * EasyInstall can now download bare ‘.py’ files and wrap them in + an egg, as long as you include an ‘#egg=name-version’ suffix + on the URL, or if the ‘.py’ file is listed as the “Download + URL” on the project’s PyPI page. This allows third parties to + “package” trivial Python modules just by linking to them (e.g. + from within their own PyPI page or download links page). + + * The ‘--always-copy’ option now skips “system” and + “development” eggs since they can’t be reliably copied. Note + that this may cause EasyInstall to choose an older version of + a package than what you expected, or it may cause downloading + and installation of a fresh version of what’s already + installed. + + * The ‘--find-links’ option previously scanned all supplied URLs + and directories as early as possible, but now only directories + and direct archive links are scanned immediately. URLs are + not retrieved unless a package search was already going to go + online due to a package not being available locally, or due to + the use of the ‘--update’ or ‘-U’ option. + + * Fixed the annoying ‘--help-commands’ wart. + + +File: setuptools.info, Node: 0 6a9, Next: 0 6a8, Prev: 0 6a10, Up: History<2> + +9.458 0.6a9 +=========== + + * The ‘sdist’ command no longer uses the traditional ‘MANIFEST’ + file to create source distributions. ‘MANIFEST.in’ is still + read and processed, as are the standard defaults and pruning. + But the manifest is built inside the project’s ‘.egg-info’ + directory as ‘SOURCES.txt’, and it is rebuilt every time the + ‘egg_info’ command is run. + + * Added the ‘include_package_data’ keyword to ‘setup()’, + allowing you to automatically include any package data listed + in revision control or ‘MANIFEST.in’ + + * Added the ‘exclude_package_data’ keyword to ‘setup()’, + allowing you to trim back files included via the + ‘package_data’ and ‘include_package_data’ options. + + * Fixed ‘--tag-svn-revision’ not working when run from a source + distribution. + + * Added warning for namespace packages with missing + ‘declare_namespace()’ + + * Added ‘tests_require’ keyword to ‘setup()’, so that e.g. + packages requiring ‘nose’ to run unit tests can make this + dependency optional unless the ‘test’ command is run. + + * Made all commands that use ‘easy_install’ respect its + configuration options, as this was causing some problems with + ‘setup.py install’. + + * Added an ‘unpack_directory()’ driver to + ‘setuptools.archive_util’, so that you can process a directory + tree through a processing filter as if it were a zipfile or + tarfile. + + * Added an internal ‘install_egg_info’ command to use as part of + old-style ‘install’ operations, that installs an ‘.egg-info’ + directory with the package. + + * Added a ‘--single-version-externally-managed’ option to the + ‘install’ command so that you can more easily wrap a “flat” + egg in a system package. + + * Enhanced ‘bdist_rpm’ so that it installs single-version eggs + that don’t rely on a ‘.pth’ file. The ‘--no-egg’ option has + been removed, since all RPMs are now built in a more + backwards-compatible format. + + * Support full roundtrip translation of eggs to and from + ‘bdist_wininst’ format. Running ‘bdist_wininst’ on a + setuptools-based package wraps the egg in an .exe that will + safely install it as an egg (i.e., with metadata and + entry-point wrapper scripts), and ‘easy_install’ can turn the + .exe back into an ‘.egg’ file or directory and install it as + such. + + * Fixed ‘.pth’ file processing picking up nested eggs (i.e. + ones inside “baskets”) when they weren’t explicitly listed in + the ‘.pth’ file. + + * If more than one URL appears to describe the exact same + distribution, prefer the shortest one. This helps to avoid + “table of contents” CGI URLs like the ones on effbot.org. + + * Quote arguments to python.exe (including python’s path) to + avoid problems when Python (or a script) is installed in a + directory whose name contains spaces on Windows. + + * Support full roundtrip translation of eggs to and from + ‘bdist_wininst’ format. Running ‘bdist_wininst’ on a + setuptools-based package wraps the egg in an .exe that will + safely install it as an egg (i.e., with metadata and + entry-point wrapper scripts), and ‘easy_install’ can turn the + .exe back into an ‘.egg’ file or directory and install it as + such. + + +File: setuptools.info, Node: 0 6a8, Next: 0 6a7, Prev: 0 6a9, Up: History<2> + +9.459 0.6a8 +=========== + + * Fixed some problems building extensions when Pyrex was + installed, especially with Python 2.4 and/or packages using + SWIG. + + * Made ‘develop’ command accept all the same options as + ‘easy_install’, and use the ‘easy_install’ command’s + configuration settings as defaults. + + * Made ‘egg_info --tag-svn-revision’ fall back to extracting the + revision number from ‘PKG-INFO’ in case it is being run on a + source distribution of a snapshot taken from a + Subversion-based project. + + * Automatically detect ‘.dll’, ‘.so’ and ‘.dylib’ files that are + being installed as data, adding them to ‘native_libs.txt’ + automatically. + + * Fixed some problems with fresh checkouts of projects that + don’t include ‘.egg-info/PKG-INFO’ under revision control and + put the project’s source code directly in the project + directory. If such a package had any requirements that get + processed before the ‘egg_info’ command can be run, the setup + scripts would fail with a “Missing ‘Version:’ header and/or + PKG-INFO file” error, because the egg runtime interpreted the + unbuilt metadata in a directory on ‘sys.path’ (i.e. the + current directory) as being a corrupted egg. Setuptools now + monkeypatches the distribution metadata cache to pretend that + the egg has valid version information, until it has a chance + to make it actually be so (via the ‘egg_info’ command). + + * Update for changed SourceForge mirror format + + * Fixed not installing dependencies for some packages fetched + via Subversion + + * Fixed dependency installation with ‘--always-copy’ not using + the same dependency resolution procedure as other operations. + + * Fixed not fully removing temporary directories on Windows, if + a Subversion checkout left read-only files behind + + * Fixed some problems building extensions when Pyrex was + installed, especially with Python 2.4 and/or packages using + SWIG. + + +File: setuptools.info, Node: 0 6a7, Next: 0 6a6, Prev: 0 6a8, Up: History<2> + +9.460 0.6a7 +=========== + + * Fixed not being able to install Windows script wrappers using + Python 2.3 + + +File: setuptools.info, Node: 0 6a6, Next: 0 6a5, Prev: 0 6a7, Up: History<2> + +9.461 0.6a6 +=========== + + * Added support for “traditional” PYTHONPATH-based non-root + installation, and also the convenient ‘virtual-python.py’ + script, based on a contribution by Ian Bicking. The + setuptools egg now contains a hacked ‘site’ module that makes + the PYTHONPATH-based approach work with .pth files, so that + you can get the full EasyInstall feature set on such + installations. + + * Added ‘--no-deps’ and ‘--allow-hosts’ options. + + * Improved Windows ‘.exe’ script wrappers so that the script can + have the same name as a module without confusing Python. + + * Changed dependency processing so that it’s breadth-first, + allowing a depender’s preferences to override those of a + dependee, to prevent conflicts when a lower version is + acceptable to the dependee, but not the depender. Also, + ensure that currently installed/selected packages aren’t given + precedence over ones desired by a package being installed, + which could cause conflict errors. + + +File: setuptools.info, Node: 0 6a5, Next: 0 6a3, Prev: 0 6a6, Up: History<2> + +9.462 0.6a5 +=========== + + * Fixed missing gui/cli .exe files in distribution. Fixed bugs + in tests. + + +File: setuptools.info, Node: 0 6a3, Next: 0 6a2, Prev: 0 6a5, Up: History<2> + +9.463 0.6a3 +=========== + + * Added ‘gui_scripts’ entry point group to allow installing GUI + scripts on Windows and other platforms. (The special handling + is only for Windows; other platforms are treated the same as + for ‘console_scripts’.) + + * Improved error message when trying to use old ways of running + ‘easy_install’. Removed the ability to run via ‘python -m’ or + by running ‘easy_install.py’; ‘easy_install’ is the command to + run on all supported platforms. + + * Improved wrapper script generation and runtime initialization + so that a VersionConflict doesn’t occur if you later install a + competing version of a needed package as the default version + of that package. + + * Fixed a problem parsing version numbers in ‘#egg=’ links. + + +File: setuptools.info, Node: 0 6a2, Next: 0 6a1, Prev: 0 6a3, Up: History<2> + +9.464 0.6a2 +=========== + + * Added ‘console_scripts’ entry point group to allow installing + scripts without the need to create separate script files. On + Windows, console scripts get an ‘.exe’ wrapper so you can just + type their name. On other platforms, the scripts are written + without a file extension. + + * EasyInstall can now install “console_scripts” defined by + packages that use ‘setuptools’ and define appropriate entry + points. On Windows, console scripts get an ‘.exe’ wrapper so + you can just type their name. On other platforms, the scripts + are installed without a file extension. + + * Using ‘python -m easy_install’ or running ‘easy_install.py’ is + now DEPRECATED, since an ‘easy_install’ wrapper is now + available on all platforms. + + +File: setuptools.info, Node: 0 6a1, Next: 0 5a12, Prev: 0 6a2, Up: History<2> + +9.465 0.6a1 +=========== + + * Added support for building “old-style” RPMs that don’t install + an egg for the target package, using a ‘--no-egg’ option. + + * The ‘build_ext’ command now works better when using the + ‘--inplace’ option and multiple Python versions. It now makes + sure that all extensions match the current Python version, + even if newer copies were built for a different Python + version. + + * The ‘upload’ command no longer attaches an extra ‘.zip’ when + uploading eggs, as PyPI now supports egg uploads without + trickery. + + * The ‘ez_setup’ script/module now displays a warning before + downloading the setuptools egg, and attempts to check the + downloaded egg against an internal MD5 checksum table. + + * Fixed the ‘--tag-svn-revision’ option of ‘egg_info’ not + finding the latest revision number; it was using the revision + number of the directory containing ‘setup.py’, not the highest + revision number in the project. + + * Added ‘eager_resources’ setup argument + + * The ‘sdist’ command now recognizes Subversion “deleted file” + entries and does not include them in source distributions. + + * ‘setuptools’ now embeds itself more thoroughly into the + distutils, so that other distutils extensions (e.g. py2exe, + py2app) will subclass setuptools’ versions of things, rather + than the native distutils ones. + + * Added ‘entry_points’ and ‘setup_requires’ arguments to + ‘setup()’; ‘setup_requires’ allows you to automatically find + and download packages that are needed in order to `build' your + project (as opposed to running it). + + * ‘setuptools’ now finds its commands, ‘setup()’ argument + validators, and metadata writers using entry points, so that + they can be extended by third-party packages. See Creating + distutils Extensions(1) for more details. + + * The vestigial ‘depends’ command has been removed. It was + never finished or documented, and never would have worked + without EasyInstall - which it pre-dated and was never + compatible with. + + * EasyInstall now does MD5 validation of downloads from PyPI, or + from any link that has an “#md5=…” trailer with a 32-digit + lowercase hex md5 digest. + + * EasyInstall now handles symlinks in target directories by + removing the link, rather than attempting to overwrite the + link’s destination. This makes it easier to set up an + alternate Python “home” directory (as described in the + Non-Root Installation section of the docs). + + * Added support for handling MacOS platform information in + ‘.egg’ filenames, based on a contribution by Kevin Dangoor. + You may wish to delete and reinstall any eggs whose filename + includes “darwin” and “Power_Macintosh”, because the format + for this platform information has changed so that minor OS X + upgrades (such as 10.4.1 to 10.4.2) do not cause eggs built + with a previous OS version to become obsolete. + + * easy_install’s dependency processing algorithms have changed. + When using ‘--always-copy’, it now ensures that dependencies + are copied too. When not using ‘--always-copy’, it tries to + use a single resolution loop, rather than recursing. + + * Fixed installing extra ‘.pyc’ or ‘.pyo’ files for scripts with + ‘.py’ extensions. + + * Added ‘--site-dirs’ option to allow adding custom “site” + directories. Made ‘easy-install.pth’ work in + platform-specific alternate site directories (e.g. + ‘~/Library/Python/2.x/site-packages’ on Mac OS X). + + * If you manually delete the current version of a package, the + next run of EasyInstall against the target directory will now + remove the stray entry from the ‘easy-install.pth’ file. + + * EasyInstall now recognizes URLs with a ‘#egg=project_name’ + fragment ID as pointing to the named project’s source + checkout. Such URLs have a lower match precedence than any + other kind of distribution, so they’ll only be used if they + have a higher version number than any other available + distribution, or if you use the ‘--editable’ option. The + ‘#egg’ fragment can contain a version if it’s formatted as + ‘#egg=proj-ver’, where ‘proj’ is the project name, and ‘ver’ + is the version number. You `must' use the format for these + values that the ‘bdist_egg’ command uses; i.e., all + non-alphanumeric runs must be condensed to single underscore + characters. + + * Added the ‘--editable’ option; see Editing and Viewing Source + Packages in the docs. Also, slightly changed the behavior of + the ‘--build-directory’ option. + + * Fixed the setup script sandbox facility not recognizing + certain paths as valid on case-insensitive platforms. + + ---------- Footnotes ---------- + + (1) +https://setuptools.readthedocs.io/en/latest/setuptools.html#creating-distutils-extensions + + +File: setuptools.info, Node: 0 5a12, Next: 0 5a11, Prev: 0 6a1, Up: History<2> + +9.466 0.5a12 +============ + + * The zip-safety scanner now checks for modules that might be + used with ‘python -m’, and marks them as unsafe for zipping, + since Python 2.4 can’t handle ‘-m’ on zipped modules. + + * Fix ‘python -m easy_install’ not working due to setuptools + being installed as a zipfile. Update safety scanner to check + for modules that might be used as ‘python -m’ scripts. + + * Misc. fixes for win32.exe support, including changes to + support Python 2.4’s changed ‘bdist_wininst’ format. + + +File: setuptools.info, Node: 0 5a11, Next: 0 5a10, Prev: 0 5a12, Up: History<2> + +9.467 0.5a11 +============ + + * Fix breakage of the “develop” command that was caused by the + addition of ‘--always-unzip’ to the ‘easy_install’ command. + + +File: setuptools.info, Node: 0 5a10, Next: 0 5a9, Prev: 0 5a11, Up: History<2> + +9.468 0.5a10 +============ + + * Put the ‘easy_install’ module back in as a module, as it’s + needed for ‘python -m’ to run it! + + * Allow ‘--find-links/-f’ to accept local directories or + filenames as well as URLs. + + +File: setuptools.info, Node: 0 5a9, Next: 0 5a8, Prev: 0 5a10, Up: History<2> + +9.469 0.5a9 +=========== + + * Include ‘svn:externals’ directories in source distributions as + well as normal subversion-controlled files and directories. + + * Added ‘exclude=patternlist’ option to + ‘setuptools.find_packages()’ + + * Changed –tag-svn-revision to include an “r” in front of the + revision number for better readability. + + * Added ability to build eggs without including source files + (except for any scripts, of course), using the + ‘--exclude-source-files’ option to ‘bdist_egg’. + + * ‘setup.py install’ now automatically detects when an + “unmanaged” package or module is going to be on ‘sys.path’ + ahead of a package being installed, thereby preventing the + newer version from being imported. If this occurs, a warning + message is output to ‘sys.stderr’, but installation proceeds + anyway. The warning message informs the user what files or + directories need deleting, and advises them they can also use + EasyInstall (with the ‘--delete-conflicting’ option) to do it + automatically. + + * The ‘egg_info’ command now adds a ‘top_level.txt’ file to the + metadata directory that lists all top-level modules and + packages in the distribution. This is used by the + ‘easy_install’ command to find possibly-conflicting + “unmanaged” packages when installing the distribution. + + * Added ‘zip_safe’ and ‘namespace_packages’ arguments to + ‘setup()’. Added package analysis to determine zip-safety if + the ‘zip_safe’ flag is not given, and advise the author + regarding what code might need changing. + + * Fixed the swapped ‘-d’ and ‘-b’ options of ‘bdist_egg’. + + * EasyInstall now automatically detects when an “unmanaged” + package or module is going to be on ‘sys.path’ ahead of a + package you’re installing, thereby preventing the newer + version from being imported. By default, it will abort + installation to alert you of the problem, but there are also + new options (‘--delete-conflicting’ and + ‘--ignore-conflicts-at-my-risk’) available to change the + default behavior. (Note: this new feature doesn’t take effect + for egg files that were built with older ‘setuptools’ + versions, because they lack the new metadata file required to + implement it.) + + * The ‘easy_install’ distutils command now uses ‘DistutilsError’ + as its base error type for errors that should just issue a + message to stderr and exit the program without a traceback. + + * EasyInstall can now be given a path to a directory containing + a setup script, and it will attempt to build and install the + package there. + + * EasyInstall now performs a safety analysis on module contents + to determine whether a package is likely to run in zipped + form, and displays information about what modules may be doing + introspection that would break when running as a zipfile. + + * Added the ‘--always-unzip/-Z’ option, to force unzipping of + packages that would ordinarily be considered safe to unzip, + and changed the meaning of ‘--zip-ok/-z’ to “always leave + everything zipped”. + + +File: setuptools.info, Node: 0 5a8, Next: 0 5a7, Prev: 0 5a9, Up: History<2> + +9.470 0.5a8 +=========== + + * The “egg_info” command now always sets the distribution + metadata to “safe” forms of the distribution name and version, + so that distribution files will be generated with parseable + names (i.e., ones that don’t include ‘-‘ in the name or + version). Also, this means that if you use the various + ‘--tag’ options of “egg_info”, any distributions generated + will use the tags in the version, not just egg distributions. + + * Added support for defining command aliases in distutils + configuration files, under the “[aliases]” section. To + prevent recursion and to allow aliases to call the command of + the same name, a given alias can be expanded only once per + command-line invocation. You can define new aliases with the + “alias” command, either for the local, global, or per-user + configuration. + + * Added “rotate” command to delete old distribution files, given + a set of patterns to match and the number of files to keep. + (Keeps the most recently-modified distribution files matching + each pattern.) + + * Added “saveopts” command that saves all command-line options + for the current invocation to the local, global, or per-user + configuration file. Useful for setting defaults without + having to hand-edit a configuration file. + + * Added a “setopt” command that sets a single option in a + specified distutils configuration file. + + * There is now a separate documentation page for setuptools; + revision history that’s not specific to EasyInstall has been + moved to that page. + + +File: setuptools.info, Node: 0 5a7, Next: 0 5a6, Prev: 0 5a8, Up: History<2> + +9.471 0.5a7 +=========== + + * Added “upload” support for egg and source distributions, + including a bug fix for “upload” and a temporary workaround + for lack of .egg support in PyPI. + + +File: setuptools.info, Node: 0 5a6, Next: 0 5a5, Prev: 0 5a7, Up: History<2> + +9.472 0.5a6 +=========== + + * Beefed up the “sdist” command so that if you don’t have a + MANIFEST.in, it will include all files under revision control + (CVS or Subversion) in the current directory, and it will + regenerate the list every time you create a source + distribution, not just when you tell it to. This should make + the default “do what you mean” more often than the distutils’ + default behavior did, while still retaining the old behavior + in the presence of MANIFEST.in. + + * Fixed the “develop” command always updating .pth files, even + if you specified ‘-n’ or ‘--dry-run’. + + * Slightly changed the format of the generated version when you + use ‘--tag-build’ on the “egg_info” command, so that you can + make tagged revisions compare `lower' than the version + specified in setup.py (e.g. by using ‘--tag-build=dev’). + + +File: setuptools.info, Node: 0 5a5, Next: 0 5a4, Prev: 0 5a6, Up: History<2> + +9.473 0.5a5 +=========== + + * Added ‘develop’ command to ‘setuptools’-based packages. This + command installs an ‘.egg-link’ pointing to the package’s + source directory, and script wrappers that ‘execfile()’ the + source versions of the package’s scripts. This lets you put + your development checkout(s) on sys.path without having to + actually install them. (To uninstall the link, use use + ‘setup.py develop --uninstall’.) + + * Added ‘egg_info’ command to ‘setuptools’-based packages. This + command just creates or updates the “projectname.egg-info” + directory, without building an egg. (It’s used by the + ‘bdist_egg’, ‘test’, and ‘develop’ commands.) + + * Enhanced the ‘test’ command so that it doesn’t install the + package, but instead builds any C extensions in-place, updates + the ‘.egg-info’ metadata, adds the source directory to + ‘sys.path’, and runs the tests directly on the source. This + avoids an “unmanaged” installation of the package to + ‘site-packages’ or elsewhere. + + * Made ‘easy_install’ a standard ‘setuptools’ command, moving it + from the ‘easy_install’ module to + ‘setuptools.command.easy_install’. Note that if you were + importing or extending it, you must now change your imports + accordingly. ‘easy_install.py’ is still installed as a + script, but not as a module. + + +File: setuptools.info, Node: 0 5a4, Next: 0 5a3, Prev: 0 5a5, Up: History<2> + +9.474 0.5a4 +=========== + + * Setup scripts using setuptools can now list their dependencies + directly in the setup.py file, without having to manually + create a ‘depends.txt’ file. The ‘install_requires’ and + ‘extras_require’ arguments to ‘setup()’ are used to create a + dependencies file automatically. If you are manually creating + ‘depends.txt’ right now, please switch to using these setup + arguments as soon as practical, because ‘depends.txt’ support + will be removed in the 0.6 release cycle. For documentation + on the new arguments, see the ‘setuptools.dist.Distribution’ + class. + + * Setup scripts using setuptools now always install using + ‘easy_install’ internally, for ease of uninstallation and + upgrading. + + * Added ‘--always-copy/-a’ option to always copy needed packages + to the installation directory, even if they’re already present + elsewhere on sys.path. (In previous versions, this was the + default behavior, but now you must request it.) + + * Added ‘--upgrade/-U’ option to force checking PyPI for latest + available version(s) of all packages requested by name and + version, even if a matching version is available locally. + + * Added automatic installation of dependencies declared by a + distribution being installed. These dependencies must be + listed in the distribution’s ‘EGG-INFO’ directory, so the + distribution has to have declared its dependencies by using + setuptools. If a package has requirements it didn’t declare, + you’ll still have to deal with them yourself. (E.g., by + asking EasyInstall to find and install them.) + + * Added the ‘--record’ option to ‘easy_install’ for the benefit + of tools that run ‘setup.py install --record=filename’ on + behalf of another packaging system.) + + +File: setuptools.info, Node: 0 5a3, Next: 0 5a2, Prev: 0 5a4, Up: History<2> + +9.475 0.5a3 +=========== + + * Fixed not setting script permissions to allow execution. + + * Improved sandboxing so that setup scripts that want a + temporary directory (e.g. pychecker) can still run in the + sandbox. + + +File: setuptools.info, Node: 0 5a2, Next: 0 5a1, Prev: 0 5a3, Up: History<2> + +9.476 0.5a2 +=========== + + * Fix stupid stupid refactoring-at-the-last-minute typos. :( + + +File: setuptools.info, Node: 0 5a1, Next: 0 4a4, Prev: 0 5a2, Up: History<2> + +9.477 0.5a1 +=========== + + * Added support for “self-installation” bootstrapping. Packages + can now include ‘ez_setup.py’ in their source distribution, + and add the following to their ‘setup.py’, in order to + automatically bootstrap installation of setuptools as part of + their setup process: + + from ez_setup import use_setuptools + use_setuptools() + + from setuptools import setup + # etc... + + * Added support for converting ‘.win32.exe’ installers to eggs + on the fly. EasyInstall will now recognize such files by name + and install them. + + * Fixed a problem with picking the “best” version to install + (versions were being sorted as strings, rather than as parsed + values) + + +File: setuptools.info, Node: 0 4a4, Next: 0 4a3, Prev: 0 5a1, Up: History<2> + +9.478 0.4a4 +=========== + + * Added support for the distutils “verbose/quiet” and “dry-run” + options, as well as the “optimize” flag. + + * Support downloading packages that were uploaded to PyPI (by + scanning all links on package pages, not just the + homepage/download links). + + +File: setuptools.info, Node: 0 4a3, Next: 0 4a2, Prev: 0 4a4, Up: History<2> + +9.479 0.4a3 +=========== + + * Add progress messages to the search/download process so that + you can tell what URLs it’s reading to find download links. + (Hopefully, this will help people report out-of-date and + broken links to package authors, and to tell when they’ve + asked for a package that doesn’t exist.) + + +File: setuptools.info, Node: 0 4a2, Next: 0 4a1, Prev: 0 4a3, Up: History<2> + +9.480 0.4a2 +=========== + + * Added ‘ez_setup.py’ installer/bootstrap script to make initial + setuptools installation easier, and to allow distributions + using setuptools to avoid having to include setuptools in + their source distribution. + + * All downloads are now managed by the ‘PackageIndex’ class + (which is now subclassable and replaceable), so that embedders + can more easily override download logic, give download + progress reports, etc. The class has also been moved to the + new ‘setuptools.package_index’ module. + + * The ‘Installer’ class no longer handles downloading, manages a + temporary directory, or tracks the ‘zip_ok’ option. + Downloading is now handled by ‘PackageIndex’, and ‘Installer’ + has become an ‘easy_install’ command class based on + ‘setuptools.Command’. + + * There is a new ‘setuptools.sandbox.run_setup()’ API to invoke + a setup script in a directory sandbox, and a new + ‘setuptools.archive_util’ module with an ‘unpack_archive()’ + API. These were split out of EasyInstall to allow reuse by + other tools and applications. + + * ‘setuptools.Command’ now supports reinitializing commands + using keyword arguments to set/reset options. Also, ‘Command’ + subclasses can now set their ‘command_consumes_arguments’ + attribute to ‘True’ in order to receive an ‘args’ option + containing the rest of the command line. + + * Added support for installing scripts + + * Added support for setting options via distutils configuration + files, and using distutils’ default options as a basis for + EasyInstall’s defaults. + + * Renamed ‘--scan-url/-s’ to ‘--find-links/-f’ to free up ‘-s’ + for the script installation directory option. + + * Use ‘urllib2’ instead of ‘urllib’, to allow use of ‘https:’ + URLs if Python includes SSL support. + + +File: setuptools.info, Node: 0 4a1, Next: 0 3a4, Prev: 0 4a2, Up: History<2> + +9.481 0.4a1 +=========== + + * Added ‘--scan-url’ and ‘--index-url’ options, to scan download + pages and search PyPI for needed packages. + + +File: setuptools.info, Node: 0 3a4, Next: 0 3a3, Prev: 0 4a1, Up: History<2> + +9.482 0.3a4 +=========== + + * Restrict ‘--build-directory=DIR/-b DIR’ option to only be used + with single URL installs, to avoid running the wrong setup.py. + + +File: setuptools.info, Node: 0 3a3, Next: 0 3a2, Prev: 0 3a4, Up: History<2> + +9.483 0.3a3 +=========== + + * Added ‘--build-directory=DIR/-b DIR’ option. + + * Added “installation report” that explains how to use + ‘require()’ when doing a multiversion install or alternate + installation directory. + + * Added SourceForge mirror auto-select (Contributed by Ian + Bicking) + + * Added “sandboxing” that stops a setup script from running if + it attempts to write to the filesystem outside of the build + area + + * Added more workarounds for packages with quirky ‘install_data’ + hacks + + +File: setuptools.info, Node: 0 3a2, Next: 0 3a1, Prev: 0 3a3, Up: History<2> + +9.484 0.3a2 +=========== + + * Added new options to ‘bdist_egg’ to allow tagging the egg’s + version number with a subversion revision number, the current + date, or an explicit tag value. Run ‘setup.py bdist_egg + --help’ to get more information. + + * Added subversion download support for ‘svn:’ and ‘svn+’ URLs, + as well as automatic recognition of HTTP subversion URLs + (Contributed by Ian Bicking) + + * Misc. bug fixes + + +File: setuptools.info, Node: 0 3a1, Prev: 0 3a2, Up: History<2> + +9.485 0.3a1 +=========== + + * Initial release. + + +File: setuptools.info, Node: Credits, Next: Index, Prev: History<2>, Up: Top + +10 Credits +********** + + * The original design for the ‘.egg’ format and the ‘pkg_resources’ + API was co-created by Phillip Eby and Bob Ippolito. Bob also + implemented the first version of ‘pkg_resources’, and supplied the + macOS operating system version compatibility algorithm. + + * Ian Bicking implemented many early “creature comfort” features of + easy_install, including support for downloading via Sourceforge and + Subversion repositories. Ian’s comments on the Web-SIG about WSGI + application deployment also inspired the concept of “entry points” + in eggs, and he has given talks at PyCon and elsewhere to inform + and educate the community about eggs and setuptools. + + * Jim Fulton contributed time and effort to build automated tests of + various aspects of ‘easy_install’, and supplied the doctests for + the command-line ‘.exe’ wrappers on Windows. + + * Phillip J. Eby is the seminal author of setuptools, and first + proposed the idea of an importable binary distribution format for + Python application plug-ins. + + * Significant parts of the implementation of setuptools were funded + by the Open Source Applications Foundation, to provide a plug-in + infrastructure for the Chandler PIM application. In addition, many + OSAF staffers (such as Mike “Code Bear” Taylor) contributed their + time and stress as guinea pigs for the use of eggs and setuptools, + even before eggs were “cool”. (Thanks, guys!) + + * Tarek Ziadé is the principal author of the Distribute fork, which + re-invigorated the community on the project, encouraged renewed + innovation, and addressed many defects. + + * Jason R. Coombs performed the merge with Distribute, maintaining + the project for several years in coordination with the Python + Packaging Authority (PyPA). + + +File: setuptools.info, Node: Index, Prev: Credits, Up: Top + +Index +***** + + +* Menu: + +* Python Enhancement Proposals; PEP 370: Command-Line Options. + (line 100) +* Python Enhancement Proposals; PEP 517: Configuring setup using setup cfg files. + (line 9) +* Python Enhancement Proposals; PEP 517 <1>: setup cfg-only projects. + (line 8) +* Python Enhancement Proposals; PEP 517 <2>: setup cfg-only projects. + (line 12) +* Python Enhancement Proposals; PEP 517 <3>: setup cfg-only projects. + (line 13) +* Python Enhancement Proposals; PEP 517 <4>: setup cfg-only projects. + (line 18) +* Python Enhancement Proposals; PEP 517 <5>: setup cfg-only projects. + (line 23) +* Python Enhancement Proposals; PEP 517 <6>: setup cfg-only projects. + (line 33) +* Python Enhancement Proposals; PEP 517 <7>: setup cfg-only projects. + (line 36) +* Python Enhancement Proposals; PEP 517#build-requirements: Python packaging at a glance. + (line 13) +* Python Enhancement Proposals; PEP 518: setup cfg-only projects. + (line 18) + + + +Tag Table: +Node: Top367 +Ref: index doc615 +Ref: 0615 +Node: Building and Distributing Packages with Setuptools22415 +Ref: userguide/index doc22550 +Ref: 122550 +Ref: userguide/index building-and-distributing-packages-with-setuptools22550 +Ref: 222550 +Ref: userguide/index documentation22550 +Ref: 322550 +Node: Transition to PEP51723037 +Ref: userguide/index transition-to-pep51723148 +Ref: 423148 +Node: setuptools Quickstart24269 +Ref: userguide/quickstart doc24399 +Ref: 624399 +Ref: userguide/quickstart setuptools-quickstart24399 +Ref: 724399 +Node: Installation24844 +Ref: userguide/quickstart installation24955 +Ref: 824955 +Node: Python packaging at a glance25088 +Ref: userguide/quickstart python-packaging-at-a-glance25217 +Ref: 925217 +Ref: Python packaging at a glance-Footnote-125977 +Ref: Python packaging at a glance-Footnote-226045 +Node: Basic Use26080 +Ref: userguide/quickstart basic-use26224 +Ref: a26224 +Ref: Basic Use-Footnote-127806 +Node: Automatic package discovery27847 +Ref: userguide/quickstart automatic-package-discovery28005 +Ref: b28005 +Node: Entry points and automatic script creation29156 +Ref: userguide/quickstart entry-points-and-automatic-script-creation29326 +Ref: d29326 +Node: Dependency management30140 +Ref: userguide/quickstart dependency-management30303 +Ref: f30303 +Node: Including Data Files31432 +Ref: userguide/quickstart id131569 +Ref: 1131569 +Ref: userguide/quickstart including-data-files31569 +Ref: 1231569 +Node: Development mode32179 +Ref: userguide/quickstart development-mode32325 +Ref: 1432325 +Node: Uploading your package to PyPI32997 +Ref: userguide/quickstart uploading-your-package-to-pypi33163 +Ref: 1533163 +Ref: Uploading your package to PyPI-Footnote-133482 +Node: Transitioning from setup py to setup cfg33522 +Ref: userguide/quickstart transitioning-from-setup-py-to-setup-cfg33701 +Ref: 1633701 +Node: Resources on Python packaging34195 +Ref: userguide/quickstart resources-on-python-packaging34335 +Ref: 1734335 +Node: Package Discovery and Namespace Package34512 +Ref: userguide/package_discovery doc34663 +Ref: 1834663 +Ref: userguide/package_discovery package-discovery34663 +Ref: c34663 +Ref: userguide/package_discovery package-discovery-and-namespace-package34663 +Ref: 1934663 +Node: Using find or find_packages36066 +Ref: userguide/package_discovery using-find-or-find-packages36229 +Ref: 1b36229 +Node: Using find_namespace or find_namespace_packages37302 +Ref: userguide/package_discovery namespace-packages37499 +Ref: 1c37499 +Ref: userguide/package_discovery using-find-namespace-or-find-namespace-packages37499 +Ref: 1d37499 +Node: Legacy Namespace Packages39655 +Ref: userguide/package_discovery legacy-namespace-packages39816 +Ref: 1e39816 +Ref: Legacy Namespace Packages-Footnote-140601 +Ref: Legacy Namespace Packages-Footnote-240651 +Node: pkg_resource style namespace package40725 +Ref: userguide/package_discovery pkg-resource-style-namespace-package40867 +Ref: 1f40867 +Node: pkgutil style namespace package41764 +Ref: userguide/package_discovery pkgutil-style-namespace-package41906 +Ref: 2041906 +Node: Entry Points42319 +Ref: userguide/entry_point doc42486 +Ref: e42486 +Ref: userguide/entry_point entry-points42486 +Ref: 2142486 +Ref: userguide/entry_point id142486 +Ref: 2242486 +Node: Console Scripts42830 +Ref: userguide/entry_point console-scripts42927 +Ref: 2342927 +Ref: Console Scripts-Footnote-144615 +Node: Advertising Behavior44668 +Ref: userguide/entry_point advertising-behavior44795 +Ref: 2444795 +Ref: userguide/entry_point dynamic-discovery-of-services-and-plugins44795 +Ref: 2544795 +Ref: Advertising Behavior-Footnote-146935 +Ref: Advertising Behavior-Footnote-246998 +Ref: Advertising Behavior-Footnote-347064 +Node: Dependency Management47116 +Ref: userguide/entry_point dependency-management47219 +Ref: 2647219 +Node: Dependencies Management in Setuptools48070 +Ref: userguide/dependency_management doc48216 +Ref: 1048216 +Ref: userguide/dependency_management dependencies-management-in-setuptools48216 +Ref: 2748216 +Ref: Dependencies Management in Setuptools-Footnote-148731 +Node: Build system requirement48781 +Ref: userguide/dependency_management build-system-requirement48921 +Ref: 2848921 +Node: Package requirement49022 +Ref: userguide/dependency_management package-requirement49106 +Ref: 2949106 +Node: Declaring required dependency50070 +Ref: userguide/dependency_management declaring-dependencies50240 +Ref: 2b50240 +Ref: userguide/dependency_management declaring-required-dependency50240 +Ref: 2c50240 +Node: Platform specific dependencies51217 +Ref: userguide/dependency_management platform-specific-dependencies51360 +Ref: 2d51360 +Ref: Platform specific dependencies-Footnote-152614 +Node: Dependencies that aren’t in PyPI52664 +Ref: userguide/dependency_management dependencies-that-aren-t-in-pypi52807 +Ref: 2e52807 +Node: Optional dependencies55587 +Ref: userguide/dependency_management optional-dependencies55751 +Ref: 2f55751 +Node: Python requirement58781 +Ref: userguide/dependency_management python-requirement58907 +Ref: 3058907 +Node: Data Files Support59157 +Ref: userguide/datafiles doc59313 +Ref: 1359313 +Ref: userguide/datafiles data-files-support59313 +Ref: 3159313 +Ref: Data Files Support-Footnote-165829 +Node: Accessing Data Files at Runtime65915 +Ref: userguide/datafiles accessing-data-files-at-runtime66036 +Ref: 3366036 +Ref: userguide/datafiles id266036 +Ref: 3466036 +Ref: Accessing Data Files at Runtime-Footnote-166883 +Node: Non-Package Data Files66968 +Ref: userguide/datafiles importlib-resources67089 +Ref: 3667089 +Ref: userguide/datafiles non-package-data-files67089 +Ref: 3767089 +Ref: Non-Package Data Files-Footnote-167639 +Node: “Development Mode”67760 +Ref: userguide/development_mode doc67935 +Ref: 3867935 +Ref: userguide/development_mode development-mode67935 +Ref: 3967935 +Node: Tagging and “Daily Build” or “Snapshot” Releases71275 +Ref: userguide/distribution doc71463 +Ref: 3b71463 +Ref: userguide/distribution tagging-and-daily-build-or-snapshot-releases71463 +Ref: 3c71463 +Node: Generating Source Distributions74524 +Ref: userguide/distribution generating-source-distributions74734 +Ref: 4174734 +Node: Making “Official” Non-Snapshot Releases76624 +Ref: userguide/distribution making-official-non-snapshot-releases76739 +Ref: 4276739 +Node: Distributing Extensions compiled with Cython78161 +Ref: userguide/distribution distributing-extensions-compiled-with-cython78350 +Ref: 4378350 +Node: Specifying Your Project’s Version79935 +Ref: userguide/distribution id180122 +Ref: 4480122 +Ref: userguide/distribution specifying-your-project-s-version80122 +Ref: 3e80122 +Node: Creating distutils Extensions85080 +Ref: userguide/extension doc85262 +Ref: 4585262 +Ref: userguide/extension creating-distutils-extensions85262 +Ref: 4685262 +Ref: userguide/extension id185262 +Ref: 4785262 +Node: Adding Commands86205 +Ref: userguide/extension adding-commands86321 +Ref: 4886321 +Node: Adding setup Arguments87585 +Ref: userguide/extension adding-setup-arguments87742 +Ref: 4987742 +Node: Customizing Distribution Options90361 +Ref: userguide/extension customizing-distribution-options90528 +Ref: 4a90528 +Node: Adding new EGG-INFO Files91395 +Ref: userguide/extension adding-new-egg-info-files91583 +Ref: 4b91583 +Ref: userguide/extension id291583 +Ref: 4c91583 +Node: Adding Support for Revision Control Systems94085 +Ref: userguide/extension adding-support-for-revision-control-systems94232 +Ref: 3294232 +Ref: userguide/extension id394232 +Ref: 4d94232 +Ref: Adding Support for Revision Control Systems-Footnote-197167 +Ref: Adding Support for Revision Control Systems-Footnote-297216 +Node: Configuring setup using setup cfg files97265 +Ref: userguide/declarative_config doc97442 +Ref: 4e97442 +Ref: userguide/declarative_config configuring-setup-using-setup-cfg-files97442 +Ref: 4f97442 +Ref: userguide/declarative_config declarative-config97442 +Ref: 5097442 +Ref: Configuring setup using setup cfg files-Footnote-1100442 +Node: Using a src/ layout100491 +Ref: userguide/declarative_config using-a-src-layout100616 +Ref: 51100616 +Node: Specifying values101349 +Ref: userguide/declarative_config specifying-values101474 +Ref: 52101474 +Node: Metadata102746 +Ref: userguide/declarative_config metadata102828 +Ref: 53102828 +Node: Options108439 +Ref: userguide/declarative_config options108521 +Ref: 54108521 +Node: New and Changed setup Keywords113055 +Ref: userguide/keywords doc113220 +Ref: 1a113220 +Ref: userguide/keywords new-and-changed-setup-keywords113220 +Ref: 55113220 +Ref: userguide/keywords test-loader119892 +Ref: 57119892 +Node: Command Reference123156 +Ref: userguide/commands doc123337 +Ref: 5a123337 +Ref: userguide/commands command-reference123337 +Ref: 5b123337 +Node: alias - Define shortcuts for commonly used commands123908 +Ref: userguide/commands alias124073 +Ref: 40124073 +Ref: userguide/commands alias-define-shortcuts-for-commonly-used-commands124073 +Ref: 5c124073 +Node: bdist_egg - Create a Python Egg for the project127121 +Ref: userguide/commands bdist-egg-create-a-python-egg-for-the-project127356 +Ref: 5f127356 +Node: develop - Deploy the project source in “Development Mode”131349 +Ref: userguide/commands develop131582 +Ref: 3a131582 +Ref: userguide/commands develop-deploy-the-project-source-in-development-mode131582 +Ref: 60131582 +Node: egg_info - Create egg metadata and set build tags138553 +Ref: userguide/commands egg-info138782 +Ref: 3d138782 +Ref: userguide/commands egg-info-create-egg-metadata-and-set-build-tags138782 +Ref: 61138782 +Node: Release Tagging Options140219 +Ref: userguide/commands release-tagging-options140363 +Ref: 62140363 +Node: Other egg_info Options142521 +Ref: userguide/commands other-egg-info-options142691 +Ref: 63142691 +Node: egg_info Examples143364 +Ref: userguide/commands egg-info-examples143502 +Ref: 64143502 +Node: rotate - Delete outdated distribution files143966 +Ref: userguide/commands rotate144186 +Ref: 3f144186 +Ref: userguide/commands rotate-delete-outdated-distribution-files144186 +Ref: 65144186 +Node: saveopts - Save used options to a configuration file146091 +Ref: userguide/commands saveopts146324 +Ref: 5e146324 +Ref: userguide/commands saveopts-save-used-options-to-a-configuration-file146324 +Ref: 66146324 +Node: Configuration File Options147929 +Ref: userguide/commands configuration-file-options148048 +Ref: 5d148048 +Node: setopt - Set a distutils or setuptools option in a config file149367 +Ref: userguide/commands setopt149602 +Ref: 67149602 +Ref: userguide/commands setopt-set-a-distutils-or-setuptools-option-in-a-config-file149602 +Ref: 68149602 +Node: test - Build package and run a unittest suite150985 +Ref: userguide/commands test151223 +Ref: 56151223 +Ref: userguide/commands test-build-package-and-run-a-unittest-suite151223 +Ref: 69151223 +Ref: test - Build package and run a unittest suite-Footnote-1154185 +Node: upload - Upload source and/or egg distributions to PyPI154220 +Ref: userguide/commands upload154387 +Ref: 6a154387 +Ref: userguide/commands upload-upload-source-and-or-egg-distributions-to-pypi154387 +Ref: 6b154387 +Ref: upload - Upload source and/or egg distributions to PyPI-Footnote-1154910 +Ref: upload - Upload source and/or egg distributions to PyPI-Footnote-2154943 +Node: Using setuptools to package and distribute your project155047 +Ref: userguide/functionalities_rewrite doc155227 +Ref: 6c155227 +Ref: userguide/functionalities_rewrite using-setuptools-to-package-and-distribute-your-project155227 +Ref: 6d155227 +Node: Automatic Resource Extraction155527 +Ref: userguide/miscellaneous doc155718 +Ref: 6e155718 +Ref: userguide/miscellaneous automatic-resource-extraction155718 +Ref: 58155718 +Ref: userguide/miscellaneous id1155718 +Ref: 6f155718 +Node: Defining Additional Metadata157957 +Ref: userguide/miscellaneous defining-additional-metadata158118 +Ref: 70158118 +Node: Setting the zip_safe flag158928 +Ref: userguide/miscellaneous setting-the-zip-safe-flag159051 +Ref: 71159051 +Node: Build System Support161810 +Ref: build_meta doc161999 +Ref: 5161999 +Ref: build_meta build-system-support161999 +Ref: 72161999 +Node: What is it?162091 +Ref: build_meta what-is-it162186 +Ref: 73162186 +Ref: What is it?-Footnote-1163895 +Ref: What is it?-Footnote-2163940 +Node: How to use it?163990 +Ref: build_meta how-to-use-it164085 +Ref: 74164085 +Ref: How to use it?-Footnote-1165455 +Ref: How to use it?-Footnote-2165517 +Node: Package Discovery and Resource Access using pkg_resources165557 +Ref: pkg_resources doc165704 +Ref: 75165704 +Ref: pkg_resources package-discovery-and-resource-access-using-pkg-resources165704 +Ref: 76165704 +Node: Overview166350 +Ref: pkg_resources overview166478 +Ref: 77166478 +Ref: Overview-Footnote-1170904 +Node: API Reference170982 +Ref: pkg_resources api-reference171110 +Ref: 78171110 +Node: Namespace Package Support171426 +Ref: pkg_resources namespace-package-support171532 +Ref: 79171532 +Node: WorkingSet Objects174056 +Ref: pkg_resources workingset-objects174190 +Ref: 7b174190 +Node: Basic WorkingSet Methods176726 +Ref: pkg_resources basic-workingset-methods176851 +Ref: 7c176851 +Node: WorkingSet Methods and Attributes180619 +Ref: pkg_resources workingset-methods-and-attributes180783 +Ref: 80180783 +Node: Receiving Change Notifications184950 +Ref: pkg_resources receiving-change-notifications185106 +Ref: 82185106 +Node: Locating Plugins186449 +Ref: pkg_resources locating-plugins186563 +Ref: 83186563 +Node: Environment Objects190673 +Ref: pkg_resources environment-objects190801 +Ref: 81190801 +Node: Requirement Objects196336 +Ref: pkg_resources requirement-objects196461 +Ref: 84196461 +Node: Requirements Parsing196840 +Ref: pkg_resources requirements-parsing196963 +Ref: 7d196963 +Node: Requirement Methods and Attributes199298 +Ref: pkg_resources requirement-methods-and-attributes199421 +Ref: 85199421 +Node: Entry Points<2>202078 +Ref: pkg_resources entry-points202204 +Ref: 7f202204 +Node: Convenience API204711 +Ref: pkg_resources convenience-api204811 +Ref: 86204811 +Node: Creating and Parsing207221 +Ref: pkg_resources creating-and-parsing207348 +Ref: 87207348 +Node: EntryPoint Objects210392 +Ref: pkg_resources entrypoint-objects210495 +Ref: 88210495 +Node: Distribution Objects211979 +Ref: pkg_resources distribution-objects212105 +Ref: 89212105 +Node: Getting or Creating Distributions212593 +Ref: pkg_resources getting-or-creating-distributions212719 +Ref: 8a212719 +Node: Distribution Attributes216620 +Ref: pkg_resources distribution-attributes216775 +Ref: 8d216775 +Node: Distribution Methods220522 +Ref: pkg_resources distribution-methods220635 +Ref: 90220635 +Node: ResourceManager API225533 +Ref: pkg_resources id1225656 +Ref: 91225656 +Ref: pkg_resources resourcemanager-api225656 +Ref: 35225656 +Node: Basic Resource Access226588 +Ref: pkg_resources basic-resource-access226697 +Ref: 92226697 +Node: Resource Extraction229834 +Ref: pkg_resources resource-extraction229976 +Ref: 93229976 +Node: “Provider” Interface232647 +Ref: pkg_resources provider-interface232759 +Ref: 94232759 +Node: Metadata API235052 +Ref: pkg_resources metadata-api235165 +Ref: 7e235165 +Node: IMetadataProvider Methods237259 +Ref: pkg_resources imetadataprovider-methods237337 +Ref: 8c237337 +Node: Exceptions238661 +Ref: pkg_resources exceptions238782 +Ref: 96238782 +Node: Supporting Custom Importers240205 +Ref: pkg_resources supporting-custom-importers240331 +Ref: 7a240331 +Node: IResourceProvider242930 +Ref: pkg_resources iresourceprovider243051 +Ref: 8b243051 +Node: Built-in Resource Providers244880 +Ref: pkg_resources built-in-resource-providers245001 +Ref: 97245001 +Node: Utility Functions248068 +Ref: pkg_resources utility-functions248175 +Ref: 98248175 +Node: Parsing Utilities248556 +Ref: pkg_resources parsing-utilities248658 +Ref: 8e248658 +Ref: pkg_resources yield-lines249212 +Ref: 95249212 +Node: Platform Utilities253345 +Ref: pkg_resources platform-utilities253473 +Ref: 8f253473 +Node: PEP 302 Utilities255688 +Ref: pkg_resources pep-302-utilities255818 +Ref: 99255818 +Node: File/Path Utilities255962 +Ref: pkg_resources file-path-utilities256081 +Ref: 9a256081 +Node: History256902 +Ref: pkg_resources history256995 +Ref: 9b256995 +Node: Keywords270832 +Ref: references/keywords doc270966 +Ref: 9c270966 +Ref: references/keywords keywords270966 +Ref: 9d270966 +Ref: references/keywords test-loader282821 +Ref: 9e282821 +Ref: Keywords-Footnote-1286193 +Ref: Keywords-Footnote-2286243 +Node: Roadmap286292 +Ref: roadmap doc286422 +Ref: 9f286422 +Ref: roadmap roadmap286422 +Ref: a0286422 +Ref: Roadmap-Footnote-1286568 +Node: Building and Distributing Packages with Setuptools<2>286622 +Ref: setuptools doc286769 +Ref: a1286769 +Ref: setuptools building-and-distributing-packages-with-setuptools286769 +Ref: a2286769 +Ref: Building and Distributing Packages with Setuptools<2>-Footnote-1289138 +Node: Developer’s Guide289197 +Ref: setuptools developer-s-guide289310 +Ref: a3289310 +Node: TRANSITIONAL NOTE289389 +Ref: setuptools transitional-note289466 +Ref: a4289466 +Node: setup cfg-only projects290789 +Ref: setuptools setup-cfg-only-projects290896 +Ref: a5290896 +Ref: setup cfg-only projects-Footnote-1292299 +Ref: setup cfg-only projects-Footnote-2292348 +Ref: setup cfg-only projects-Footnote-3292397 +Ref: setup cfg-only projects-Footnote-4292446 +Ref: setup cfg-only projects-Footnote-5292495 +Ref: setup cfg-only projects-Footnote-6292544 +Ref: setup cfg-only projects-Footnote-7292593 +Ref: setup cfg-only projects-Footnote-8292642 +Node: Configuration API292691 +Ref: setuptools configuration-api292835 +Ref: a6292835 +Node: Mailing List and Bug Tracker293857 +Ref: setuptools mailing-list-and-bug-tracker293969 +Ref: a7293969 +Ref: Mailing List and Bug Tracker-Footnote-1294339 +Ref: Mailing List and Bug Tracker-Footnote-2294395 +Node: Development on Setuptools294439 +Ref: development/index doc294633 +Ref: a8294633 +Ref: development/index development-on-setuptools294633 +Ref: a9294633 +Ref: development/index setuptools-bug-tracker294633 +Ref: aa294633 +Node: Developer’s Guide for Setuptools296088 +Ref: development/developer-guide doc296212 +Ref: ab296212 +Ref: development/developer-guide developer-s-guide-for-setuptools296212 +Ref: ac296212 +Node: Recommended Reading296586 +Ref: development/developer-guide recommended-reading296707 +Ref: ad296707 +Ref: Recommended Reading-Footnote-1297098 +Node: Project Management297165 +Ref: development/developer-guide project-management297312 +Ref: ae297312 +Ref: Project Management-Footnote-1297899 +Ref: Project Management-Footnote-2297942 +Ref: Project Management-Footnote-3298015 +Node: Authoring Tickets298057 +Ref: development/developer-guide authoring-tickets298206 +Ref: af298206 +Node: Making a pull request299312 +Ref: development/developer-guide making-a-pull-request299462 +Ref: b0299462 +Node: Adding change notes with your PRs299928 +Ref: development/developer-guide adding-change-notes-with-your-prs300071 +Ref: b1300071 +Ref: development/developer-guide id1300071 +Ref: b2300071 +Ref: Adding change notes with your PRs-Footnote-1300998 +Node: Alright! So how to add a news fragment?301076 +Ref: development/developer-guide alright-so-how-to-add-a-news-fragment301287 +Ref: b3301287 +Ref: Alright! So how to add a news fragment?-Footnote-1303484 +Node: Examples for adding changelog entries to your Pull Requests303528 +Ref: development/developer-guide examples-for-adding-changelog-entries-to-your-pull-requests303697 +Ref: b4303697 +Node: Auto-Merge Requests304303 +Ref: development/developer-guide auto-merge-requests304443 +Ref: b5304443 +Ref: development/developer-guide towncrier-philosophy304443 +Ref: b6304443 +Node: Testing304769 +Ref: development/developer-guide testing304907 +Ref: b7304907 +Node: Semantic Versioning305179 +Ref: development/developer-guide semantic-versioning305320 +Ref: b8305320 +Node: Building Documentation305407 +Ref: development/developer-guide building-documentation305562 +Ref: b9305562 +Ref: Building Documentation-Footnote-1305844 +Ref: Building Documentation-Footnote-2305889 +Node: Vendored Dependencies305942 +Ref: development/developer-guide published-documentation306069 +Ref: ba306069 +Ref: development/developer-guide vendored-dependencies306069 +Ref: bb306069 +Ref: Vendored Dependencies-Footnote-1306650 +Node: Release Process306704 +Ref: development/releases doc306828 +Ref: bc306828 +Ref: development/releases release-process306828 +Ref: bd306828 +Node: Release Frequency307216 +Ref: development/releases release-frequency307314 +Ref: be307314 +Node: Release Managers308292 +Ref: development/releases release-managers308390 +Ref: bf308390 +Node: Guides on backward compatibility & deprecated practice308525 +Ref: deprecated/index doc308676 +Ref: 2a308676 +Ref: deprecated/index guides-on-backward-compatibility-deprecated-practice308676 +Ref: c0308676 +Node: Supporting both Python 2 and Python 3 with Setuptools309462 +Ref: deprecated/python3 doc309656 +Ref: 59309656 +Ref: deprecated/python3 supporting-both-python-2-and-python-3-with-setuptools309656 +Ref: c1309656 +Ref: Supporting both Python 2 and Python 3 with Setuptools-Footnote-1310381 +Ref: Supporting both Python 2 and Python 3 with Setuptools-Footnote-2310419 +Node: Using 2to3310460 +Ref: deprecated/python3 using-2to3310602 +Ref: c2310602 +Node: Differential conversion312551 +Ref: deprecated/python3 differential-conversion312625 +Ref: c3312625 +Node: Distributing Python 3 modules313446 +Ref: deprecated/python3 distributing-python-3-modules313614 +Ref: c4313614 +Node: Advanced features314070 +Ref: deprecated/python3 advanced-features314219 +Ref: c5314219 +Node: The Internal Structure of Python Eggs314429 +Ref: deprecated/python_eggs doc314644 +Ref: c6314644 +Ref: deprecated/python_eggs the-internal-structure-of-python-eggs314644 +Ref: c7314644 +Node: Eggs and their Formats314878 +Ref: deprecated/python_eggs eggs-and-their-formats315004 +Ref: c8315004 +Node: Code and Resources318188 +Ref: deprecated/python_eggs code-and-resources318294 +Ref: c9318294 +Node: Project Metadata319082 +Ref: deprecated/python_eggs project-metadata319223 +Ref: ca319223 +Node: Filename-Embedded Metadata321015 +Ref: deprecated/python_eggs filename-embedded-metadata321147 +Ref: cc321147 +Node: Egg Links323662 +Ref: deprecated/python_eggs egg-links323769 +Ref: cd323769 +Node: Standard Metadata325841 +Ref: deprecated/python_eggs standard-metadata326006 +Ref: cb326006 +Node: txt File Formats327581 +Ref: deprecated/python_eggs txt-file-formats327683 +Ref: ce327683 +Node: Dependency Metadata328856 +Ref: deprecated/python_eggs dependency-metadata329020 +Ref: cf329020 +Node: requires txt329290 +Ref: deprecated/python_eggs requires-txt329389 +Ref: d0329389 +Node: setup_requires txt330435 +Ref: deprecated/python_eggs setup-requires-txt330563 +Ref: d1330563 +Node: dependency_links txt330760 +Ref: deprecated/python_eggs dependency-links-txt330915 +Ref: d2330915 +Node: depends txt – Obsolete do not create!331273 +Ref: deprecated/python_eggs depends-txt-obsolete-do-not-create331401 +Ref: d3331401 +Node: namespace_packages txt – Namespace Package Metadata332008 +Ref: deprecated/python_eggs namespace-packages-txt-namespace-package-metadata332210 +Ref: d4332210 +Node: entry_points txt – “Entry Point”/Plugin Metadata332571 +Ref: deprecated/python_eggs entry-points-txt-entry-point-plugin-metadata332778 +Ref: d5332778 +Node: The scripts Subdirectory333650 +Ref: deprecated/python_eggs the-scripts-subdirectory333824 +Ref: d6333824 +Node: Zip Support Metadata334781 +Ref: deprecated/python_eggs zip-support-metadata334947 +Ref: d9334947 +Node: native_libs txt335128 +Ref: deprecated/python_eggs native-libs-txt335232 +Ref: da335232 +Node: eager_resources txt335897 +Ref: deprecated/python_eggs eager-resources-txt336035 +Ref: dc336035 +Node: zip-safe and not-zip-safe336653 +Ref: deprecated/python_eggs zip-safe-and-not-zip-safe336767 +Ref: dd336767 +Node: top_level txt – Conflict Management Metadata337816 +Ref: deprecated/python_eggs top-level-txt-conflict-management-metadata337995 +Ref: de337995 +Node: SOURCES txt – Source Files Manifest338804 +Ref: deprecated/python_eggs sources-txt-source-files-manifest338954 +Ref: df338954 +Node: Other Technical Considerations340189 +Ref: deprecated/python_eggs other-technical-considerations340323 +Ref: e0340323 +Node: Zip File Issues340472 +Ref: deprecated/python_eggs zip-file-issues340606 +Ref: db340606 +Node: The Extraction Process341840 +Ref: deprecated/python_eggs the-extraction-process341952 +Ref: e1341952 +Node: Extension Import Wrappers343133 +Ref: deprecated/python_eggs extension-import-wrappers343245 +Ref: e2343245 +Node: Installation and Path Management Issues344580 +Ref: deprecated/python_eggs installation-and-path-management-issues344714 +Ref: d8344714 +Node: Script Wrappers349270 +Ref: deprecated/python_eggs script-wrappers349365 +Ref: d7349365 +Node: Easy Install351737 +Ref: deprecated/easy_install doc351921 +Ref: e3351921 +Ref: deprecated/easy_install easy-install351921 +Ref: e4351921 +Ref: Easy Install-Footnote-1353191 +Node: Using “Easy Install”353247 +Ref: deprecated/easy_install using-easy-install353349 +Ref: e5353349 +Node: Installing “Easy Install”353732 +Ref: deprecated/easy_install installation-instructions353871 +Ref: e6353871 +Ref: deprecated/easy_install installing-easy-install353871 +Ref: e7353871 +Ref: Installing “Easy Install”-Footnote-1355301 +Ref: Installing “Easy Install”-Footnote-2355346 +Node: Troubleshooting355377 +Ref: deprecated/easy_install troubleshooting355484 +Ref: eb355484 +Node: Windows Notes356373 +Ref: deprecated/easy_install windows-notes356480 +Ref: ec356480 +Node: Downloading and Installing a Package356831 +Ref: deprecated/easy_install downloading-and-installing-a-package356998 +Ref: ee356998 +Ref: Downloading and Installing a Package-Footnote-1360432 +Node: Upgrading a Package360491 +Ref: deprecated/easy_install upgrading-a-package360656 +Ref: f1360656 +Node: Changing the Active Version362592 +Ref: deprecated/easy_install changing-the-active-version362742 +Ref: f3362742 +Node: Uninstalling Packages363810 +Ref: deprecated/easy_install uninstalling-packages363957 +Ref: f2363957 +Node: Managing Scripts364611 +Ref: deprecated/easy_install managing-scripts364756 +Ref: f4364756 +Ref: Managing Scripts-Footnote-1366587 +Node: Executables and Launchers366619 +Ref: deprecated/easy_install executables-and-launchers366760 +Ref: ed366760 +Node: Windows Executable Launcher368152 +Ref: deprecated/easy_install windows-executable-launcher368277 +Ref: f5368277 +Node: Natural Script Launcher368775 +Ref: deprecated/easy_install natural-script-launcher368900 +Ref: f6368900 +Ref: Natural Script Launcher-Footnote-1369909 +Node: Tips & Techniques369955 +Ref: deprecated/easy_install tips-techniques370104 +Ref: f7370104 +Node: Multiple Python Versions370360 +Ref: deprecated/easy_install multiple-python-versions370491 +Ref: f8370491 +Node: Restricting Downloads with --allow-hosts371060 +Ref: deprecated/easy_install restricting-downloads-with-allow-hosts371235 +Ref: e9371235 +Node: Installing on Un-networked Machines372141 +Ref: deprecated/easy_install installing-on-un-networked-machines372328 +Ref: f9372328 +Node: Packaging Others’ Projects As Eggs373914 +Ref: deprecated/easy_install packaging-others-projects-as-eggs374092 +Ref: fa374092 +Node: Creating your own Package Index375193 +Ref: deprecated/easy_install creating-your-own-package-index375327 +Ref: fb375327 +Node: Password-Protected Sites376573 +Ref: deprecated/easy_install password-protected-sites376721 +Ref: fd376721 +Node: Using pypirc Credentials377240 +Ref: deprecated/easy_install using-pypirc-credentials377362 +Ref: fe377362 +Node: Controlling Build Options378021 +Ref: deprecated/easy_install controlling-build-options378155 +Ref: ff378155 +Node: Editing and Viewing Source Packages379091 +Ref: deprecated/easy_install editing-and-viewing-source-packages379269 +Ref: ef379269 +Node: Dealing with Installation Conflicts381362 +Ref: deprecated/easy_install dealing-with-installation-conflicts381538 +Ref: 100381538 +Node: Compressed Installation383597 +Ref: deprecated/easy_install compressed-installation383729 +Ref: 101383729 +Node: Reference Manual386059 +Ref: deprecated/easy_install reference-manual386161 +Ref: 102386161 +Node: Configuration Files386329 +Ref: deprecated/easy_install configuration-files386434 +Ref: f0386434 +Ref: Configuration Files-Footnote-1388421 +Node: Command-Line Options388490 +Ref: deprecated/easy_install command-line-options388633 +Ref: ea388633 +Ref: Command-Line Options-Footnote-1404837 +Node: Custom Installation Locations404886 +Ref: deprecated/easy_install custom-installation-locations405033 +Ref: e8405033 +Ref: deprecated/easy_install non-root-installation405033 +Ref: 103405033 +Ref: Custom Installation Locations-Footnote-1406241 +Node: Use the “–user” option406575 +Ref: deprecated/easy_install pep-370406745 +Ref: 107406745 +Ref: deprecated/easy_install use-the-user-option406745 +Ref: 104406745 +Ref: Use the “–user” option-Footnote-1407332 +Node: Use the “–user” option and customize “PYTHONUSERBASE”407497 +Ref: deprecated/easy_install use-the-user-option-and-customize-pythonuserbase407696 +Ref: 105407696 +Node: Use “virtualenv”408168 +Ref: deprecated/easy_install use-virtualenv408330 +Ref: 106408330 +Ref: Use “virtualenv”-Footnote-1409040 +Node: Package Index “API”409085 +Ref: deprecated/easy_install package-index-api409203 +Ref: fc409203 +Ref: deprecated/easy_install virtualenv409203 +Ref: 108409203 +Node: Porting from Distutils412197 +Ref: deprecated/distutils-legacy doc412370 +Ref: 109412370 +Ref: deprecated/distutils-legacy porting-from-distutils412370 +Ref: 10a412370 +Ref: Porting from Distutils-Footnote-1412920 +Node: Prefer Setuptools412982 +Ref: deprecated/distutils-legacy prefer-setuptools413062 +Ref: 10b413062 +Ref: Prefer Setuptools-Footnote-1413971 +Node: “Eggsecutable” Scripts414022 +Ref: deprecated/functionalities doc414174 +Ref: 10c414174 +Ref: deprecated/functionalities eggsecutable-scripts414174 +Ref: 10d414174 +Node: History<2>415686 +Ref: history doc415819 +Ref: 10e415819 +Ref: history changes415819 +Ref: 10f415819 +Ref: history history415819 +Ref: 110415819 +Node: v50 3 2424446 +Ref: history v50-3-2424520 +Ref: 111424520 +Node: Documentation changes424603 +Ref: history documentation-changes424685 +Ref: 112424685 +Ref: Documentation changes-Footnote-1425167 +Ref: Documentation changes-Footnote-2425222 +Ref: Documentation changes-Footnote-3425267 +Ref: Documentation changes-Footnote-4425322 +Ref: Documentation changes-Footnote-5425367 +Ref: Documentation changes-Footnote-6425422 +Node: Misc425467 +Ref: history misc425549 +Ref: 113425549 +Ref: Misc-Footnote-1425878 +Ref: Misc-Footnote-2425933 +Ref: Misc-Footnote-3425978 +Ref: Misc-Footnote-4426033 +Ref: Misc-Footnote-5426088 +Node: v50 3 1426133 +Ref: history v50-3-1426223 +Ref: 114426223 +Node: Documentation changes<2>426339 +Ref: history id7426427 +Ref: 115426427 +Ref: Documentation changes<2>-Footnote-1426949 +Ref: Documentation changes<2>-Footnote-2427004 +Ref: Documentation changes<2>-Footnote-3427059 +Ref: Documentation changes<2>-Footnote-4427114 +Ref: Documentation changes<2>-Footnote-5427169 +Ref: Documentation changes<2>-Footnote-6427224 +Ref: Documentation changes<2>-Footnote-7427269 +Ref: Documentation changes<2>-Footnote-8427324 +Node: Misc<2>427369 +Ref: history id14427457 +Ref: 116427457 +Ref: Misc<2>-Footnote-1427666 +Ref: Misc<2>-Footnote-2427721 +Node: v50 3 0427776 +Ref: history v50-3-0427866 +Ref: 117427866 +Node: Changes427926 +Ref: history id17427981 +Ref: 118427981 +Ref: Changes-Footnote-1428157 +Ref: Changes-Footnote-2428212 +Node: v50 2 0428264 +Ref: history v50-2-0428354 +Ref: 119428354 +Node: Changes<2>428425 +Ref: history id19428483 +Ref: 11a428483 +Ref: Changes<2>-Footnote-1428942 +Ref: Changes<2>-Footnote-2428997 +Node: v50 1 0429052 +Ref: history v50-1-0429142 +Ref: 11b429142 +Node: Changes<3>429213 +Ref: history id22429271 +Ref: 11c429271 +Ref: Changes<3>-Footnote-1429782 +Node: v50 0 3429837 +Ref: history v50-0-3429927 +Ref: 11d429927 +Node: Misc<3>429992 +Ref: history id24430047 +Ref: 11e430047 +Ref: Misc<3>-Footnote-1430211 +Ref: Misc<3>-Footnote-2430266 +Node: v50 0 2430317 +Ref: history v50-0-2430407 +Ref: 11f430407 +Node: Misc<4>430472 +Ref: history id26430527 +Ref: 120430527 +Ref: Misc<4>-Footnote-1430690 +Ref: Misc<4>-Footnote-2430745 +Node: v50 0 1430787 +Ref: history v50-0-1430877 +Ref: 121430877 +Node: Misc<5>430942 +Ref: history id28430997 +Ref: 122430997 +Ref: Misc<5>-Footnote-1431441 +Ref: Misc<5>-Footnote-2431496 +Ref: Misc<5>-Footnote-3431551 +Node: v50 0 0431606 +Ref: history v50-0-0431696 +Ref: 123431696 +Node: Breaking Changes431788 +Ref: history breaking-changes431871 +Ref: 124431871 +Ref: Breaking Changes-Footnote-1432454 +Node: Changes<4>432509 +Ref: history id33432592 +Ref: 125432592 +Ref: Changes<4>-Footnote-1432719 +Node: v49 6 0432774 +Ref: history v49-6-0432864 +Ref: 126432864 +Node: Changes<5>432937 +Ref: history id35432995 +Ref: 127432995 +Ref: Changes<5>-Footnote-1433221 +Node: v49 5 0433276 +Ref: history v49-5-0433366 +Ref: 128433366 +Node: Changes<6>433439 +Ref: history id37433497 +Ref: 129433497 +Ref: Changes<6>-Footnote-1433762 +Ref: Changes<6>-Footnote-2433817 +Node: v49 4 0433867 +Ref: history v49-4-0433957 +Ref: 12a433957 +Node: Changes<7>434030 +Ref: history id39434088 +Ref: 12b434088 +Ref: Changes<7>-Footnote-1434215 +Node: v49 3 2434270 +Ref: history v49-3-2434360 +Ref: 12c434360 +Node: Documentation changes<3>434478 +Ref: history id41434566 +Ref: 12d434566 +Ref: Documentation changes<3>-Footnote-1434731 +Node: Misc<6>434786 +Ref: history id43434874 +Ref: 12e434874 +Ref: Misc<6>-Footnote-1435027 +Node: v49 3 1435082 +Ref: history v49-3-1435172 +Ref: 12f435172 +Node: Changes<8>435245 +Ref: history id45435303 +Ref: 130435303 +Ref: Changes<8>-Footnote-1435513 +Node: v49 3 0435568 +Ref: history v49-3-0435658 +Ref: 131435658 +Node: Changes<9>435731 +Ref: history id47435789 +Ref: 132435789 +Ref: Changes<9>-Footnote-1436219 +Node: v49 2 1436274 +Ref: history v49-2-1436364 +Ref: 133436364 +Node: Misc<7>436431 +Ref: history id49436486 +Ref: 134436486 +Ref: Misc<7>-Footnote-1436631 +Node: v49 2 0436686 +Ref: history v49-2-0436776 +Ref: 135436776 +Node: Changes<10>436850 +Ref: history id51436909 +Ref: 136436909 +Ref: Changes<10>-Footnote-1437175 +Node: v49 1 3437230 +Ref: history v49-1-3437320 +Ref: 137437320 +Node: Misc<8>437387 +Ref: history id53437442 +Ref: 138437442 +Ref: Misc<8>-Footnote-1437666 +Ref: Misc<8>-Footnote-2437721 +Node: v49 1 2437776 +Ref: history v49-1-2437866 +Ref: 139437866 +Node: Changes<11>437940 +Ref: history id56437999 +Ref: 13a437999 +Ref: Changes<11>-Footnote-1438450 +Node: v49 1 1438505 +Ref: history v49-1-1438595 +Ref: 13b438595 +Node: Misc<9>438662 +Ref: history id58438717 +Ref: 13c438717 +Ref: Misc<9>-Footnote-1438868 +Node: v49 0 1438923 +Ref: history v49-0-1439013 +Ref: 13d439013 +Node: Misc<10>439081 +Ref: history id60439137 +Ref: 13e439137 +Ref: Misc<10>-Footnote-1439369 +Ref: Misc<10>-Footnote-2439424 +Node: v49 1 0439475 +Ref: history v49-1-0439565 +Ref: 13f439565 +Node: Changes<12>439639 +Ref: history id62439698 +Ref: 140439698 +Ref: Changes<12>-Footnote-1439859 +Node: v49 0 0439914 +Ref: history v49-0-0440004 +Ref: 141440004 +Node: Breaking Changes<2>440137 +Ref: history id64440224 +Ref: 142440224 +Ref: Breaking Changes<2>-Footnote-1440630 +Ref: Breaking Changes<2>-Footnote-2440685 +Node: Changes<13>440740 +Ref: history id67440844 +Ref: 143440844 +Ref: Changes<13>-Footnote-1441209 +Ref: Changes<13>-Footnote-2441264 +Node: Misc<11>441319 +Ref: history id70441395 +Ref: 144441395 +Ref: Misc<11>-Footnote-1441574 +Node: v48 0 0441629 +Ref: history v48-0-0441719 +Ref: 145441719 +Node: Breaking Changes<3>441810 +Ref: history id72441877 +Ref: 146441877 +Ref: Breaking Changes<3>-Footnote-1442993 +Node: v47 3 2443048 +Ref: history v47-3-2443138 +Ref: 147443138 +Node: Misc<12>443206 +Ref: history id74443262 +Ref: 148443262 +Ref: Misc<12>-Footnote-1443423 +Node: v47 3 1443478 +Ref: history v47-3-1443568 +Ref: 149443568 +Node: Misc<13>443636 +Ref: history id76443692 +Ref: 14a443692 +Ref: Misc<13>-Footnote-1443971 +Ref: Misc<13>-Footnote-2444026 +Node: v47 3 0444081 +Ref: history v47-3-0444171 +Ref: 14b444171 +Node: Changes<14>444263 +Ref: history id79444339 +Ref: 14c444339 +Ref: Changes<14>-Footnote-1444591 +Node: Misc<14>444646 +Ref: history id81444722 +Ref: 14d444722 +Ref: Misc<14>-Footnote-1444879 +Node: v47 2 0444934 +Ref: history v47-2-0445024 +Ref: 14e445024 +Node: Changes<15>445098 +Ref: history id83445157 +Ref: 14f445157 +Ref: Changes<15>-Footnote-1445332 +Node: v47 1 1445387 +Ref: history v47-1-1445477 +Ref: 150445477 +Node: Documentation changes<4>445649 +Ref: history id85445762 +Ref: 151445762 +Ref: Documentation changes<4>-Footnote-1445919 +Node: Incorporate changes from v44 1 1445974 +Ref: history incorporate-changes-from-v44-1-1446087 +Ref: 152446087 +Ref: Incorporate changes from v44 1 1-Footnote-1446372 +Node: v44 1 1446427 +Ref: history v44-1-1446517 +Ref: 153446517 +Node: Misc<15>446585 +Ref: history id88446641 +Ref: 154446641 +Ref: Misc<15>-Footnote-1446868 +Node: v47 1 0446923 +Ref: history v47-1-0447013 +Ref: 155447013 +Node: Changes<16>447087 +Ref: history id90447146 +Ref: 156447146 +Ref: Changes<16>-Footnote-1447366 +Node: v47 0 0447421 +Ref: history v47-0-0447511 +Ref: 157447511 +Node: Breaking Changes<4>447626 +Ref: history id92447713 +Ref: 158447713 +Ref: Breaking Changes<4>-Footnote-1447957 +Node: Changes<17>448012 +Ref: history id94448099 +Ref: 159448099 +Ref: Changes<17>-Footnote-1448257 +Node: v46 4 0448312 +Ref: history v46-4-0448402 +Ref: 15a448402 +Node: Changes<18>448476 +Ref: history id96448535 +Ref: 15b448535 +Ref: Changes<18>-Footnote-1448913 +Node: v46 3 1448968 +Ref: history v46-3-1449058 +Ref: 15c449058 +Node: v46 3 0449123 +Ref: history v46-3-0449213 +Ref: 15d449213 +Node: Changes<19>449305 +Ref: history id98449381 +Ref: 15e449381 +Ref: Changes<19>-Footnote-1449639 +Ref: Changes<19>-Footnote-2449694 +Node: Misc<16>449748 +Ref: history id101449824 +Ref: 15f449824 +Ref: Misc<16>-Footnote-1450104 +Ref: Misc<16>-Footnote-2450159 +Node: v46 2 0450214 +Ref: history v46-2-0450304 +Ref: 160450304 +Node: Changes<20>450447 +Ref: history id104450539 +Ref: 161450539 +Ref: Changes<20>-Footnote-1451073 +Ref: Changes<20>-Footnote-2451128 +Ref: Changes<20>-Footnote-3451183 +Ref: Changes<20>-Footnote-4451238 +Node: Documentation changes<5>451293 +Ref: history id109451402 +Ref: 162451402 +Ref: Documentation changes<5>-Footnote-1451592 +Node: Misc<17>451647 +Ref: history id111451736 +Ref: 163451736 +Ref: Misc<17>-Footnote-1451969 +Ref: Misc<17>-Footnote-2452024 +Node: v46 1 3452067 +Ref: history v46-1-3452157 +Ref: 164452157 +Node: v46 1 2452222 +Ref: history v46-1-2452312 +Ref: 165452312 +Node: Misc<18>452380 +Ref: history id113452436 +Ref: 166452436 +Ref: Misc<18>-Footnote-1452570 +Node: v46 1 1452625 +Ref: history v46-1-1452715 +Ref: 167452715 +Node: v46 1 0452780 +Ref: history v46-1-0452870 +Ref: 168452870 +Node: Changes<21>453015 +Ref: history id115453115 +Ref: 169453115 +Ref: Changes<21>-Footnote-1453640 +Ref: Changes<21>-Footnote-2453694 +Ref: Changes<21>-Footnote-3453749 +Ref: Changes<21>-Footnote-4453804 +Ref: Changes<21>-Footnote-5453859 +Node: Incorporate changes from v44 1 0453909 +Ref: history incorporate-changes-from-v44-1-0454009 +Ref: 16a454009 +Ref: Incorporate changes from v44 1 0-Footnote-1454457 +Ref: Incorporate changes from v44 1 0-Footnote-2454512 +Ref: Incorporate changes from v44 1 0-Footnote-3454567 +Node: v44 1 0454622 +Ref: history v44-1-0454712 +Ref: 16b454712 +Node: Changes<22>454786 +Ref: history id123454845 +Ref: 16c454845 +Ref: Changes<22>-Footnote-1455241 +Ref: Changes<22>-Footnote-2455296 +Ref: Changes<22>-Footnote-3455351 +Node: v46 0 0455406 +Ref: history v46-0-0455496 +Ref: 16d455496 +Node: Breaking Changes<5>455680 +Ref: history id127455767 +Ref: 16e455767 +Ref: Breaking Changes<5>-Footnote-1455918 +Node: Changes<23>455971 +Ref: history id129456091 +Ref: 16f456091 +Ref: Changes<23>-Footnote-1456415 +Ref: Changes<23>-Footnote-2456470 +Node: Documentation changes<6>456525 +Ref: history id132456634 +Ref: 170456634 +Ref: Documentation changes<6>-Footnote-1456795 +Node: Misc<19>456850 +Ref: history id134456939 +Ref: 171456939 +Ref: Misc<19>-Footnote-1457097 +Node: v45 3 0457152 +Ref: history v45-3-0457242 +Ref: 172457242 +Node: Changes<24>457316 +Ref: history id136457375 +Ref: 173457375 +Ref: Changes<24>-Footnote-1457592 +Ref: Changes<24>-Footnote-2457647 +Node: v45 2 0457702 +Ref: history v45-2-0457792 +Ref: 174457792 +Node: Changes<25>457884 +Ref: history id139457960 +Ref: 175457960 +Ref: Changes<25>-Footnote-1458711 +Ref: Changes<25>-Footnote-2458766 +Ref: Changes<25>-Footnote-3458821 +Ref: Changes<25>-Footnote-4458871 +Ref: Changes<25>-Footnote-5458926 +Node: Misc<20>458981 +Ref: history id144459057 +Ref: 176459057 +Ref: Misc<20>-Footnote-1459211 +Node: v45 1 0459266 +Ref: history v45-1-0459356 +Ref: 177459356 +Node: Changes<26>459430 +Ref: history id146459489 +Ref: 178459489 +Ref: Changes<26>-Footnote-1459851 +Ref: Changes<26>-Footnote-2459906 +Ref: Changes<26>-Footnote-3459961 +Node: v45 0 0460016 +Ref: history v45-0-0460106 +Ref: 179460106 +Node: Breaking Changes<6>460221 +Ref: history id150460308 +Ref: 17a460308 +Ref: Breaking Changes<6>-Footnote-1460576 +Node: Changes<27>460631 +Ref: history id152460718 +Ref: 17b460718 +Ref: Changes<27>-Footnote-1460855 +Node: v44 0 0460910 +Ref: history v44-0-0461000 +Ref: 17c461000 +Node: Breaking Changes<7>461091 +Ref: history id154461158 +Ref: 17d461158 +Ref: Breaking Changes<7>-Footnote-1461288 +Node: v43 0 0461343 +Ref: history v43-0-0461433 +Ref: 17e461433 +Node: Breaking Changes<8>461548 +Ref: history id156461635 +Ref: 17f461635 +Ref: Breaking Changes<8>-Footnote-1462014 +Node: Changes<28>462069 +Ref: history id158462156 +Ref: 180462156 +Ref: Changes<28>-Footnote-1462537 +Ref: Changes<28>-Footnote-2462592 +Node: v42 0 2462642 +Ref: history v42-0-2462732 +Ref: 181462732 +Node: Changes<29>462806 +Ref: history id161462865 +Ref: 182462865 +Ref: Changes<29>-Footnote-1463162 +Ref: Changes<29>-Footnote-2463217 +Node: v42 0 1463272 +Ref: history v42-0-1463362 +Ref: 183463362 +Node: Changes<30>463436 +Ref: history id164463495 +Ref: 184463495 +Ref: Changes<30>-Footnote-1463632 +Node: v42 0 0463687 +Ref: history v42-0-0463777 +Ref: 185463777 +Node: Breaking Changes<9>463892 +Ref: history id166463979 +Ref: 186463979 +Ref: Breaking Changes<9>-Footnote-1464927 +Ref: Breaking Changes<9>-Footnote-2464982 +Ref: Breaking Changes<9>-Footnote-3465037 +Ref: Breaking Changes<9>-Footnote-4465076 +Ref: Breaking Changes<9>-Footnote-5465126 +Ref: Breaking Changes<9>-Footnote-6465176 +Ref: Breaking Changes<9>-Footnote-7465231 +Node: Changes<31>465264 +Ref: history id171465351 +Ref: 187465351 +Ref: Changes<31>-Footnote-1466048 +Ref: Changes<31>-Footnote-2466103 +Ref: Changes<31>-Footnote-3466158 +Ref: Changes<31>-Footnote-4466213 +Ref: Changes<31>-Footnote-5466268 +Node: v41 6 0466316 +Ref: history v41-6-0466406 +Ref: 188466406 +Node: Changes<32>466480 +Ref: history id176466539 +Ref: 189466539 +Ref: Changes<32>-Footnote-1466726 +Node: v41 5 1466780 +Ref: history v41-5-1466870 +Ref: 18a466870 +Node: Changes<33>466944 +Ref: history id178467003 +Ref: 18b467003 +Ref: Changes<33>-Footnote-1467167 +Node: v41 5 0467222 +Ref: history v41-5-0467312 +Ref: 18c467312 +Node: Changes<34>467455 +Ref: history id180467547 +Ref: 18d467547 +Ref: Changes<34>-Footnote-1468021 +Ref: Changes<34>-Footnote-2468076 +Ref: Changes<34>-Footnote-3468131 +Ref: Changes<34>-Footnote-4468181 +Ref: Changes<34>-Footnote-5468236 +Node: Documentation changes<7>468291 +Ref: history id185468400 +Ref: 18e468400 +Ref: Documentation changes<7>-Footnote-1468980 +Ref: Documentation changes<7>-Footnote-2469035 +Ref: Documentation changes<7>-Footnote-3469090 +Ref: Documentation changes<7>-Footnote-4469145 +Node: Misc<21>469200 +Ref: history id190469289 +Ref: 18f469289 +Ref: Misc<21>-Footnote-1469418 +Node: v41 4 0469473 +Ref: history v41-4-0469563 +Ref: 190469563 +Node: Changes<35>469637 +Ref: history id192469696 +Ref: 191469696 +Ref: Changes<35>-Footnote-1469880 +Node: v41 3 0469935 +Ref: history v41-3-0470025 +Ref: 192470025 +Node: Changes<36>470117 +Ref: history id194470193 +Ref: 193470193 +Ref: Changes<36>-Footnote-1470479 +Node: Misc<22>470534 +Ref: history id196470610 +Ref: 194470610 +Ref: Misc<22>-Footnote-1470786 +Node: v41 2 0470841 +Ref: history v41-2-0470931 +Ref: 195470931 +Node: Changes<37>471023 +Ref: history id198471099 +Ref: 196471099 +Ref: Changes<37>-Footnote-1471235 +Node: Misc<23>471289 +Ref: history id200471365 +Ref: 197471365 +Ref: Misc<23>-Footnote-1471567 +Node: v41 1 0471622 +Ref: history v41-1-0471712 +Ref: 198471712 +Node: Misc<24>471831 +Ref: history id202471920 +Ref: 199471920 +Ref: Misc<24>-Footnote-1472922 +Ref: Misc<24>-Footnote-2472977 +Ref: Misc<24>-Footnote-3473032 +Ref: Misc<24>-Footnote-4473082 +Ref: Misc<24>-Footnote-5473137 +Ref: Misc<24>-Footnote-6473187 +Ref: Misc<24>-Footnote-7473242 +Ref: Misc<24>-Footnote-8473297 +Ref: Misc<24>-Footnote-9473352 +Node: Documentation changes<8>473407 +Ref: history id212473496 +Ref: 19a473496 +Ref: Documentation changes<8>-Footnote-1473662 +Node: v41 0 1473717 +Ref: history v41-0-1473807 +Ref: 19b473807 +Node: Changes<38>473881 +Ref: history id214473940 +Ref: 19c473940 +Ref: Changes<38>-Footnote-1474411 +Ref: Changes<38>-Footnote-2474466 +Ref: Changes<38>-Footnote-3474516 +Ref: Changes<38>-Footnote-4474571 +Node: v41 0 0474626 +Ref: history v41-0-0474716 +Ref: 19d474716 +Node: Breaking Changes<10>474808 +Ref: history id219474876 +Ref: 19e474876 +Ref: Breaking Changes<10>-Footnote-1475468 +Node: v40 9 0475523 +Ref: history v40-9-0475613 +Ref: 19f475613 +Node: Changes<39>475738 +Ref: history id221475830 +Ref: 1a0475830 +Ref: Changes<39>-Footnote-1476552 +Ref: Changes<39>-Footnote-2476607 +Ref: Changes<39>-Footnote-3476657 +Ref: Changes<39>-Footnote-4476712 +Node: Documentation changes<9>476767 +Ref: history id226476859 +Ref: 1a1476859 +Ref: Documentation changes<9>-Footnote-1477057 +Node: v40 8 0477112 +Ref: history v40-8-0477202 +Ref: 1a2477202 +Node: Changes<40>477276 +Ref: history id228477335 +Ref: 1a3477335 +Ref: Changes<40>-Footnote-1478222 +Ref: Changes<40>-Footnote-2478277 +Ref: Changes<40>-Footnote-3478327 +Ref: Changes<40>-Footnote-4478382 +Node: v40 7 3478437 +Ref: history v40-7-3478527 +Ref: 1a4478527 +Node: Changes<41>478601 +Ref: history id233478660 +Ref: 1a5478660 +Ref: Changes<41>-Footnote-1478998 +Ref: Changes<41>-Footnote-2479053 +Ref: Changes<41>-Footnote-3479108 +Ref: Changes<41>-Footnote-4479163 +Ref: Changes<41>-Footnote-5479218 +Node: v40 7 2479273 +Ref: history v40-7-2479363 +Ref: 1a6479363 +Node: Changes<42>479437 +Ref: history id239479496 +Ref: 1a7479496 +Ref: Changes<42>-Footnote-1479626 +Node: v40 7 1479681 +Ref: history v40-7-1479771 +Ref: 1a8479771 +Node: Changes<43>479845 +Ref: history id241479904 +Ref: 1a9479904 +Ref: Changes<43>-Footnote-1480103 +Node: v40 7 0480158 +Ref: history v40-7-0480248 +Ref: 1aa480248 +Node: Breaking Changes<11>480364 +Ref: history id243480452 +Ref: 1ab480452 +Ref: Breaking Changes<11>-Footnote-1480654 +Node: Changes<44>480709 +Ref: history id245480797 +Ref: 1ac480797 +Ref: Changes<44>-Footnote-1481314 +Ref: Changes<44>-Footnote-2481369 +Ref: Changes<44>-Footnote-3481424 +Ref: Changes<44>-Footnote-4481479 +Ref: Changes<44>-Footnote-5481534 +Ref: Changes<44>-Footnote-6481576 +Ref: Changes<44>-Footnote-7481631 +Ref: Changes<44>-Footnote-8481686 +Node: v40 6 3481736 +Ref: history v40-6-3481826 +Ref: 1ad481826 +Node: Changes<45>481900 +Ref: history id253481959 +Ref: 1ae481959 +Ref: Changes<45>-Footnote-1482134 +Ref: Changes<45>-Footnote-2482189 +Node: v40 6 2482239 +Ref: history v40-6-2482329 +Ref: 1af482329 +Node: Changes<46>482403 +Ref: history id256482462 +Ref: 1b0482462 +Ref: Changes<46>-Footnote-1482627 +Node: v40 6 1482682 +Ref: history v40-6-1482772 +Ref: 1b1482772 +Node: Changes<47>482846 +Ref: history id258482905 +Ref: 1b2482905 +Ref: Changes<47>-Footnote-1483113 +Node: v40 6 0483168 +Ref: history v40-6-0483258 +Ref: 1b3483258 +Node: Deprecations483419 +Ref: history deprecations483499 +Ref: 1b4483499 +Ref: Deprecations-Footnote-1483666 +Node: Changes<48>483721 +Ref: history id261483835 +Ref: 1b5483835 +Ref: Changes<48>-Footnote-1484727 +Ref: Changes<48>-Footnote-2484782 +Ref: Changes<48>-Footnote-3484837 +Ref: Changes<48>-Footnote-4484892 +Node: Documentation changes<10>484947 +Ref: history id266485057 +Ref: 1b6485057 +Ref: Documentation changes<10>-Footnote-1485903 +Ref: Documentation changes<10>-Footnote-2485958 +Ref: Documentation changes<10>-Footnote-3486013 +Ref: Documentation changes<10>-Footnote-4486068 +Ref: Documentation changes<10>-Footnote-5486123 +Ref: Documentation changes<10>-Footnote-6486178 +Ref: Documentation changes<10>-Footnote-7486233 +Ref: Documentation changes<10>-Footnote-8486288 +Node: Misc<25>486343 +Ref: history id275486433 +Ref: 1b7486433 +Ref: Misc<25>-Footnote-1486731 +Ref: Misc<25>-Footnote-2486786 +Node: v40 5 0486841 +Ref: history v40-5-0486931 +Ref: 1b8486931 +Node: Changes<49>487057 +Ref: history id278487150 +Ref: 1b9487150 +Ref: Changes<49>-Footnote-1487566 +Ref: Changes<49>-Footnote-2487621 +Ref: Changes<49>-Footnote-3487676 +Ref: Changes<49>-Footnote-4487731 +Node: Documentation changes<11>487786 +Ref: history id283487879 +Ref: 1ba487879 +Ref: Documentation changes<11>-Footnote-1488059 +Node: v40 4 3488114 +Ref: history v40-4-3488204 +Ref: 1bb488204 +Node: Changes<50>488278 +Ref: history id285488337 +Ref: 1bc488337 +Ref: Changes<50>-Footnote-1488471 +Node: v40 4 2488526 +Ref: history v40-4-2488616 +Ref: 1bd488616 +Node: Misc<26>488684 +Ref: history id287488740 +Ref: 1be488740 +Ref: Misc<26>-Footnote-1488844 +Node: v40 4 1488899 +Ref: history v40-4-1488989 +Ref: 1bf488989 +Node: Changes<51>489063 +Ref: history id289489122 +Ref: 1c0489122 +Ref: Changes<51>-Footnote-1489239 +Node: v40 4 0489294 +Ref: history v40-4-0489384 +Ref: 1c1489384 +Node: Changes<52>489458 +Ref: history id291489517 +Ref: 1c2489517 +Ref: Changes<52>-Footnote-1489908 +Node: v40 3 0489963 +Ref: history v40-3-0490053 +Ref: 1c3490053 +Node: Changes<53>490145 +Ref: history id293490221 +Ref: 1c4490221 +Ref: Changes<53>-Footnote-1490721 +Ref: Changes<53>-Footnote-2490776 +Ref: Changes<53>-Footnote-3490831 +Ref: Changes<53>-Footnote-4490886 +Node: Misc<27>490941 +Ref: history id298491017 +Ref: 1c5491017 +Ref: Misc<27>-Footnote-1491134 +Node: v40 2 0491189 +Ref: history v40-2-0491279 +Ref: 1c6491279 +Node: Changes<54>491353 +Ref: history id300491412 +Ref: 1c7491412 +Ref: Changes<54>-Footnote-1491551 +Ref: Changes<54>-Footnote-2491606 +Node: v40 1 1491656 +Ref: history v40-1-1491746 +Ref: 1c8491746 +Node: Changes<55>491820 +Ref: history id303491879 +Ref: 1c9491879 +Ref: Changes<55>-Footnote-1492032 +Node: v40 1 0492087 +Ref: history v40-1-0492177 +Ref: 1ca492177 +Node: Changes<56>492269 +Ref: history id305492345 +Ref: 1cb492345 +Ref: Changes<56>-Footnote-1493127 +Ref: Changes<56>-Footnote-2493182 +Ref: Changes<56>-Footnote-3493237 +Ref: Changes<56>-Footnote-4493287 +Ref: Changes<56>-Footnote-5493342 +Ref: Changes<56>-Footnote-6493397 +Ref: Changes<56>-Footnote-7493452 +Ref: Changes<56>-Footnote-8493507 +Ref: Changes<56>-Footnote-9493562 +Ref: Changes<56>-Footnote-10493617 +Node: Misc<28>493673 +Ref: history id315493749 +Ref: 1cc493749 +Ref: Misc<28>-Footnote-1493906 +Node: v40 0 0493961 +Ref: history v40-0-0494051 +Ref: 1cd494051 +Node: Breaking Changes<12>494237 +Ref: history id317494325 +Ref: 1ce494325 +Ref: Breaking Changes<12>-Footnote-1494455 +Node: Changes<57>494510 +Ref: history id319494632 +Ref: 1cf494632 +Ref: Changes<57>-Footnote-1494884 +Ref: Changes<57>-Footnote-2494939 +Node: Documentation changes<12>494994 +Ref: history id322495104 +Ref: 1d0495104 +Ref: Documentation changes<12>-Footnote-1495382 +Ref: Documentation changes<12>-Footnote-2495437 +Ref: Documentation changes<12>-Footnote-3495492 +Node: Misc<29>495547 +Ref: history id326495637 +Ref: 1d1495637 +Ref: Misc<29>-Footnote-1495816 +Ref: Misc<29>-Footnote-2495871 +Node: v39 2 0495921 +Ref: history v39-2-0496011 +Ref: 1d2496011 +Node: Changes<58>496155 +Ref: history id329496248 +Ref: 1d3496248 +Ref: Changes<58>-Footnote-1496841 +Ref: Changes<58>-Footnote-2496896 +Ref: Changes<58>-Footnote-3496946 +Ref: Changes<58>-Footnote-4497001 +Ref: Changes<58>-Footnote-5497056 +Node: Documentation changes<13>497111 +Ref: history id334497221 +Ref: 1d4497221 +Ref: Documentation changes<13>-Footnote-1497608 +Ref: Documentation changes<13>-Footnote-2497663 +Ref: Documentation changes<13>-Footnote-3497718 +Ref: Documentation changes<13>-Footnote-4497773 +Node: Misc<30>497828 +Ref: history id339497918 +Ref: 1d5497918 +Ref: Misc<30>-Footnote-1498694 +Ref: Misc<30>-Footnote-2498749 +Ref: Misc<30>-Footnote-3498804 +Ref: Misc<30>-Footnote-4498859 +Ref: Misc<30>-Footnote-5498914 +Ref: Misc<30>-Footnote-6498969 +Ref: Misc<30>-Footnote-7499024 +Ref: Misc<30>-Footnote-8499074 +Node: v39 1 0499129 +Ref: history v39-1-0499219 +Ref: 1d6499219 +Ref: v39 1 0-Footnote-1499587 +Ref: v39 1 0-Footnote-2499642 +Ref: v39 1 0-Footnote-3499697 +Node: v39 0 1499752 +Ref: history v39-0-1499842 +Ref: 1d7499842 +Ref: v39 0 1-Footnote-1499999 +Node: v39 0 0500054 +Ref: history v39-0-0500144 +Ref: 1d8500144 +Ref: v39 0 0-Footnote-1500728 +Ref: v39 0 0-Footnote-2500783 +Node: v38 7 0500837 +Ref: history v38-7-0500927 +Ref: 1d9500927 +Ref: v38 7 0-Footnote-1501059 +Node: v38 6 1501114 +Ref: history v38-6-1501204 +Ref: 1da501204 +Ref: v38 6 1-Footnote-1501407 +Node: v38 6 0501462 +Ref: history v38-6-0501552 +Ref: 1db501552 +Ref: v38 6 0-Footnote-1501687 +Ref: v38 6 0-Footnote-2501742 +Node: v38 5 2501792 +Ref: history v38-5-2501882 +Ref: 1dc501882 +Ref: v38 5 2-Footnote-1502076 +Ref: v38 5 2-Footnote-2502131 +Node: v38 5 1502181 +Ref: history v38-5-1502271 +Ref: 1dd502271 +Ref: v38 5 1-Footnote-1502436 +Node: v38 5 0502491 +Ref: history v38-5-0502581 +Ref: 1de502581 +Ref: v38 5 0-Footnote-1502847 +Ref: v38 5 0-Footnote-2502902 +Node: v38 4 1502957 +Ref: history v38-4-1503047 +Ref: 1df503047 +Ref: v38 4 1-Footnote-1503195 +Node: v38 4 0503250 +Ref: history v38-4-0503340 +Ref: 1e0503340 +Ref: v38 4 0-Footnote-1503489 +Node: v38 3 0503544 +Ref: history v38-3-0503634 +Ref: 1e1503634 +Ref: v38 3 0-Footnote-1503900 +Ref: v38 3 0-Footnote-2503955 +Ref: v38 3 0-Footnote-3504005 +Node: v38 2 5504060 +Ref: history v38-2-5504150 +Ref: 1e2504150 +Ref: v38 2 5-Footnote-1504298 +Node: v38 2 4504353 +Ref: history v38-2-4504443 +Ref: 1e3504443 +Ref: v38 2 4-Footnote-1504593 +Node: v38 2 3504648 +Ref: history v38-2-3504738 +Ref: 1e4504738 +Node: v38 2 2504814 +Ref: history v38-2-2504904 +Ref: 1e5504904 +Ref: v38 2 2-Footnote-1505066 +Node: v38 2 1505121 +Ref: history v38-2-1505211 +Ref: 1e6505211 +Ref: v38 2 1-Footnote-1505372 +Node: v38 2 0505427 +Ref: history v38-2-0505517 +Ref: 1e7505517 +Ref: v38 2 0-Footnote-1505715 +Node: v38 1 0505770 +Ref: history v38-1-0505860 +Ref: 1e8505860 +Ref: v38 1 0-Footnote-1506034 +Node: v38 0 0506089 +Ref: history v38-0-0506179 +Ref: 1e9506179 +Ref: v38 0 0-Footnote-1506435 +Node: v37 0 0506489 +Ref: history v37-0-0506579 +Ref: 1ea506579 +Ref: v37 0 0-Footnote-1506765 +Node: v36 8 0506819 +Ref: history v36-8-0506909 +Ref: 1eb506909 +Ref: v36 8 0-Footnote-1507078 +Node: v36 7 3507133 +Ref: history v36-7-3507223 +Ref: 1ec507223 +Ref: v36 7 3-Footnote-1507355 +Node: v36 7 2507410 +Ref: history v36-7-2507500 +Ref: 1ed507500 +Ref: v36 7 2-Footnote-1507637 +Node: v36 7 1507691 +Ref: history v36-7-1507781 +Ref: 1ee507781 +Ref: v36 7 1-Footnote-1507950 +Node: v36 7 0508005 +Ref: history v36-7-0508095 +Ref: 1ef508095 +Ref: v36 7 0-Footnote-1508244 +Node: v36 6 1508299 +Ref: history v36-6-1508389 +Ref: 1f0508389 +Ref: v36 6 1-Footnote-1508667 +Ref: v36 6 1-Footnote-2508722 +Node: v36 6 0508776 +Ref: history v36-6-0508866 +Ref: 1f1508866 +Ref: v36 6 0-Footnote-1509157 +Ref: v36 6 0-Footnote-2509212 +Ref: v36 6 0-Footnote-3509262 +Node: v36 5 0509317 +Ref: history v36-5-0509407 +Ref: 1f2509407 +Ref: v36 5 0-Footnote-1509775 +Ref: v36 5 0-Footnote-2509829 +Node: v36 4 0509884 +Ref: history v36-4-0509974 +Ref: 1f3509974 +Ref: v36 4 0-Footnote-1510914 +Ref: v36 4 0-Footnote-2510969 +Ref: v36 4 0-Footnote-3511048 +Ref: v36 4 0-Footnote-4511103 +Ref: v36 4 0-Footnote-5511157 +Ref: v36 4 0-Footnote-6511212 +Ref: v36 4 0-Footnote-7511267 +Ref: v36 4 0-Footnote-8511322 +Node: v36 3 0511377 +Ref: history v36-3-0511467 +Ref: 1f4511467 +Ref: v36 3 0-Footnote-1511678 +Node: v36 2 7511733 +Ref: history v36-2-7511823 +Ref: 1f5511823 +Ref: v36 2 7-Footnote-1512047 +Ref: v36 2 7-Footnote-2512102 +Node: v36 2 6512157 +Ref: history v36-2-6512247 +Ref: 1f6512247 +Ref: v36 2 6-Footnote-1512417 +Node: v36 2 5512471 +Ref: history v36-2-5512561 +Ref: 1f7512561 +Ref: v36 2 5-Footnote-1512795 +Ref: v36 2 5-Footnote-2512850 +Ref: v36 2 5-Footnote-3512905 +Ref: v36 2 5-Footnote-4512960 +Node: v36 2 4513015 +Ref: history v36-2-4513105 +Ref: 1f8513105 +Ref: v36 2 4-Footnote-1513301 +Node: v36 2 3513356 +Ref: history v36-2-3513446 +Ref: 1f9513446 +Ref: v36 2 3-Footnote-1513575 +Node: v36 2 2513630 +Ref: history v36-2-2513720 +Ref: 1fa513720 +Ref: v36 2 2-Footnote-1513917 +Node: v36 2 1513972 +Ref: history v36-2-1514062 +Ref: 1fb514062 +Ref: v36 2 1-Footnote-1514243 +Ref: v36 2 1-Footnote-2514298 +Node: v36 2 0514353 +Ref: history v36-2-0514443 +Ref: 1fc514443 +Ref: v36 2 0-Footnote-1514962 +Ref: v36 2 0-Footnote-2515017 +Node: v36 1 1515072 +Ref: history v36-1-1515162 +Ref: 1fd515162 +Ref: v36 1 1-Footnote-1515411 +Ref: v36 1 1-Footnote-2515466 +Node: v36 1 0515521 +Ref: history v36-1-0515611 +Ref: 1fe515611 +Ref: v36 1 0-Footnote-1516114 +Ref: v36 1 0-Footnote-2516169 +Ref: v36 1 0-Footnote-3516206 +Node: v36 0 1516318 +Ref: history v36-0-1516408 +Ref: 1ff516408 +Ref: v36 0 1-Footnote-1516645 +Node: v36 0 0516700 +Ref: history v36-0-0516790 +Ref: 200516790 +Ref: v36 0 0-Footnote-1517225 +Node: v35 0 2517279 +Ref: history v35-0-2517369 +Ref: 201517369 +Ref: v35 0 2-Footnote-1517565 +Ref: v35 0 2-Footnote-2517620 +Ref: v35 0 2-Footnote-3517675 +Node: v35 0 1517716 +Ref: history v35-0-1517806 +Ref: 202517806 +Ref: v35 0 1-Footnote-1518149 +Ref: v35 0 1-Footnote-2518203 +Ref: v35 0 1-Footnote-3518258 +Ref: v35 0 1-Footnote-4518313 +Node: v35 0 0518367 +Ref: history v35-0-0518457 +Ref: 203518457 +Ref: v35 0 0-Footnote-1519057 +Node: v34 4 1519111 +Ref: history v34-4-1519201 +Ref: 204519201 +Ref: v34 4 1-Footnote-1519633 +Ref: v34 4 1-Footnote-2519688 +Ref: v34 4 1-Footnote-3519743 +Node: v34 4 0519797 +Ref: history v34-4-0519887 +Ref: 205519887 +Ref: v34 4 0-Footnote-1520276 +Ref: v34 4 0-Footnote-2520330 +Ref: v34 4 0-Footnote-3520384 +Node: v34 3 3520439 +Ref: history v34-3-3520529 +Ref: 206520529 +Ref: v34 3 3-Footnote-1520788 +Ref: v34 3 3-Footnote-2520842 +Node: v34 3 2520896 +Ref: history v34-3-2520986 +Ref: 207520986 +Ref: v34 3 2-Footnote-1521182 +Node: v34 3 1521236 +Ref: history v34-3-1521326 +Ref: 208521326 +Ref: v34 3 1-Footnote-1521585 +Ref: v34 3 1-Footnote-2521639 +Node: v34 3 0521693 +Ref: history v34-3-0521783 +Ref: 209521783 +Ref: v34 3 0-Footnote-1522077 +Ref: v34 3 0-Footnote-2522131 +Node: v34 2 0522185 +Ref: history v34-2-0522275 +Ref: 20a522275 +Ref: v34 2 0-Footnote-1522621 +Ref: v34 2 0-Footnote-2522675 +Ref: v34 2 0-Footnote-3522729 +Node: v34 1 1522779 +Ref: history v34-1-1522869 +Ref: 20b522869 +Ref: v34 1 1-Footnote-1523045 +Ref: v34 1 1-Footnote-2523099 +Node: v34 1 0523153 +Ref: history v34-1-0523243 +Ref: 20c523243 +Ref: v34 1 0-Footnote-1523444 +Node: v34 0 3523498 +Ref: history v34-0-3523588 +Ref: 20d523588 +Ref: v34 0 3-Footnote-1523816 +Node: v34 0 2523870 +Ref: history v34-0-2523960 +Ref: 20e523960 +Ref: v34 0 2-Footnote-1524194 +Ref: v34 0 2-Footnote-2524248 +Node: v34 0 1524302 +Ref: history v34-0-1524392 +Ref: 20f524392 +Ref: v34 0 1-Footnote-1524511 +Node: v34 0 0524565 +Ref: history v34-0-0524655 +Ref: 210524655 +Ref: v34 0 0-Footnote-1526296 +Ref: v34 0 0-Footnote-2526350 +Ref: v34 0 0-Footnote-3526404 +Node: v33 1 1526459 +Ref: history v33-1-1526549 +Ref: 211526549 +Ref: v33 1 1-Footnote-1526714 +Node: v33 1 0526768 +Ref: history v33-1-0526858 +Ref: 212526858 +Ref: v33 1 0-Footnote-1527237 +Node: v33 0 0527286 +Ref: history v33-0-0527376 +Ref: 213527376 +Ref: v33 0 0-Footnote-1527673 +Ref: v33 0 0-Footnote-2527727 +Node: v32 3 1527785 +Ref: history v32-3-1527875 +Ref: 214527875 +Ref: v32 3 1-Footnote-1528049 +Node: v32 3 0528103 +Ref: history v32-3-0528193 +Ref: 215528193 +Ref: v32 3 0-Footnote-1528387 +Node: v32 2 0528441 +Ref: history v32-2-0528531 +Ref: 216528531 +Ref: v32 2 0-Footnote-1528766 +Ref: v32 2 0-Footnote-2528820 +Node: v32 1 3528872 +Ref: history v32-1-3528962 +Ref: 217528962 +Ref: v32 1 3-Footnote-1529156 +Node: v32 1 2529210 +Ref: history v32-1-2529300 +Ref: 218529300 +Ref: v32 1 2-Footnote-1529491 +Node: v32 1 1529545 +Ref: history v32-1-1529635 +Ref: 219529635 +Ref: v32 1 1-Footnote-1530069 +Ref: v32 1 1-Footnote-2530123 +Node: v32 1 0530177 +Ref: history v32-1-0530267 +Ref: 21a530267 +Ref: v32 1 0-Footnote-1530473 +Node: v32 0 0530527 +Ref: history v32-0-0530617 +Ref: 21b530617 +Ref: v32 0 0-Footnote-1530953 +Ref: v32 0 0-Footnote-2531007 +Ref: v32 0 0-Footnote-3531061 +Ref: v32 0 0-Footnote-4531115 +Node: v31 0 1531169 +Ref: history v31-0-1531259 +Ref: 21c531259 +Ref: v31 0 1-Footnote-1531514 +Node: v31 0 0531568 +Ref: history v31-0-0531658 +Ref: 21d531658 +Ref: v31 0 0-Footnote-1532258 +Ref: v31 0 0-Footnote-2532312 +Ref: v31 0 0-Footnote-3532366 +Ref: v31 0 0-Footnote-4532421 +Node: v30 4 0532475 +Ref: history v30-4-0532565 +Ref: 21e532565 +Ref: v30 4 0-Footnote-1533101 +Node: v30 3 0533155 +Ref: history v30-3-0533245 +Ref: 21f533245 +Ref: v30 3 0-Footnote-1533424 +Ref: v30 3 0-Footnote-2533478 +Ref: v30 3 0-Footnote-3533532 +Node: v30 2 1533641 +Ref: history v30-2-1533731 +Ref: 220533731 +Ref: v30 2 1-Footnote-1533908 +Node: v30 2 0533962 +Ref: history v30-2-0534052 +Ref: 221534052 +Ref: v30 2 0-Footnote-1534181 +Ref: v30 2 0-Footnote-2534235 +Node: v30 1 0534301 +Ref: history v30-1-0534391 +Ref: 222534391 +Ref: v30 1 0-Footnote-1534726 +Ref: v30 1 0-Footnote-2534780 +Node: v30 0 0534834 +Ref: history v30-0-0534924 +Ref: 223534924 +Ref: v30 0 0-Footnote-1535337 +Ref: v30 0 0-Footnote-2535391 +Ref: v30 0 0-Footnote-3535445 +Ref: v30 0 0-Footnote-4535499 +Node: v29 0 1535553 +Ref: history v29-0-1535643 +Ref: 224535643 +Ref: v29 0 1-Footnote-1536037 +Node: v29 0 0536091 +Ref: history v29-0-0536181 +Ref: 225536181 +Ref: v29 0 0-Footnote-1536409 +Ref: v29 0 0-Footnote-2536463 +Node: v28 8 0536520 +Ref: history v28-8-0536610 +Ref: 226536610 +Ref: v28 8 0-Footnote-1536995 +Ref: v28 8 0-Footnote-2537049 +Ref: v28 8 0-Footnote-3537103 +Node: v28 7 1537157 +Ref: history v28-7-1537247 +Ref: 227537247 +Ref: v28 7 1-Footnote-1537491 +Ref: v28 7 1-Footnote-2537545 +Ref: v28 7 1-Footnote-3537599 +Node: v28 7 0537653 +Ref: history v28-7-0537743 +Ref: 228537743 +Ref: v28 7 0-Footnote-1538138 +Ref: v28 7 0-Footnote-2538192 +Ref: v28 7 0-Footnote-3538246 +Ref: v28 7 0-Footnote-4538300 +Ref: v28 7 0-Footnote-5538354 +Node: v28 6 1538408 +Ref: history v28-6-1538498 +Ref: 229538498 +Ref: v28 6 1-Footnote-1538630 +Node: v28 6 0538684 +Ref: history v28-6-0538774 +Ref: 22a538774 +Ref: v28 6 0-Footnote-1539116 +Node: v28 5 0539170 +Ref: history v28-5-0539260 +Ref: 22b539260 +Ref: v28 5 0-Footnote-1539763 +Ref: v28 5 0-Footnote-2539817 +Ref: v28 5 0-Footnote-3539871 +Ref: v28 5 0-Footnote-4539925 +Node: v28 4 0539979 +Ref: history v28-4-0540069 +Ref: 22c540069 +Ref: v28 4 0-Footnote-1540635 +Ref: v28 4 0-Footnote-2540689 +Ref: v28 4 0-Footnote-3540739 +Ref: v28 4 0-Footnote-4540793 +Ref: v28 4 0-Footnote-5540847 +Ref: v28 4 0-Footnote-6540901 +Node: v28 3 0540955 +Ref: history v28-3-0541045 +Ref: 22d541045 +Ref: v28 3 0-Footnote-1541385 +Ref: v28 3 0-Footnote-2541439 +Ref: v28 3 0-Footnote-3541493 +Ref: v28 3 0-Footnote-4541543 +Node: v28 1 0541598 +Ref: history v28-1-0541688 +Ref: 22e541688 +Ref: v28 1 0-Footnote-1541808 +Node: v28 0 0541862 +Ref: history v28-0-0541952 +Ref: 22f541952 +Ref: v28 0 0-Footnote-1542530 +Ref: v28 0 0-Footnote-2542584 +Ref: v28 0 0-Footnote-3542638 +Node: v27 3 1542692 +Ref: history v27-3-1542782 +Ref: 230542782 +Ref: v27 3 1-Footnote-1543165 +Node: v27 3 0543219 +Ref: history v27-3-0543309 +Ref: 231543309 +Ref: v27 3 0-Footnote-1543613 +Ref: v27 3 0-Footnote-2543667 +Ref: v27 3 0-Footnote-3543717 +Node: v27 2 0543771 +Ref: history v27-2-0543861 +Ref: 232543861 +Ref: v27 2 0-Footnote-1544104 +Ref: v27 2 0-Footnote-2544158 +Node: v27 1 2544212 +Ref: history v27-1-2544302 +Ref: 233544302 +Ref: v27 1 2-Footnote-1544428 +Ref: v27 1 2-Footnote-2544482 +Node: v27 1 1544536 +Ref: history v27-1-1544626 +Ref: 234544626 +Ref: v27 1 1-Footnote-1544744 +Node: v27 1 0544798 +Ref: history v27-1-0544888 +Ref: 235544888 +Node: v27 0 0545039 +Ref: history v27-0-0545129 +Ref: 236545129 +Ref: v27 0 0-Footnote-1545944 +Ref: v27 0 0-Footnote-2545998 +Ref: v27 0 0-Footnote-3546052 +Node: v26 1 1546106 +Ref: history v26-1-1546196 +Ref: 237546196 +Node: v26 1 0546426 +Ref: history v26-1-0546516 +Ref: 238546516 +Ref: v26 1 0-Footnote-1546783 +Ref: v26 1 0-Footnote-2546837 +Node: v26 0 0546878 +Ref: history v26-0-0546968 +Ref: 239546968 +Ref: v26 0 0-Footnote-1547558 +Ref: v26 0 0-Footnote-2547612 +Ref: v26 0 0-Footnote-3547654 +Ref: v26 0 0-Footnote-4547708 +Ref: v26 0 0-Footnote-5547762 +Ref: v26 0 0-Footnote-6547816 +Node: v25 4 0547870 +Ref: history v25-4-0547960 +Ref: 23a547960 +Node: v25 3 0548519 +Ref: history v25-3-0548609 +Ref: 23b548609 +Ref: v25 3 0-Footnote-1549040 +Ref: v25 3 0-Footnote-2549094 +Ref: v25 3 0-Footnote-3549148 +Ref: v25 3 0-Footnote-4549202 +Ref: v25 3 0-Footnote-5549256 +Ref: v25 3 0-Footnote-6549310 +Ref: v25 3 0-Footnote-7549364 +Ref: v25 3 0-Footnote-8549418 +Ref: v25 3 0-Footnote-9549472 +Ref: v25 3 0-Footnote-10549526 +Node: v25 2 0549581 +Ref: history v25-2-0549671 +Ref: 23c549671 +Ref: v25 2 0-Footnote-1549860 +Ref: v25 2 0-Footnote-2549914 +Node: v25 1 6549968 +Ref: history v25-1-6550058 +Ref: 23d550058 +Ref: v25 1 6-Footnote-1550274 +Node: v25 1 5550328 +Ref: history v25-1-5550418 +Ref: 23e550418 +Ref: v25 1 5-Footnote-1550569 +Ref: v25 1 5-Footnote-2550623 +Node: v25 1 4550677 +Ref: history v25-1-4550767 +Ref: 23f550767 +Ref: v25 1 4-Footnote-1551033 +Ref: v25 1 4-Footnote-2551087 +Ref: v25 1 4-Footnote-3551141 +Ref: v25 1 4-Footnote-4551195 +Node: v25 1 3551249 +Ref: history v25-1-3551339 +Ref: 240551339 +Ref: v25 1 3-Footnote-1551571 +Ref: v25 1 3-Footnote-2551625 +Ref: v25 1 3-Footnote-3551679 +Ref: v25 1 3-Footnote-4551733 +Ref: v25 1 3-Footnote-5551787 +Node: v25 1 2551841 +Ref: history v25-1-2551931 +Ref: 241551931 +Ref: v25 1 2-Footnote-1552370 +Ref: v25 1 2-Footnote-2552424 +Ref: v25 1 2-Footnote-3552478 +Node: v25 1 1552532 +Ref: history v25-1-1552622 +Ref: 242552622 +Ref: v25 1 1-Footnote-1552846 +Ref: v25 1 1-Footnote-2552900 +Node: v25 1 0552954 +Ref: history v25-1-0553044 +Ref: 243553044 +Ref: v25 1 0-Footnote-1553424 +Node: v25 0 2553478 +Ref: history v25-0-2553568 +Ref: 244553568 +Ref: v25 0 2-Footnote-1553742 +Node: v25 0 1553796 +Ref: history v25-0-1553886 +Ref: 245553886 +Ref: v25 0 1-Footnote-1554197 +Ref: v25 0 1-Footnote-2554251 +Ref: v25 0 1-Footnote-3554305 +Ref: v25 0 1-Footnote-4554359 +Ref: v25 0 1-Footnote-5554413 +Node: v25 0 0554467 +Ref: history v25-0-0554557 +Ref: 246554557 +Ref: v25 0 0-Footnote-1555394 +Node: v24 3 1555448 +Ref: history v24-3-1555538 +Ref: 247555538 +Ref: v24 3 1-Footnote-1555871 +Ref: v24 3 1-Footnote-2555925 +Ref: v24 3 1-Footnote-3555979 +Ref: v24 3 1-Footnote-4556033 +Node: v24 3 0556087 +Ref: history v24-3-0556177 +Ref: 248556177 +Ref: v24 3 0-Footnote-1556474 +Node: v24 2 1556528 +Ref: history v24-2-1556618 +Ref: 249556618 +Ref: v24 2 1-Footnote-1556787 +Node: v24 2 0556841 +Ref: history v24-2-0556931 +Ref: 24a556931 +Ref: v24 2 0-Footnote-1557071 +Node: v24 1 1557125 +Ref: history v24-1-1557215 +Ref: 24b557215 +Ref: v24 1 1-Footnote-1557351 +Ref: v24 1 1-Footnote-2557405 +Ref: v24 1 1-Footnote-3557459 +Node: v24 1 0557513 +Ref: history v24-1-0557603 +Ref: 24c557603 +Ref: v24 1 0-Footnote-1557911 +Ref: v24 1 0-Footnote-2557965 +Ref: v24 1 0-Footnote-3558019 +Ref: v24 1 0-Footnote-4558073 +Ref: v24 1 0-Footnote-5558127 +Ref: v24 1 0-Footnote-6558181 +Ref: v24 1 0-Footnote-7558235 +Ref: v24 1 0-Footnote-8558289 +Node: v24 0 3558343 +Ref: history v24-0-3558433 +Ref: 24d558433 +Ref: v24 0 3-Footnote-1558675 +Ref: v24 0 3-Footnote-2558729 +Ref: v24 0 3-Footnote-3558783 +Ref: v24 0 3-Footnote-4558837 +Ref: v24 0 3-Footnote-5558891 +Ref: v24 0 3-Footnote-6558945 +Ref: v24 0 3-Footnote-7558999 +Ref: v24 0 3-Footnote-8559053 +Node: v24 0 2559107 +Ref: history v24-0-2559197 +Ref: 24e559197 +Node: v24 0 1559348 +Ref: history v24-0-1559438 +Ref: 24f559438 +Ref: v24 0 1-Footnote-1559610 +Ref: v24 0 1-Footnote-2559664 +Node: v24 0 0559718 +Ref: history v24-0-0559808 +Ref: 250559808 +Ref: v24 0 0-Footnote-1560221 +Node: v23 2 1560275 +Ref: history v23-2-1560365 +Ref: 251560365 +Ref: v23 2 1-Footnote-1560585 +Node: v23 1 0560639 +Ref: history v23-1-0560729 +Ref: 252560729 +Ref: v23 1 0-Footnote-1560877 +Node: v23 0 0560931 +Ref: history v23-0-0561021 +Ref: 253561021 +Ref: v23 0 0-Footnote-1561407 +Ref: v23 0 0-Footnote-2561461 +Node: v22 0 5561515 +Ref: history v22-0-5561605 +Ref: 254561605 +Ref: v22 0 5-Footnote-1561792 +Node: v22 0 4561846 +Ref: history v22-0-4561936 +Ref: 255561936 +Ref: v22 0 4-Footnote-1562104 +Node: v22 0 3562158 +Ref: history v22-0-3562248 +Ref: 256562248 +Ref: v22 0 3-Footnote-1562444 +Node: v22 0 2562498 +Ref: history v22-0-2562588 +Ref: 257562588 +Ref: v22 0 2-Footnote-1562731 +Node: v22 0 1562785 +Ref: history v22-0-1562875 +Ref: 258562875 +Ref: v22 0 1-Footnote-1563102 +Node: v22 0 0563156 +Ref: history v22-0-0563246 +Ref: 259563246 +Ref: v22 0 0-Footnote-1563537 +Ref: v22 0 0-Footnote-2563591 +Node: v21 2 2563649 +Ref: history v21-2-2563739 +Ref: 25a563739 +Node: v21 2 1563822 +Ref: history v21-2-1563912 +Ref: 25b563912 +Ref: v21 2 1-Footnote-1564063 +Node: v21 2 0564117 +Ref: history v21-2-0564207 +Ref: 25c564207 +Ref: v21 2 0-Footnote-1564393 +Node: v21 1 0564447 +Ref: history v21-1-0564537 +Ref: 25d564537 +Ref: v21 1 0-Footnote-1564855 +Node: v21 0 0564909 +Ref: history v21-0-0565000 +Ref: 25e565000 +Node: v20 10 0565278 +Ref: history v20-10-0565369 +Ref: 25f565369 +Ref: v20 10 0-Footnote-1565961 +Ref: v20 10 0-Footnote-2566015 +Ref: v20 10 0-Footnote-3566069 +Ref: v20 10 0-Footnote-4566135 +Node: v20 9 0566189 +Ref: history v20-9-0566280 +Ref: 260566280 +Ref: v20 9 0-Footnote-1566482 +Ref: v20 9 0-Footnote-2566536 +Node: v20 8 1566590 +Ref: history v20-8-1566680 +Ref: 261566680 +Ref: v20 8 1-Footnote-1566877 +Node: v20 8 0566931 +Ref: history v20-8-0567021 +Ref: 262567021 +Ref: v20 8 0-Footnote-1567243 +Node: v20 7 0567297 +Ref: history v20-7-0567387 +Ref: 263567387 +Ref: v20 7 0-Footnote-1567846 +Ref: v20 7 0-Footnote-2567900 +Ref: v20 7 0-Footnote-3567954 +Node: v20 6 8568008 +Ref: history v20-6-8568098 +Ref: 264568098 +Ref: v20 6 8-Footnote-1568290 +Node: v20 6 7568344 +Ref: history v20-6-7568434 +Ref: 265568434 +Ref: v20 6 7-Footnote-1568600 +Node: v20 6 6568654 +Ref: history v20-6-6568744 +Ref: 266568744 +Ref: v20 6 6-Footnote-1568933 +Ref: v20 6 6-Footnote-2568987 +Ref: v20 6 6-Footnote-3569037 +Node: v20 6 0569103 +Ref: history v20-6-0569190 +Ref: 267569190 +Ref: v20 6 0-Footnote-1569634 +Ref: v20 6 0-Footnote-2569681 +Node: 20 5569708 +Ref: history id610569792 +Ref: 268569792 +Ref: 20 5-Footnote-1570090 +Ref: 20 5-Footnote-2570153 +Node: 20 4570207 +Ref: history id612570290 +Ref: 269570290 +Ref: 20 4-Footnote-1570812 +Ref: 20 4-Footnote-2570866 +Ref: 20 4-Footnote-3570909 +Node: 20 3 1570955 +Ref: history id613571038 +Ref: 26a571038 +Ref: 20 3 1-Footnote-1571331 +Ref: 20 3 1-Footnote-2571385 +Node: 20 3571448 +Ref: history id614571533 +Ref: 26b571533 +Ref: 20 3-Footnote-1571959 +Ref: 20 3-Footnote-2572022 +Node: 20 2 2572085 +Ref: history id616572170 +Ref: 26c572170 +Ref: 20 2 2-Footnote-1572365 +Node: 20 2 1572419 +Ref: history id617572504 +Ref: 26d572504 +Ref: 20 2 1-Footnote-1572681 +Ref: 20 2 1-Footnote-2572735 +Node: 20 2572801 +Ref: history id618572886 +Ref: 26e572886 +Ref: 20 2-Footnote-1573761 +Ref: 20 2-Footnote-2573824 +Ref: 20 2-Footnote-3573874 +Ref: 20 2-Footnote-4573924 +Ref: 20 2-Footnote-5573990 +Ref: 20 2-Footnote-6574040 +Ref: 20 2-Footnote-7574094 +Ref: 20 2-Footnote-8574157 +Ref: 20 2-Footnote-9574220 +Ref: 20 2-Footnote-10574283 +Ref: 20 2-Footnote-11574334 +Node: 20 1 1574389 +Ref: history id624574472 +Ref: 26f574472 +Node: 20 1574603 +Ref: history id625574686 +Ref: 270574686 +Ref: 20 1-Footnote-1574876 +Node: 20 0574999 +Ref: history id626575080 +Ref: 271575080 +Ref: 20 0-Footnote-1575358 +Node: 19 7575412 +Ref: history id627575495 +Ref: 272575495 +Ref: 19 7-Footnote-1575683 +Ref: 19 7-Footnote-2575775 +Ref: 19 7-Footnote-3575867 +Node: 19 6 2575959 +Ref: history id628576044 +Ref: 273576044 +Ref: 19 6 2-Footnote-1576265 +Node: 19 6 1576319 +Ref: history id629576404 +Ref: 274576404 +Ref: 19 6 1-Footnote-1576737 +Node: 19 6576791 +Ref: history id630576874 +Ref: 275576874 +Ref: 19 6-Footnote-1577682 +Node: 19 5577736 +Ref: history id631577819 +Ref: 276577819 +Ref: 19 5-Footnote-1578127 +Ref: 19 5-Footnote-2578181 +Ref: 19 5-Footnote-3578235 +Node: 19 4 1578298 +Ref: history id632578381 +Ref: 277578381 +Ref: 19 4 1-Footnote-1578607 +Node: 19 4578661 +Ref: history id634578744 +Ref: 278578744 +Ref: 19 4-Footnote-1579296 +Ref: 19 4-Footnote-2579350 +Ref: 19 4-Footnote-3579407 +Ref: 19 4-Footnote-4579461 +Ref: 19 4-Footnote-5579515 +Node: 19 3579578 +Ref: history id635579659 +Ref: 279579659 +Ref: 19 3-Footnote-1579913 +Node: 19 2579967 +Ref: history id636580050 +Ref: 27a580050 +Ref: 19 2-Footnote-1580292 +Ref: 19 2-Footnote-2580355 +Node: 19 1 1580418 +Ref: history id637580501 +Ref: 27b580501 +Ref: 19 1 1-Footnote-1580877 +Ref: 19 1 1-Footnote-2580931 +Node: 19 1580985 +Ref: history id638581068 +Ref: 27c581068 +Ref: 19 1-Footnote-1581401 +Ref: 19 1-Footnote-2581455 +Node: 19 0581509 +Ref: history id639581592 +Ref: 27d581592 +Ref: 19 0-Footnote-1581796 +Node: 18 8 1581850 +Ref: history id640581933 +Ref: 27e581933 +Ref: 18 8 1-Footnote-1582223 +Node: 18 8582277 +Ref: history id641582362 +Ref: 27f582362 +Ref: 18 8-Footnote-1582773 +Ref: 18 8-Footnote-2582827 +Ref: 18 8-Footnote-3582881 +Node: 18 7 1582935 +Ref: history id642583018 +Ref: 280583018 +Ref: 18 7 1-Footnote-1583201 +Ref: 18 7 1-Footnote-2583255 +Node: 18 7583309 +Ref: history id644583394 +Ref: 281583394 +Ref: 18 7-Footnote-1584144 +Ref: 18 7-Footnote-2584207 +Ref: 18 7-Footnote-3584270 +Ref: 18 7-Footnote-4584324 +Ref: 18 7-Footnote-5584387 +Ref: 18 7-Footnote-6584437 +Ref: 18 7-Footnote-7584491 +Node: 18 6 1584554 +Ref: history id646584637 +Ref: 282584637 +Ref: 18 6 1-Footnote-1584818 +Node: 18 6584872 +Ref: history id647584955 +Ref: 283584955 +Ref: 18 6-Footnote-1585201 +Node: 18 5585255 +Ref: history id648585336 +Ref: 284585336 +Ref: 18 5-Footnote-1585707 +Ref: 18 5-Footnote-2585799 +Node: 18 4585891 +Ref: history id649585974 +Ref: 285585974 +Ref: 18 4-Footnote-1586149 +Node: 18 3 2586203 +Ref: history id650586288 +Ref: 286586288 +Ref: 18 3 2-Footnote-1586469 +Node: 18 3 1586511 +Ref: history id651586596 +Ref: 287586596 +Ref: 18 3 1-Footnote-1586735 +Node: 18 3586789 +Ref: history id652586872 +Ref: 288586872 +Ref: 18 3-Footnote-1587762 +Ref: 18 3-Footnote-2587825 +Node: 18 2587879 +Ref: history id653587960 +Ref: 289587960 +Ref: 18 2-Footnote-1588109 +Node: 18 1588163 +Ref: history id654588246 +Ref: 28a588246 +Ref: 18 1-Footnote-1588363 +Node: 18 0 1588429 +Ref: history id655588512 +Ref: 28b588512 +Ref: 18 0 1-Footnote-1588636 +Node: 18 0588690 +Ref: history id656588775 +Ref: 28c588775 +Ref: 18 0-Footnote-1589841 +Ref: 18 0-Footnote-2589895 +Ref: 18 0-Footnote-3589949 +Node: 17 1 1590012 +Ref: history id657590095 +Ref: 28d590095 +Ref: 17 1 1-Footnote-1590283 +Node: 17 1590395 +Ref: history id658590478 +Ref: 28e590478 +Ref: 17 1-Footnote-1590642 +Node: 17 0590696 +Ref: history id659590777 +Ref: 28f590777 +Ref: 17 0-Footnote-1591085 +Ref: 17 0-Footnote-2591139 +Node: 16 0591193 +Ref: history id660591274 +Ref: 290591274 +Ref: 16 0-Footnote-1591627 +Ref: 16 0-Footnote-2591690 +Ref: 16 0-Footnote-3591753 +Node: 15 2591816 +Ref: history id661591897 +Ref: 291591897 +Ref: 15 2-Footnote-1592142 +Node: 15 1592196 +Ref: history id662592277 +Ref: 292592277 +Ref: 15 1-Footnote-1592477 +Ref: 15 1-Footnote-2592543 +Node: 15 0592595 +Ref: history id663592678 +Ref: 293592678 +Ref: 15 0-Footnote-1593278 +Ref: 15 0-Footnote-2593341 +Node: 14 3 1593397 +Ref: history id664593480 +Ref: 294593480 +Ref: 14 3 1-Footnote-1593773 +Ref: 14 3 1-Footnote-2593827 +Ref: 14 3 1-Footnote-3593877 +Node: 14 3593931 +Ref: history id666594014 +Ref: 295594014 +Ref: 14 3-Footnote-1594268 +Node: 14 2594322 +Ref: history id667594405 +Ref: 296594405 +Ref: 14 2-Footnote-1594665 +Node: 14 1 1594719 +Ref: history id668594802 +Ref: 297594802 +Ref: 14 1 1-Footnote-1595014 +Node: 14 1595068 +Ref: history id669595151 +Ref: 298595151 +Ref: 14 1-Footnote-1595336 +Node: 14 0595399 +Ref: history id670595482 +Ref: 299595482 +Ref: 14 0-Footnote-1596311 +Ref: 14 0-Footnote-2596374 +Node: 13 0 2596428 +Ref: history id671596513 +Ref: 29a596513 +Ref: 13 0 2-Footnote-1596718 +Node: 13 0 1596772 +Ref: history id672596857 +Ref: 29b596857 +Node: 13 0597037 +Ref: history id673597120 +Ref: 29c597120 +Ref: 13 0-Footnote-1597500 +Ref: 13 0-Footnote-2597554 +Node: 12 4597617 +Ref: history id674597698 +Ref: 29d597698 +Ref: 12 4-Footnote-1597904 +Node: 12 3597967 +Ref: history id676598048 +Ref: 29e598048 +Ref: 12 3-Footnote-1598369 +Node: 12 2598423 +Ref: history id677598504 +Ref: 29f598504 +Ref: 12 2-Footnote-1598956 +Ref: 12 2-Footnote-2599010 +Node: 12 1599064 +Ref: history id678599147 +Ref: 2a0599147 +Ref: 12 1-Footnote-1599315 +Node: 12 0 5599378 +Ref: history id679599463 +Ref: 2a1599463 +Ref: 12 0 5-Footnote-1599687 +Ref: 12 0 5-Footnote-2599741 +Node: 12 0 4599795 +Ref: history id681599882 +Ref: 2a2599882 +Ref: 12 0 4-Footnote-1600020 +Node: 12 0 3600074 +Ref: history id682600161 +Ref: 2a3600161 +Node: 12 0 2600292 +Ref: history id683600379 +Ref: 2a4600379 +Ref: 12 0 2-Footnote-1600559 +Node: 12 0 1600613 +Ref: history id684600698 +Ref: 2a5600698 +Node: 12 0600904 +Ref: history id685600989 +Ref: 2a6600989 +Ref: 12 0-Footnote-1601548 +Node: 11 3 1601602 +Ref: history id686601685 +Ref: 2a7601685 +Ref: 11 3 1-Footnote-1601869 +Node: 11 3601923 +Ref: history id687602006 +Ref: 2a8602006 +Node: 11 2602529 +Ref: history id688602610 +Ref: 2a9602610 +Ref: 11 2-Footnote-1602772 +Node: 11 1602820 +Ref: history id689602901 +Ref: 2aa602901 +Ref: 11 1-Footnote-1603425 +Ref: 11 1-Footnote-2603479 +Node: 11 0603533 +Ref: history id690603616 +Ref: 2ab603616 +Ref: 11 0-Footnote-1603847 +Ref: 11 0-Footnote-2603910 +Ref: 11 0-Footnote-3603976 +Node: 10 2 1604026 +Ref: history id692604109 +Ref: 2ac604109 +Ref: 10 2 1-Footnote-1604250 +Node: 10 2604304 +Ref: history id693604387 +Ref: 2ad604387 +Node: 10 1604758 +Ref: history id694604841 +Ref: 2ae604841 +Ref: 10 1-Footnote-1605119 +Node: 10 0 1605173 +Ref: history id695605256 +Ref: 2af605256 +Ref: 10 0 1-Footnote-1605401 +Node: 10 0605455 +Ref: history id696605537 +Ref: 2b0605537 +Ref: 10 0-Footnote-1606091 +Ref: 10 0-Footnote-2606145 +Ref: 10 0-Footnote-3606194 +Node: 9 1606248 +Ref: history id697606329 +Ref: 2b1606329 +Ref: 9 1-Footnote-1606458 +Node: 9 0 1606550 +Ref: history id698606630 +Ref: 2b2606630 +Ref: 9 0 1-Footnote-1606795 +Node: 9 0606849 +Ref: history id699606929 +Ref: 2b3606929 +Ref: 9 0-Footnote-1607158 +Node: 8 4607212 +Ref: history id700607290 +Ref: 2b4607290 +Ref: 8 4-Footnote-1607432 +Node: 8 3607495 +Ref: history id701607575 +Ref: 2b5607575 +Ref: 8 3-Footnote-1607781 +Node: 8 2 1607835 +Ref: history id702607915 +Ref: 2b6607915 +Ref: 8 2 1-Footnote-1608105 +Node: 8 2608159 +Ref: history id703608239 +Ref: 2b7608239 +Ref: 8 2-Footnote-1608394 +Node: 8 1608456 +Ref: history id704608536 +Ref: 2b8608536 +Ref: 8 1-Footnote-1608902 +Node: 8 0 4608952 +Ref: history id706609034 +Ref: 2b9609034 +Ref: 8 0 4-Footnote-1609495 +Node: 8 0 3609549 +Ref: history id707609633 +Ref: 2ba609633 +Ref: 8 0 3-Footnote-1609795 +Node: 8 0 2609849 +Ref: history id709609933 +Ref: 2bb609933 +Ref: 8 0 2-Footnote-1610117 +Node: 8 0 1610171 +Ref: history id711610253 +Ref: 2bc610253 +Ref: 8 0 1-Footnote-1610487 +Node: 8 0610541 +Ref: history id713610621 +Ref: 2bd610621 +Ref: 8 0-Footnote-1611092 +Ref: 8 0-Footnote-2611142 +Ref: 8 0-Footnote-3611277 +Node: 7 0611319 +Ref: history id715611397 +Ref: 2be611397 +Ref: 7 0-Footnote-1612340 +Ref: 7 0-Footnote-2612393 +Ref: 7 0-Footnote-3612447 +Node: 6 1612501 +Ref: history id717612581 +Ref: 2bf612581 +Ref: 6 1-Footnote-1612804 +Node: 6 0 2612858 +Ref: history id719612940 +Ref: 2c0612940 +Ref: 6 0 2-Footnote-1613140 +Ref: 6 0 2-Footnote-2613194 +Node: 6 0 1613248 +Ref: history id721613330 +Ref: 2c1613330 +Ref: 6 0 1-Footnote-1613533 +Node: 6 0613587 +Ref: history id722613667 +Ref: 2c2613667 +Ref: 6 0-Footnote-1615185 +Ref: 6 0-Footnote-2615239 +Ref: 6 0-Footnote-3615301 +Ref: 6 0-Footnote-4615363 +Ref: 6 0-Footnote-5615425 +Ref: 6 0-Footnote-6615479 +Node: 5 8615533 +Ref: history id724615611 +Ref: 2c3615611 +Ref: 5 8-Footnote-1615886 +Node: 5 7615940 +Ref: history id725616018 +Ref: 2c4616018 +Ref: 5 7-Footnote-1616549 +Ref: 5 7-Footnote-2616603 +Node: 5 6616657 +Ref: history id726616737 +Ref: 2c5616737 +Ref: 5 6-Footnote-1616941 +Node: 5 5 1616995 +Ref: history id727617075 +Ref: 2c6617075 +Ref: 5 5 1-Footnote-1617214 +Node: 5 5617268 +Ref: history id728617350 +Ref: 2c7617350 +Ref: 5 5-Footnote-1617610 +Node: 5 4 2617664 +Ref: history id730617746 +Ref: 2c8617746 +Ref: 5 4 2-Footnote-1617910 +Node: 5 4 1617964 +Ref: history id731618046 +Ref: 2c9618046 +Ref: 5 4 1-Footnote-1618225 +Node: 5 4618266 +Ref: history id732618346 +Ref: 2ca618346 +Ref: 5 4-Footnote-1618898 +Node: 5 3618952 +Ref: history id734619030 +Ref: 2cb619030 +Ref: 5 3-Footnote-1619295 +Node: 5 2619349 +Ref: history id735619427 +Ref: 2cc619427 +Ref: 5 2-Footnote-1619782 +Node: 5 1619855 +Ref: history id736619935 +Ref: 2cd619935 +Ref: 5 1-Footnote-1620185 +Ref: 5 1-Footnote-2620239 +Node: 5 0 2620293 +Ref: history id737620375 +Ref: 2ce620375 +Ref: 5 0 2-Footnote-1620497 +Node: 5 0 1620551 +Ref: history id738620633 +Ref: 2cf620633 +Node: 5 0620836 +Ref: history id739620938 +Ref: 2d0620938 +Ref: 5 0-Footnote-1621185 +Node: 3 7 1 and 3 8 1 and 4 0 1621239 +Ref: history and-3-8-1-and-4-0-1621339 +Ref: 2d1621339 +Ref: 3 7 1 and 3 8 1 and 4 0 1-Footnote-1621645 +Ref: 3 7 1 and 3 8 1 and 4 0 1-Footnote-2621699 +Node: 4 0621753 +Ref: history id741621853 +Ref: 2d2621853 +Ref: 4 0-Footnote-1622086 +Node: 3 8622140 +Ref: history id742622218 +Ref: 2d3622218 +Ref: 3 8-Footnote-1622380 +Node: 3 7622434 +Ref: history id743622512 +Ref: 2d4622512 +Ref: 3 7-Footnote-1622672 +Node: 3 6622726 +Ref: history id744622806 +Ref: 2d5622806 +Ref: 3 6-Footnote-1622975 +Node: 3 5 2623029 +Ref: history id745623111 +Ref: 2d6623111 +Ref: 3 5 2-Footnote-1623343 +Node: 3 5 1623397 +Ref: history id747623479 +Ref: 2d7623479 +Ref: 3 5 1-Footnote-1623658 +Node: 3 5623712 +Ref: history id748623794 +Ref: 2d8623794 +Ref: 3 5-Footnote-1624280 +Ref: 3 5-Footnote-2624334 +Ref: 3 5-Footnote-3624388 +Node: 3 4 4624442 +Ref: history id750624524 +Ref: 2d9624524 +Ref: 3 4 4-Footnote-1624731 +Node: 3 4 3624785 +Ref: history id751624869 +Ref: 2da624869 +Ref: 3 4 3-Footnote-1625005 +Node: 3 4 2625059 +Ref: history id752625143 +Ref: 2db625143 +Ref: 3 4 2-Footnote-1625300 +Node: 3 4 1625354 +Ref: history id754625436 +Ref: 2dc625436 +Ref: 3 4 1-Footnote-1625600 +Node: 3 4625654 +Ref: history id755625734 +Ref: 2dd625734 +Ref: 3 4-Footnote-1626168 +Ref: 3 4-Footnote-2626222 +Node: 3 3626276 +Ref: history id756626354 +Ref: 2de626354 +Node: 3 2626459 +Ref: history id757626537 +Ref: 2df626537 +Ref: 3 2-Footnote-1626823 +Ref: 3 2-Footnote-2626885 +Ref: 3 2-Footnote-3626939 +Node: 3 1626993 +Ref: history id758627073 +Ref: 2e0627073 +Ref: 3 1-Footnote-1627314 +Node: 3 0 2627368 +Ref: history id759627450 +Ref: 2e1627450 +Node: 3 0 1627527 +Ref: history id760627609 +Ref: 2e2627609 +Ref: 3 0 1-Footnote-1627841 +Node: 3 0627895 +Ref: history id761627975 +Ref: 2e3627975 +Ref: 3 0-Footnote-1629765 +Ref: 3 0-Footnote-2629819 +Ref: 3 0-Footnote-3629872 +Ref: 3 0-Footnote-4629926 +Ref: 3 0-Footnote-5629978 +Ref: 3 0-Footnote-6630031 +Ref: 3 0-Footnote-7630093 +Node: 2 2630147 +Ref: history id762630227 +Ref: 2e4630227 +Ref: 2 2-Footnote-1630583 +Ref: 2 2-Footnote-2630637 +Node: 2 1 2630691 +Ref: history id764630773 +Ref: 2e5630773 +Ref: 2 1 2-Footnote-1630967 +Node: 2 1 1631021 +Ref: history id765631103 +Ref: 2e6631103 +Ref: 2 1 1-Footnote-1631276 +Node: 2 1631330 +Ref: history id767631412 +Ref: 2e7631412 +Ref: 2 1-Footnote-1631670 +Ref: 2 1-Footnote-2631724 +Node: 2 0 2631778 +Ref: history id768631860 +Ref: 2e8631860 +Node: 2 0 1632061 +Ref: history id769632143 +Ref: 2e9632143 +Ref: 2 0 1-Footnote-1632284 +Node: 2 0632338 +Ref: history id770632420 +Ref: 2ea632420 +Ref: 2 0-Footnote-1633030 +Ref: 2 0-Footnote-2633084 +Node: 1 4 2633137 +Ref: history id771633219 +Ref: 2eb633219 +Ref: 1 4 2-Footnote-1633385 +Node: 1 4 1633439 +Ref: history id772633521 +Ref: 2ec633521 +Ref: 1 4 1-Footnote-1635078 +Ref: 1 4 1-Footnote-2635132 +Ref: 1 4 1-Footnote-3635186 +Node: 1 4635240 +Ref: history id773635322 +Ref: 2ed635322 +Ref: 1 4-Footnote-1635680 +Ref: 1 4-Footnote-2635733 +Node: 1 3 2635795 +Ref: history id774635877 +Ref: 2ee635877 +Ref: 1 3 2-Footnote-1636016 +Node: 1 3 1636069 +Ref: history id775636151 +Ref: 2ef636151 +Node: 1 3636257 +Ref: history id776636337 +Ref: 2f0636337 +Ref: 1 3-Footnote-1636674 +Ref: 1 3-Footnote-2636716 +Node: 1 2636779 +Ref: history id777636859 +Ref: 2f1636859 +Ref: 1 2-Footnote-1637442 +Ref: 1 2-Footnote-2637495 +Ref: 1 2-Footnote-3637548 +Node: 1 1 7637602 +Ref: history id778637684 +Ref: 2f2637684 +Ref: 1 1 7-Footnote-1638096 +Ref: 1 1 7-Footnote-2638153 +Node: 1 1 6638206 +Ref: history id779638290 +Ref: 2f3638290 +Ref: 1 1 6-Footnote-1638507 +Node: 1 1 5638564 +Ref: history id780638648 +Ref: 2f4638648 +Ref: 1 1 5-Footnote-1638786 +Node: 1 1 4638839 +Ref: history id781638923 +Ref: 2f5638923 +Ref: 1 1 4-Footnote-1639059 +Node: 1 1 3639112 +Ref: history id782639196 +Ref: 2f6639196 +Node: 1 1 2639273 +Ref: history id783639357 +Ref: 2f7639357 +Ref: 1 1 2-Footnote-1639549 +Node: 1 1 1639602 +Ref: history id785639684 +Ref: 2f8639684 +Ref: 1 1 1-Footnote-1639980 +Ref: 1 1 1-Footnote-2640033 +Node: 1 1640086 +Ref: history id786640166 +Ref: 2f9640166 +Ref: 1 1-Footnote-1640463 +Ref: 1 1-Footnote-2640516 +Ref: 1 1-Footnote-3640573 +Node: 1 0640626 +Ref: history id787640706 +Ref: 2fa640706 +Ref: 1 0-Footnote-1641904 +Ref: 1 0-Footnote-2641957 +Ref: 1 0-Footnote-3642003 +Ref: 1 0-Footnote-4642056 +Ref: 1 0-Footnote-5642109 +Node: Backward-Incompatible Changes642162 +Ref: history backward-incompatible-changes642235 +Ref: 2fb642235 +Ref: Backward-Incompatible Changes-Footnote-1643158 +Ref: Backward-Incompatible Changes-Footnote-2643211 +Node: 0 9 8643264 +Ref: history id790643346 +Ref: 2fc643346 +Ref: 0 9 8-Footnote-1643489 +Node: 0 9 7643542 +Ref: history id791643626 +Ref: 2fd643626 +Ref: 0 9 7-Footnote-1644008 +Ref: 0 9 7-Footnote-2644061 +Node: 0 9 6644114 +Ref: history id792644198 +Ref: 2fe644198 +Ref: 0 9 6-Footnote-1644378 +Node: 0 9 5644431 +Ref: history id793644515 +Ref: 2ff644515 +Ref: 0 9 5-Footnote-1644676 +Node: 0 9 4644718 +Ref: history id794644802 +Ref: 300644802 +Ref: 0 9 4-Footnote-1645007 +Node: 0 9 3645060 +Ref: history id795645144 +Ref: 301645144 +Ref: 0 9 3-Footnote-1645291 +Node: 0 9 2645344 +Ref: history id796645428 +Ref: 302645428 +Ref: 0 9 2-Footnote-1645603 +Node: 0 9 1645656 +Ref: history id798645738 +Ref: 303645738 +Ref: 0 9 1-Footnote-1645961 +Node: 0 9646018 +Ref: history id799646098 +Ref: 304646098 +Node: 0 8646218 +Ref: history id800646298 +Ref: 305646298 +Node: 0 7 8646421 +Ref: history id801646503 +Ref: 306646503 +Ref: 0 7 8-Footnote-1646647 +Node: 0 7 7646704 +Ref: history id802646788 +Ref: 307646788 +Ref: 0 7 7-Footnote-1646998 +Ref: 0 7 7-Footnote-2647055 +Node: 0 7 6647108 +Ref: history id804647192 +Ref: 308647192 +Ref: 0 7 6-Footnote-1647339 +Node: 0 7 5647396 +Ref: history id806647480 +Ref: 309647480 +Ref: 0 7 5-Footnote-1647922 +Ref: 0 7 5-Footnote-2647975 +Node: 0 7 4648032 +Ref: history id808648116 +Ref: 30a648116 +Ref: 0 7 4-Footnote-1648260 +Node: 0 7 3648313 +Ref: history id809648397 +Ref: 30b648397 +Ref: 0 7 3-Footnote-1648623 +Node: 0 7 2648675 +Ref: history id810648759 +Ref: 30c648759 +Ref: 0 7 2-Footnote-1649011 +Ref: 0 7 2-Footnote-2649064 +Node: 0 7 1649117 +Ref: history id811649199 +Ref: 30d649199 +Ref: 0 7 1-Footnote-1649336 +Node: 0 7649388 +Ref: history id812649470 +Ref: 30e649470 +Ref: 0 7-Footnote-1650291 +Node: 0 7b4650341 +Ref: history b4650424 +Ref: 30f650424 +Ref: 0 7b4-Footnote-1650536 +Node: 0 6 49650588 +Ref: history id815650674 +Ref: 310650674 +Ref: 0 6 49-Footnote-1650946 +Node: 0 6 48651003 +Ref: history id817651090 +Ref: 311651090 +Node: 0 6 47651233 +Ref: history id818651320 +Ref: 312651320 +Node: 0 6 46651456 +Ref: history id819651543 +Ref: 313651543 +Ref: 0 6 46-Footnote-1651795 +Node: 0 6 45651852 +Ref: history id821651939 +Ref: 314651939 +Ref: 0 6 45-Footnote-1652175 +Node: 0 6 44652232 +Ref: history id822652319 +Ref: 315652319 +Node: 0 6 43652464 +Ref: history id823652551 +Ref: 316652551 +Ref: 0 6 43-Footnote-1652720 +Node: 0 6 42652777 +Ref: history id824652864 +Ref: 317652864 +Ref: 0 6 42-Footnote-1653154 +Ref: 0 6 42-Footnote-2653211 +Node: 0 6 41653264 +Ref: history id826653351 +Ref: 318653351 +Ref: 0 6 41-Footnote-1653736 +Node: 0 6 40653792 +Ref: history id827653879 +Ref: 319653879 +Ref: 0 6 40-Footnote-1654062 +Node: 0 6 39654119 +Ref: history id828654206 +Ref: 31a654206 +Ref: 0 6 39-Footnote-1654702 +Node: 0 6 38654759 +Ref: history id830654846 +Ref: 31b654846 +Ref: 0 6 38-Footnote-1655007 +Node: 0 6 37655064 +Ref: history id831655151 +Ref: 31c655151 +Ref: 0 6 37-Footnote-1655501 +Ref: 0 6 37-Footnote-2655558 +Node: 0 6 36655635 +Ref: history id832655722 +Ref: 31d655722 +Ref: 0 6 36-Footnote-1656127 +Ref: 0 6 36-Footnote-2656189 +Node: 0 6 35656244 +Ref: history id833656331 +Ref: 31e656331 +Ref: 0 6 35-Footnote-1656722 +Node: 0 6 34656779 +Ref: history id834656866 +Ref: 31f656866 +Ref: 0 6 34-Footnote-1657008 +Node: 0 6 33657065 +Ref: history id835657152 +Ref: 320657152 +Ref: 0 6 33-Footnote-1657693 +Ref: 0 6 33-Footnote-2657750 +Node: 0 6 32657807 +Ref: history id837657894 +Ref: 321657894 +Ref: 0 6 32-Footnote-1658198 +Node: 0 6 31658255 +Ref: history id838658342 +Ref: 322658342 +Ref: 0 6 31-Footnote-1659665 +Ref: 0 6 31-Footnote-2659722 +Ref: 0 6 31-Footnote-3659779 +Ref: 0 6 31-Footnote-4659820 +Ref: 0 6 31-Footnote-5659861 +Ref: 0 6 31-Footnote-6659918 +Ref: 0 6 31-Footnote-7659972 +Node: 0 6 30660029 +Ref: history id840660116 +Ref: 323660116 +Ref: 0 6 30-Footnote-1660322 +Node: 0 6 29660379 +Ref: history id841660466 +Ref: 324660466 +Ref: 0 6 29-Footnote-1662658 +Ref: 0 6 29-Footnote-2662720 +Ref: 0 6 29-Footnote-3662777 +Ref: 0 6 29-Footnote-4662830 +Ref: 0 6 29-Footnote-5662883 +Ref: 0 6 29-Footnote-6662940 +Ref: 0 6 29-Footnote-7662997 +Ref: 0 6 29-Footnote-8663054 +Ref: 0 6 29-Footnote-9663111 +Ref: 0 6 29-Footnote-10663168 +Ref: 0 6 29-Footnote-11663226 +Ref: 0 6 29-Footnote-12663284 +Ref: 0 6 29-Footnote-13663342 +Ref: 0 6 29-Footnote-14663400 +Ref: 0 6 29-Footnote-15663458 +Ref: 0 6 29-Footnote-16663516 +Ref: 0 6 29-Footnote-17663574 +Ref: 0 6 29-Footnote-18663632 +Ref: 0 6 29-Footnote-19663690 +Node: 0 6 28663748 +Ref: history id845663835 +Ref: 325663835 +Ref: 0 6 28-Footnote-1664191 +Ref: 0 6 28-Footnote-2664248 +Node: 0 6 27664305 +Ref: history id847664392 +Ref: 326664392 +Ref: 0 6 27-Footnote-1664811 +Ref: 0 6 27-Footnote-2664865 +Node: 0 6 26664922 +Ref: history id849665009 +Ref: 327665009 +Ref: 0 6 26-Footnote-1665410 +Ref: 0 6 26-Footnote-2665467 +Node: 0 6 25665524 +Ref: history id850665611 +Ref: 328665611 +Ref: 0 6 25-Footnote-1666330 +Ref: 0 6 25-Footnote-2666387 +Ref: 0 6 25-Footnote-3666444 +Ref: 0 6 25-Footnote-4666501 +Ref: 0 6 25-Footnote-5666558 +Ref: 0 6 25-Footnote-6666615 +Node: 0 6 24666672 +Ref: history id851666759 +Ref: 329666759 +Ref: 0 6 24-Footnote-1666898 +Node: 0 6 23666955 +Ref: history id852667042 +Ref: 32a667042 +Ref: 0 6 23-Footnote-1667811 +Ref: 0 6 23-Footnote-2667868 +Ref: 0 6 23-Footnote-3667925 +Ref: 0 6 23-Footnote-4667982 +Ref: 0 6 23-Footnote-5668039 +Ref: 0 6 23-Footnote-6668096 +Ref: 0 6 23-Footnote-7668153 +Ref: 0 6 23-Footnote-8668210 +Ref: 0 6 23-Footnote-9668267 +Ref: 0 6 23-Footnote-10668324 +Ref: 0 6 23-Footnote-11668382 +Node: 0 6 21668440 +Ref: history id854668527 +Ref: 32b668527 +Ref: 0 6 21-Footnote-1668657 +Node: 0 6 20668714 +Ref: history id856668801 +Ref: 32c668801 +Ref: 0 6 20-Footnote-1669122 +Ref: 0 6 20-Footnote-2669179 +Ref: 0 6 20-Footnote-3669236 +Node: 0 6 19669293 +Ref: history id857669380 +Ref: 32d669380 +Ref: 0 6 19-Footnote-1669562 +Node: 0 6 18669619 +Ref: history id858669706 +Ref: 32e669706 +Ref: 0 6 18-Footnote-1669870 +Ref: 0 6 18-Footnote-2669927 +Node: 0 6 17669984 +Ref: history id859670071 +Ref: 32f670071 +Ref: 0 6 17-Footnote-1670661 +Ref: 0 6 17-Footnote-2670718 +Ref: 0 6 17-Footnote-3670775 +Node: 0 6 16670832 +Ref: history id861670919 +Ref: 330670919 +Ref: 0 6 16-Footnote-1671310 +Ref: 0 6 16-Footnote-2671367 +Ref: 0 6 16-Footnote-3671424 +Ref: 0 6 16-Footnote-4671481 +Node: 0 6 15671538 +Ref: history id862671625 +Ref: 331671625 +Ref: 0 6 15-Footnote-1671882 +Node: 0 6 14671939 +Ref: history id863672026 +Ref: 332672026 +Ref: 0 6 14-Footnote-1672454 +Ref: 0 6 14-Footnote-2672511 +Ref: 0 6 14-Footnote-3672568 +Ref: 0 6 14-Footnote-4672625 +Node: 0 6 13672682 +Ref: history id865672769 +Ref: 333672769 +Ref: 0 6 13-Footnote-1673137 +Ref: 0 6 13-Footnote-2673194 +Ref: 0 6 13-Footnote-3673251 +Node: 0 6 12673308 +Ref: history id866673395 +Ref: 334673395 +Ref: 0 6 12-Footnote-1673531 +Node: 0 6 11673588 +Ref: history id867673675 +Ref: 335673675 +Ref: 0 6 11-Footnote-1674633 +Ref: 0 6 11-Footnote-2674689 +Ref: 0 6 11-Footnote-3674745 +Ref: 0 6 11-Footnote-4674802 +Ref: 0 6 11-Footnote-5674859 +Ref: 0 6 11-Footnote-6674916 +Ref: 0 6 11-Footnote-7674973 +Ref: 0 6 11-Footnote-8675030 +Ref: 0 6 11-Footnote-9675087 +Ref: 0 6 11-Footnote-10675144 +Node: 0 6 10675202 +Ref: history id868675288 +Ref: 336675288 +Node: 0 6 9675488 +Ref: history id869675573 +Ref: 337675573 +Ref: 0 6 9-Footnote-1677104 +Ref: 0 6 9-Footnote-2677160 +Ref: 0 6 9-Footnote-3677216 +Ref: 0 6 9-Footnote-4677272 +Ref: 0 6 9-Footnote-5677328 +Ref: 0 6 9-Footnote-6677384 +Ref: 0 6 9-Footnote-7677440 +Ref: 0 6 9-Footnote-8677496 +Ref: 0 6 9-Footnote-9677552 +Ref: 0 6 9-Footnote-10677609 +Ref: 0 6 9-Footnote-11677666 +Ref: 0 6 9-Footnote-12677724 +Ref: 0 6 9-Footnote-13677782 +Node: 0 6 8677840 +Ref: history id871677924 +Ref: 338677924 +Node: 0 6 7678079 +Ref: history id872678163 +Ref: 339678163 +Ref: 0 6 7-Footnote-1679567 +Ref: 0 6 7-Footnote-2679623 +Ref: 0 6 7-Footnote-3679679 +Ref: 0 6 7-Footnote-4679735 +Ref: 0 6 7-Footnote-5679791 +Ref: 0 6 7-Footnote-6679847 +Node: 0 6 6679903 +Ref: history id873679987 +Ref: 33a679987 +Node: 0 6 5680136 +Ref: history id874680220 +Ref: 33b680220 +Ref: 0 6 5-Footnote-1680900 +Ref: 0 6 5-Footnote-2680956 +Ref: 0 6 5-Footnote-3681012 +Ref: 0 6 5-Footnote-4681062 +Node: 0 6 4681112 +Ref: history id875681196 +Ref: 33c681196 +Ref: 0 6 4-Footnote-1681608 +Ref: 0 6 4-Footnote-2681664 +Node: 0 6 3681720 +Ref: history id876681804 +Ref: 33d681804 +Node: setuptools681885 +Ref: history setuptools681963 +Ref: 33e681963 +Node: bootstrapping682074 +Ref: history bootstrapping682152 +Ref: 33f682152 +Node: 0 6 2682269 +Ref: history id877682353 +Ref: 340682353 +Node: setuptools<2>682465 +Ref: history id878682549 +Ref: 341682549 +Ref: setuptools<2>-Footnote-1683115 +Ref: setuptools<2>-Footnote-2683165 +Ref: setuptools<2>-Footnote-3683221 +Ref: setuptools<2>-Footnote-4683271 +Ref: setuptools<2>-Footnote-5683320 +Node: bootstrapping<2>683370 +Ref: history id879683454 +Ref: 342683454 +Ref: bootstrapping<2>-Footnote-1683804 +Ref: bootstrapping<2>-Footnote-2683860 +Ref: bootstrapping<2>-Footnote-3683916 +Node: 0 6 1683966 +Ref: history id880684048 +Ref: 343684048 +Node: setuptools<3>684160 +Ref: history id881684244 +Ref: 344684244 +Ref: setuptools<3>-Footnote-1684831 +Ref: setuptools<3>-Footnote-2684887 +Ref: setuptools<3>-Footnote-3684943 +Ref: setuptools<3>-Footnote-4684993 +Ref: setuptools<3>-Footnote-5685043 +Node: bootstrapping<3>685099 +Ref: history id882685183 +Ref: 345685183 +Ref: bootstrapping<3>-Footnote-1685453 +Node: 0 6685509 +Ref: history id883685591 +Ref: 346685591 +Node: setuptools<4>685699 +Ref: history id884685778 +Ref: 347685778 +Ref: setuptools<4>-Footnote-1686417 +Ref: setuptools<4>-Footnote-2686473 +Ref: setuptools<4>-Footnote-3686529 +Ref: setuptools<4>-Footnote-4686584 +Ref: setuptools<4>-Footnote-5686639 +Ref: setuptools<4>-Footnote-6686694 +Node: pkg_resources686749 +Ref: history pkg-resources686849 +Ref: 348686849 +Ref: pkg_resources-Footnote-1687509 +Ref: pkg_resources-Footnote-2687561 +Ref: pkg_resources-Footnote-3687617 +Ref: pkg_resources-Footnote-4687672 +Ref: pkg_resources-Footnote-5687727 +Node: easy_install687782 +Ref: history easy-install687860 +Ref: 349687860 +Ref: easy_install-Footnote-1688012 +Node: 0 6c9688067 +Ref: history c9688149 +Ref: 34a688149 +Node: 0 6c7691270 +Ref: history c7691354 +Ref: 34b691354 +Node: 0 6c6692024 +Ref: history c6692108 +Ref: 34c692108 +Node: 0 6c5693672 +Ref: history c5693756 +Ref: 34d693756 +Node: 0 6c4694230 +Ref: history c4694314 +Ref: 34e694314 +Node: 0 6c3696864 +Ref: history c3696948 +Ref: 34f696948 +Node: 0 6c2697218 +Ref: history c2697302 +Ref: 350697302 +Node: 0 6c1698423 +Ref: history c1698507 +Ref: 351698507 +Node: 0 6b4699742 +Ref: history id889699826 +Ref: 352699826 +Node: 0 6b3701372 +Ref: history b3701456 +Ref: 353701456 +Node: 0 6b2702307 +Ref: history b2702391 +Ref: 354702391 +Node: 0 6b1702899 +Ref: history b1702984 +Ref: 355702984 +Node: 0 6a11704131 +Ref: history a11704217 +Ref: 356704217 +Node: 0 6a10706884 +Ref: history a10706970 +Ref: 357706970 +Node: 0 6a9709771 +Ref: history a9709856 +Ref: 358709856 +Node: 0 6a8713618 +Ref: history a8713702 +Ref: 359713702 +Node: 0 6a7715945 +Ref: history a7716029 +Ref: 35a716029 +Node: 0 6a6716148 +Ref: history a6716232 +Ref: 35b716232 +Node: 0 6a5717371 +Ref: history a5717455 +Ref: 35c717455 +Node: 0 6a3717573 +Ref: history a3717657 +Ref: 35d717657 +Node: 0 6a2718537 +Ref: history a2718621 +Ref: 35e718621 +Node: 0 6a1719514 +Ref: history a1719599 +Ref: 35f719599 +Ref: 0 6a1-Footnote-1724998 +Node: 0 5a12725097 +Ref: history a12725183 +Ref: 360725183 +Node: 0 5a11725778 +Ref: history id890725865 +Ref: 361725865 +Node: 0 5a10726046 +Ref: history id891726132 +Ref: 362726132 +Node: 0 5a9726390 +Ref: history id892726475 +Ref: 363726475 +Node: 0 5a8729999 +Ref: history id893730083 +Ref: 364730083 +Node: 0 5a7731866 +Ref: history id894731950 +Ref: 365731950 +Node: 0 5a6732165 +Ref: history id895732249 +Ref: 366732249 +Node: 0 5a5733234 +Ref: history id896733318 +Ref: 367733318 +Node: 0 5a4734902 +Ref: history a4734986 +Ref: 368734986 +Node: 0 5a3737029 +Ref: history id897737113 +Ref: 369737113 +Node: 0 5a2737359 +Ref: history id898737443 +Ref: 36a737443 +Node: 0 5a1737539 +Ref: history id899737623 +Ref: 36b737623 +Node: 0 4a4738466 +Ref: history id900738550 +Ref: 36c738550 +Node: 0 4a3738878 +Ref: history id901738962 +Ref: 36d738962 +Node: 0 4a2739321 +Ref: history id902739405 +Ref: 36e739405 +Node: 0 4a1741512 +Ref: history id903741596 +Ref: 36f741596 +Node: 0 3a4741756 +Ref: history id904741840 +Ref: 370741840 +Node: 0 3a3742016 +Ref: history id905742100 +Ref: 371742100 +Node: 0 3a2742702 +Ref: history id906742786 +Ref: 372742786 +Node: 0 3a1743289 +Ref: history id907743359 +Ref: 373743359 +Node: Credits743412 +Ref: history credits743496 +Ref: 374743496 +Node: Index745380 + +End Tag Table + + +Local Variables: +coding: utf-8 +End: |