[Python-Dev] Generally boared by installation (Re: Setting project home path the best way)

[Daniel Holth]

On Tue, Nov 20, 2012 at 9:44 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Tue, Nov 20, 2012 at 11:45 PM, Christian Tismer <tismer at stackless.com>wrote:
>
>>  On 20.11.12 12:39, Nick Coghlan wrote:
>>
>> On Tue, Nov 20, 2012 at 7:06 PM, Kristján Valur Jónsson <
>> kristjan at ccpgames.com> wrote:
>>
>>>  I’m intrigued.  I thought this was merely so that one could do
>>>
>>> python –m mypackage.mysubpackage
>>>
>>> Can you refer me to the rationale and discussion about this feature?
>>>
>>
>> It was part of a fairly long progression in changes to the command line
>> execution support :)
>>
>> Top level package execution with -m came first in 2.4, arbitrary package
>> execution for -m arrived in 2.5 (along with the runpy module), directory
>> and zipfile execution (by supplying a valid sys.path entry as the "script"
>> command line argument) was added in 2.6/3.0, and finally officially
>> supported package execution via -m only arrived in 2.7 and 3.1 (a broken
>> version of the last accidentally existed in 2.5, but that was just a
>> mistake that arose when merging the import emulations in runpy and pkgutil,
>> and had a side effect that violated at least one of the import system
>> invariants).
>>
>> In the specific case of directory and zipfile execution, discussion
>> happened on the tracker: http://bugs.python.org/issue1739468
>>
>> It was never brought up on python-dev because Guido was participating
>> directly in the tracker discussion. Unfortunately, we then also forgot to
>> mention it in the original version of the 2.6 What's New doc, so the vast
>> majority of people missed the addition :(
>>
>>
>> Hi Nick,
>>
>> thank you very much for this story and the link to the issue tracker!
>> A very good move for Python which is really not mentioned enough
>> to make people more aware of a great feature.
>>
>> I think part of this discussion should get a more prominent place
>> for gems that can be found without knowing what to search. ;-)
>>
>
> Technically, that's the "using" guide:
> http://docs.python.org/2/using/cmdline.html#interface-options (see the
> explanation of what's executable under the "<script>" tag)
>
> I also wrote up a summary last year on my blog:
> http://www.boredomandlaziness.org/2011/03/what-is-python-script.html
>
> (The main change since that post is that the Python launcher brings
> shebang line support to Windows, although I haven't checked if it works
> properly with prefixed zip files)
>
> Maybe I should plan to sign up to present an updated version of my PyCon
> AU 2010 "What is a Python script?" lightning talk at PyCon US 2013 :)
>
>
>>  Is the issue tracker permanent enough to reference it?
>>
>
> I've been referencing that particular issue for years now, so I certainly
> think so :)
>
>
>>  Maybe there could be some auxiliary info page with proper keywords
>> that collects links to relevant discussions like this.
>> Do we have such a thing already?
>>
>
> I've sometimes thought it may be a good idea to split out a separate "What
> is a Python script?" section in the using guide, separate from the existing
> descriptions under the interpreter options. I've never tried to figure out
> the details of how that would actually work, though.
>

The wheel projects' own wheel file (a zip file) takes advantage of this
feature in its own way:

python wheel-0.14.0-py2.py3-none-any.whl/wheel

Python looks inside the /wheel directory of the zip file, finds
__main__.py, and executes it; the archive can be used to install itself or
any other wheel file. (There is no __main__.py at the root because the
wheel design would install that __main__.py into the root of site-packages).


This underutilized feature of executing directories with __main__.py is
very useful for implementing Python applications instead of just libraries.

It might be interesting to define a "wheels" format which would be a bunch
of unpacked wheel files and a __main__.py like:

__main__.py
package1-x86.whl/...
package1-armel.whl/...
package2-noarch.whl/

__main__.py would add the appropriate packages to PYTHONPATH based on the
architecture, unpack dll's pkg_resources style, and run the program.


There is some activity in the tracker about adding the missing "add this to
PYTHONPATH" / "isolate self from the environment" command line arguments to
Python.

Daniel Holth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121120/d9b97357/attachment.html>