upstream/mercurial-mirror Files · contrib/packaging/inno/readme.rst

errors: catch urllib errors specifically instead of using safehasattr()...

errors: catch urllib errors specifically instead of using safehasattr() Before this patch, we would catch `IOError` and `OSError` and check if the instance had a `.code` member (indicates `HTTPError`) or a `.reason` member (indicates the more generic `URLError`). It seems to me that can simply catch those exception specifically instead, so that's what this code does. The existing code is from (commands: report http exceptions nicely, 2005-06-17), so I suspect it's just that there was no `urllib2` (where `URLError` lives) back then. The old code mentioned `SSLError` in a comment. The new code does *not* try to catch that. The documentation for `ssl.SSLError` says that it has a `.reason` property, but `python -c 'import ssl; print(dir(ssl.SSLError("foo", Exception("bar"))))` doesn't mention that property on either Python 2 or Python 3 on my system. It also seems that `sslutil` is pretty careful about converting `ssl.SSLError` to `error.Abort`. It also is carefult to not assume that instances of the exception have a `.reason`. So I at least don't want to catch `ssl.SSLError` and handle it the same way as `URLError` because that would likely result in a crash. I also wonder if we don't need to handle it at all (because `sslutil` might handle all the cases). It's now early in the release cycle, so perhaps we can just see how it goes? Differential Revision: https://phab.mercurial-scm.org/D9318

Gregory Szorc - - Load All Authors

File last commit:

r43819:f2ef4f93 default


                r46442:ae00e170

default

Download file

             readme.rst
        
                    61 lines
            
             | 2.2 KiB
            
                | text/x-rst
            
             |
                RstLexer
            
             / contrib / packaging / inno / readme.rst
          
                    History
                
                 |
                  Source
                 | Raw
                 |Copy content
                 |Copy permalink

        Gregory Szorc
    
inno: script to automate building Inno installer...

              r42019
            
      Requirements

      ============

      Building the Inno installer requires a Windows machine.

      The following system dependencies must be installed:

      * Python 2.7 (download from https://www.python.org/downloads/)

      * Microsoft Visual C++ Compiler for Python 2.7

        (https://www.microsoft.com/en-us/download/details.aspx?id=44266)

      * Inno Setup (http://jrsoftware.org/isdl.php) version 5.4 or newer.

        Be sure to install the optional Inno Setup Preprocessor feature,

        which is required.

        Gregory Szorc
    
packaging: consolidate CLI functionality into packaging.py...

              r43913
            
      * Python 3.5+ (to run the ``packaging.py`` script)

        Gregory Szorc
    
inno: script to automate building Inno installer...

              r42019
            
      Building

      ========

        Gregory Szorc
    
packaging: consolidate CLI functionality into packaging.py...

              r43913
            
      The ``packaging.py`` script automates the process of producing an

        Gregory Szorc
    
inno: script to automate building Inno installer...

              r42019
            
      Inno installer. It manages fetching and configuring the

      non-system dependencies (such as py2exe, gettext, and various

      Python packages).

      The script requires an activated ``Visual C++ 2008`` command prompt.

      A shortcut to such a prompt was installed with ``Microsoft Visual C++

      Compiler for Python 2.7``. From your Start Menu, look for

      ``Microsoft Visual C++ Compiler Package for Python 2.7`` then launch

      either ``Visual C++ 2008 32-bit Command Prompt`` or

      ``Visual C++ 2008 64-bit Command Prompt``.

      From the prompt, change to the Mercurial source directory. e.g.

      ``cd c:\src\hg``.

        Gregory Szorc
    
packaging: consolidate CLI functionality into packaging.py...

              r43913
            
      Next, invoke ``packaging.py`` to produce an Inno installer. You will

        Matt Harbison
    
inno: correct the path display in a literal block of the readme...

              r42813
            
      need to supply the path to the Python interpreter to use.::

        Gregory Szorc
    
inno: script to automate building Inno installer...

              r42019
            
        Gregory Szorc
    
packaging: consolidate CLI functionality into packaging.py...

              r43913
            
         $ python3.exe contrib\packaging\packaging.py \

             inno --python c:\python27\python.exe

        Gregory Szorc
    
inno: script to automate building Inno installer...

              r42019
            
      .. note::

         The script validates that the Visual C++ environment is

         active and that the architecture of the specified Python

         interpreter matches the Visual C++ environment and errors

         if not.

      If everything runs as intended, dependencies will be fetched and

      configured into the ``build`` sub-directory, Mercurial will be built,

      and an installer placed in the ``dist`` sub-directory. The final

      line of output should print the name of the generated installer.

        Gregory Szorc
    
packaging: consolidate CLI functionality into packaging.py...

              r43913
            
      Additional options may be configured. Run

      ``packaging.py inno --help`` to see a list of program flags.

        Gregory Szorc
    
inno: script to automate building Inno installer...

              r42019
            
      MinGW

      =====

      It is theoretically possible to generate an installer that uses

        Gregory Szorc
    
packaging: consolidate CLI functionality into packaging.py...

              r43913
            
      MinGW. This isn't well tested and ``packaging.py`` and may properly

        Gregory Szorc
    
inno: script to automate building Inno installer...

              r42019
            
      support it. See old versions of this file in version control for

      potentially useful hints as to how to achieve this.

	Site-wide shortcuts
/	Use quick search box
g h	Goto home page
g g	Goto my private gists page
g G	Goto my public gists page
g 0-9	Goto bookmarked items from 0-9
n r	New repository page
n g	New gist page

	Repositories
g s	Goto summary page
g c	Goto changelog page
g f	Goto files page
g F	Goto files page with file search activated
g p	Goto pull requests page
g o	Goto repository settings
g O	Goto repository access permissions settings
t s	Toggle sidebar on some pages

Gregory Szorc inno: script to automate building Inno installer...	r42019	Requirements
		============

		Building the Inno installer requires a Windows machine.

		The following system dependencies must be installed:

		* Python 2.7 (download from https://www.python.org/downloads/)
		* Microsoft Visual C++ Compiler for Python 2.7
		(https://www.microsoft.com/en-us/download/details.aspx?id=44266)
		* Inno Setup (http://jrsoftware.org/isdl.php) version 5.4 or newer.
		Be sure to install the optional Inno Setup Preprocessor feature,
		which is required.
Gregory Szorc packaging: consolidate CLI functionality into packaging.py...	r43913	* Python 3.5+ (to run the ``packaging.py`` script)
Gregory Szorc inno: script to automate building Inno installer...	r42019
		Building
		========

Gregory Szorc packaging: consolidate CLI functionality into packaging.py...	r43913	The ``packaging.py`` script automates the process of producing an
Gregory Szorc inno: script to automate building Inno installer...	r42019	Inno installer. It manages fetching and configuring the
		non-system dependencies (such as py2exe, gettext, and various
		Python packages).

		The script requires an activated ``Visual C++ 2008`` command prompt.
		A shortcut to such a prompt was installed with ``Microsoft Visual C++
		Compiler for Python 2.7``. From your Start Menu, look for
		``Microsoft Visual C++ Compiler Package for Python 2.7`` then launch
		either ``Visual C++ 2008 32-bit Command Prompt`` or
		``Visual C++ 2008 64-bit Command Prompt``.

		From the prompt, change to the Mercurial source directory. e.g.
		``cd c:\src\hg``.

Gregory Szorc packaging: consolidate CLI functionality into packaging.py...	r43913	Next, invoke ``packaging.py`` to produce an Inno installer. You will
Matt Harbison inno: correct the path display in a literal block of the readme...	r42813	need to supply the path to the Python interpreter to use.::
Gregory Szorc inno: script to automate building Inno installer...	r42019
Gregory Szorc packaging: consolidate CLI functionality into packaging.py...	r43913	$ python3.exe contrib\packaging\packaging.py \
		inno --python c:\python27\python.exe
Gregory Szorc inno: script to automate building Inno installer...	r42019
		.. note::

		The script validates that the Visual C++ environment is
		active and that the architecture of the specified Python
		interpreter matches the Visual C++ environment and errors
		if not.

		If everything runs as intended, dependencies will be fetched and
		configured into the ``build`` sub-directory, Mercurial will be built,
		and an installer placed in the ``dist`` sub-directory. The final
		line of output should print the name of the generated installer.

Gregory Szorc packaging: consolidate CLI functionality into packaging.py...	r43913	Additional options may be configured. Run
		``packaging.py inno --help`` to see a list of program flags.
Gregory Szorc inno: script to automate building Inno installer...	r42019
		MinGW
		=====

		It is theoretically possible to generate an installer that uses
Gregory Szorc packaging: consolidate CLI functionality into packaging.py...	r43913	MinGW. This isn't well tested and ``packaging.py`` and may properly
Gregory Szorc inno: script to automate building Inno installer...	r42019	support it. See old versions of this file in version control for
		potentially useful hints as to how to achieve this.