Hi Eric, On 11.11.12 22:45, Eric Snow wrote:

On Sun, Nov 11, 2012 at 1:53 PM, Christian Tismer mailto:tismer@stackless.com> wrote:

Once again on this:

With the introduction of module folders without __init__, it has become even harder to deduce a sensible project root Dir without relying on a global settings file. Abd as you probably agree, such files are a bad idea. Any global is bad, also in the file system.

Guido, this is another reason why I dislike the absence of __init__. :

Rhere is no longer an indicator that pretty clearly defines the root of my module heirarchy.

This came up during the discussions leading up to PEP 420, particularly regarding the impact on PEP 395. My thoughts at the time on addressing the problem:

http://mail.python.org/pipermail/import-sig/2012-March/000438.html

I do not quite understand what you want to propose: """ * there is no __init__.py in the current directory (in the case where there was one adjacent to the original module) * current directory is on sys.path * setup.py is in the current directory """ Are you saying that this is a way for me to get at the project root? And can this be done with a one-liner, or would I need a module for that, where the cat would bite its tail, because that module would not be found, easily? Please tell me in a simpler way what you think ;-) ciao - Chris -- Christian Tismer :^) mailto:tismer@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Hi Nick, Holger, this is a crazy fault of mine, see the end below. I wrote:

I have a project that has its root somewhere on my machine. This project has many folders and contains quite some modules.

There is a common root of the module tree, and I want to use - either absolute imports - relative imports with '.'

Problem:

- I want to run any module inside the heirarchy from the command-line

- this should work, regardless what my 'cwd' is

- this should work with or without virtualenv.

So far, things work fine with virtualenv, because sys.executable is in the project module tree.

Without virtualenv, this is not so. But I hate to make settings like PYTHONPATH, because these are not permanent. .

Question:

How should I define my project root dir in a unique way, without setting an environment variable? What is the lest intrusive way to spell that?

Reason:

I'd like to make things work correctly and unambigously when I call a script inside the module heirarchy. Things are not fixed: there exist many checkouts In the file system, and each should know where to search its home/root in the tree.

Is this elegantly possible to deduce from the actually executed script file?

Nick wrote: On 12.11.12 01:38, Nick Coghlan wrote:

The only way I know how to do it is to have my cwd set to the directory I want on sys.path, then use -m for script execution (using a separate shell session for anything where I want a different working directory).

I don't know of any way to handle a varying cwd without manipulating the path directly through either virtualenv or PYTHONPATH.

Cheers, Nick.

-- Sent from my phone, thus the relative brevity :)

Holger wrote (private message):

ich selbst nutze seit langer Zeit setuptools, genauer:

python setup.py develop

z.B. in pytest, execnet, tox. Das ist wie "setup.py install" nur dass das paket "inplace" installiert wird. Aber vermutlich kennst du das schon?!

So here is the crazy story: I'm actually using setuptools for my tiffany project with setup.py develop My real work is about the Pydica project which is a lot more. There I'm playing sys.path tricks, using virtualenv and the fact that I have full control over the local site-packages, and use some tricky .pth scripts to set everything up. But it needs virtualenv. Believe it or not: *I was not able to realize that all my problems are already solved* if I change Pydica and build a proper setup using setuptools. I needed to bug python-dev with this, and finally got the right hint from Holger Krekel who is absolutely right here - no point in playing tricks, because this is all solved. And Pydica is about to be prepared for PyPI, anyway. My blocker was probably that Pydica is very much in development, and I did not think right about it. The project does not need to be ready in order to use setuptools! My apologies, and many thanks again! This solved a Gordian Knot. It is great when people help me to leave a dead-lock in my brain :-) cheers - Chris -- Christian Tismer :^) mailto:tismer@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Hi Kristjan, does that mean that your scheme simply works, without any config step necessary after I did my checkout? This would in fact be an interesting alternative to Python setup.py develop but I'm not sure if this is the same scheme on windows and Os X. Getting this part right was rather tricky, and I fear this is still an issue. Right now I think to just force my users to run the install step, since it is quite accepted in general. Still, I'd love to see a way with no action needed at all: write yout your structure, and it works as-is. Seems to be impossible without tricks. Cheers - chris Sent from my Ei4Steve On Nov 15, 2012, at 10:17, Kristján Valur Jónsson wrote:

When python is being run from a compile environment, it detects this by looking for "Lib" folders in directories above the one containing the executable. (I always thought that this "special" execution mode, hardwired in, was a bit odd, and suggested that this could be made a function of pep405) Anyway, keeping your executable as part of the tree is the trick I use, and to make things nice I put right next to it: site.py sitecustomize.py

sitecustomize.py is where you would put the logic to set sys.path by walking up the hierarchy and finding the proper root. site.py is there to merely import sitecustomize.py, in case a site.py is not found in all the default places python looks.

K

...

-----Original Message----- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames.com@python.org] On Behalf Of Christian Tismer Sent: 11. nóvember 2012 20:31 To: python-dev@python.org Subject: [Python-Dev] Setting project home path the best way

Hi friends,

I have a project that has its root somewhere on my machine. This project has many folders and contains quite some modules.

There is a common root of the module tree, and I want to use - either absolute imports - relative imports with '.'

Problem:

- I want to run any module inside the heirarchy from the command-line

- this should work, regardless what my 'cwd' is

- this should work with or without virtualenv.

So far, things work fine with virtualenv, because sys.executable is in the project module tree.

Without virtualenv, this is not so. But I hate to make settings like PYTHONPATH, because these are not permanent. .

Question:

How should I define my project root dir in a unique way, without setting an environment variable? What is the lest intrusive way to spell that?

Reason:

I'd like to make things work correctly and unambigously when I call a script inside the module heirarchy. Things are not fixed: there exist many checkouts In the file system, and each should know where to search its home/root in the tree.

Is this elegantly possible to deduce from the actually executed script file?

Cheers - chris

Sent from my Ei4Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python- dev/kristjan%40ccpgames.com

Hi Daniel, no, I was not aware of this. I just read it up on http://sayspy.blogspot.de/2010/03/various-ways-of-distributing-python.html Yeah, thank you very much for this hint, very useful! ;-) cheers - Chris On 16.11.12 04:22, Daniel Holth wrote:

Are you familiar with executing directories having __main__.py as python scripts?

Daniel Holth

On Nov 15, 2012, at 4:43 PM, Christian Tismer wrote:

...

Hi Kristjan,

does that mean that your scheme simply works, without any config step necessary after I did my checkout? This would in fact be an interesting alternative to

Python setup.py develop

but I'm not sure if this is the same scheme on windows and Os X.

Getting this part right was rather tricky, and I fear this is still an issue.

Right now I think to just force my users to run the install step, since it is quite accepted in general.

Still, I'd love to see a way with no action needed at all: write yout your structure, and it works as-is. Seems to be impossible without tricks.

Cheers - chris

Sent from my Ei4Steve

On Nov 15, 2012, at 10:17, Kristján Valur Jónsson wrote:

...

When python is being run from a compile environment, it detects this by looking for "Lib" folders in directories above the one containing the executable. (I always thought that this "special" execution mode, hardwired in, was a bit odd, and suggested that this could be made a function of pep405) Anyway, keeping your executable as part of the tree is the trick I use, and to make things nice I put right next to it: site.py sitecustomize.py

sitecustomize.py is where you would put the logic to set sys.path by walking up the hierarchy and finding the proper root. site.py is there to merely import sitecustomize.py, in case a site.py is not found in all the default places python looks.

K

...

-----Original Message----- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames.com@python.org] On Behalf Of Christian Tismer Sent: 11. nóvember 2012 20:31 To: python-dev@python.org Subject: [Python-Dev] Setting project home path the best way

Hi friends,

I have a project that has its root somewhere on my machine. This project has many folders and contains quite some modules.

There is a common root of the module tree, and I want to use - either absolute imports - relative imports with '.'

Problem:

- I want to run any module inside the heirarchy from the command-line

- this should work, regardless what my 'cwd' is

- this should work with or without virtualenv.

So far, things work fine with virtualenv, because sys.executable is in the project module tree.

Without virtualenv, this is not so. But I hate to make settings like PYTHONPATH, because these are not permanent. .

Question:

How should I define my project root dir in a unique way, without setting an environment variable? What is the lest intrusive way to spell that?

Reason:

I'd like to make things work correctly and unambigously when I call a script inside the module heirarchy. Things are not fixed: there exist many checkouts In the file system, and each should know where to search its home/root in the tree.

Is this elegantly possible to deduce from the actually executed script file?

Cheers - chris

Sent from my Ei4Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python- dev/kristjan%40ccpgames.com

---

Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/dholth%40gmail.com

-- Christian Tismer :^) mailto:tismer@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Hello, Christian! On Fri, Nov 16, 2012 at 12:10:09AM +0100, Christian Tismer wrote:

I am bored of installing things. Bored of things that happen to not work for some minor reasons. Reasons that are not immediately obvious. Things that don't work because some special case was not handled. [a hot rant skipped]

Christian, I feel your pain. Everyone does, I am sure. Who among us never cursed that dratted computers? Those dirty rotten things that always hang due to bugs in drivers or whatnot, require constant cleaning, mending, upgrading, repairing, debugging. Condemn that magical mouse gestures, be cursed those magical incantations. Who in his normal mind would ever think of writing things like exec find . \( -type d \( -name CVS -o -name .svn -o -name .hg -o -name .git -o -path ./.mozilla/\*/Cache/\* -o -path ./tmp/\* \) -prune \) -o -type f -exec grep -I "$@" '{}' \+ 2>/dev/null ???!!! Unfortunately, there is no escape. Remember that classical book "The Mythical Man-Month"? Quoting Brooks, "There is no silver bullet". Things are becoming better but will never be absolutely perfect.

I would like to start a task force and some sprints about improving this situation. My goal is some unbreakable system of building blocks that are self-contained with no dependencies, that have a defined interface to talk to, and that know themselves completely by introspection.

They should not work because they happen to work around all known defects, but by design and control.

Whoever is interested to work with me on this is hereby honestly welcomed!

I am sorry to disappoint you but I don't believe this could work. Many single developers and teams -- small teams and huge companies, commercial and non-commercial -- have tried the approach and failed. Sometimes things work fine, some small projects look perfect... in isolation... But every now and then they failed, especially when combined. Try to connect a perfect project that measures distances in inches with another perfect project that that measures distances in centimeters -- and poof! your perfect satellite failed and dropped off of the sky. This will always happen. There is always pain for both users and developers. And still people are not afraid to create bigger and more complex projects -- and often they succeed. The only sane approach in my humble opinion is evolution. Similar to biological evolution. And biological evolution means huge birth rate, adapting and huge death rate. So write a lot of code, adapt it to your user's need and suffer a lot of pain -- code death and all that. Try to lessen user's pain, but never expect a piece of software to become perfect once, for all and forever. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

On Fri, Nov 16, 2012 at 05:34:37AM -0800, Eli Bendersky wrote:

...

exec find . \( -type d \( -name CVS -o -name .svn -o -name .hg -o -name .git -o -path ./.mozilla/\*/Cache/\* -o -path ./tmp/\* \) -prune \) -o -type f -exec grep -I "$@" '{}' \+ 2>/dev/null

Use pss ;-) [http://pypi.python.org/pypi/pss]

Hardly. I am proficient in find+grep. And pss is underdocumented. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

On Fri, Nov 16, 2012 at 01:20:17PM -0800, Eli Bendersky wrote:

On Fri, Nov 16, 2012 at 6:25 AM, Oleg Broytman wrote:

...

And pss is underdocumented.

Even reading https://bitbucket.org/eliben/pss/wiki/Usage#!usage-samplescombined

Compare your page with man find and man grep Compare amount of text, levels of details, number of options, examples... Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

On Fri, Nov 16, 2012 at 02:35:13PM -0800, Guido van Rossum wrote:

Oleg, this is inappropriate for python-dev. It's also a bit uncivilized and unkind.

Shame on me! Please, everyone, take my sincerest apology! I'm stopping now. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

On Fri, Nov 16, 2012 at 9:18 AM, Vinay Sajip wrote:

Eli Bendersky writes:

...

Use pss [http://pypi.python.org/pypi/pss]

How does it compare with grin? [http://pypi.python.org/pypi/grin]

On the face of it, they both do the same job.

They're quite similar. pss is more close to ack, in the sense that it knows how to identify files belonging to various categories/languages and lets you easily guide the search this way. And some others bells and whistles. But generally, both are better than using the horrible "find | xargs grep" incantation and all its variations. Eli

Yes! For many years I have been very frustrated by the install-centric nature of python. I am biased, of course, by the fact that I am developing an application where python is embedded, an application that needs to run out of the box. A developer may have many many versions (branches) of the application on his drive, and each needs to work separately. We have managed to isolate things, by patching python (and contributing that patch) to override the default library seach path (and ignore environment paths) when python is started up thogh the api. All well and good. But recently we have started in increasing amount to use external libraries and packages and we have been introduced to the dependency hell that is public python packages. In this install-centric world, developers reference huge external packages without a second thought, which cause large dependency trees. Using a simple tool may require whole HTTP frameworks to be downloaded. What is worse is when there are versioning conflicts between those dependencies. I don't have a well formed solution in mind, but I would see it desirable to have a way for someone to release his package with all its dependencies as a self-contained and isolated unit. E.g. if package foo.py relies on functionality from version 1.7 of bar.py, then that functionality could be bottled up for foo´s exclusive usage. Another package, baz.py, could then also make use of bar, but version 1.8. The two bar versions would be isolated. Perhaps this is just a pipedream. Even unpossible. But it doesn't harm to try to think about better ways to do things. K -----Original Message----- From: Christian Tismer [mailto:tismer@stackless.com] Sent: 15. nóvember 2012 23:10 To: Kristján Valur Jónsson Cc: python-dev@python.org Subject: Generally boared by installation (Re: [Python-Dev] Setting project home path the best way) Hi guys, I am bored of installing things. Bored of things that happen to not work for some minor reasons. Reasons that are not immediately obvious. Things that don't work because some special case was not handled. Things that compile for half an hour and then complain that something is not as expected. May it be a compiler, a library, a command like pip or easy-install, a system like macports or homebrew, virtualenv, whatsoever. These things are all great if they work. When they do not work, the user is in some real trouble. And he reads hundreds Of blogs and sites and emails, which all answer a bit of slightly related questions, but all in all - This is not how Python should work !! I am really bored and exhausted and annoyed by those packages which Pretend to make my life eadier, but they don't really. Something is really missing. I want something that is easy to use in all cases, also if it fails. Son't get me wrong, I like things like pip or virtualenv or homebrew. I just think they have to be rewritten completely. They have the wrong assumption that things work! The opposite should be the truth: by default, things go wrong. Correctness is very fragile. I am thinking of a better concept that is harder to break. I thin to design a setup tool that is much more checking itself and does not trust in any assumption. Scenario: After hours and hours, I find how to modify setup.py to function almost correctly for PySide. This was ridiculously hard to do! Settings for certain directories, included and stuff are not checked when they could be, but after compiling a lot of things! After a lot of tries and headaches, I find out that virtualenv barfs on a simple link like ./.Python, the executable, when switching from stock Python to a different (homebrew) version!! This was obviously never tested well, so it frustrates me quite a lot. I could fill a huge list full of complaints like that if I had time. But I don't. Instead, I think installation scripts are generally still wrong by concept today and need to be written in a different way. I would like to start a task force and some sprints about improving this situation. My goal is some unbreakable system of building blocks that are self-contained with no dependencies, that have a defined interface to talk to, and that know themselves completely by introspection. They should not work because they happen to work around all known defects, but by design and control. Whoever is interested to work with me on this is hereby honestly welcomed! Cheers - chris Sent from my Ei4Steve On Nov 15, 2012, at 10:17, Kristján Valur Jónsson wrote:

When python is being run from a compile environment, it detects this by looking for "Lib" folders in directories above the one containing the executable. (I always thought that this "special" execution mode, hardwired in, was a bit odd, and suggested that this could be made a function of pep405) Anyway, keeping your executable as part of the tree is the trick I use, and to make things nice I put right next to it: site.py sitecustomize.py

sitecustomize.py is where you would put the logic to set sys.path by walking up the hierarchy and finding the proper root. site.py is there to merely import sitecustomize.py, in case a site.py is not found in all the default places python looks.

K

...

-----Original Message----- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames.com@python.org] On Behalf Of Christian bounces+Tismer Sent: 11. nóvember 2012 20:31 To: python-dev@python.org Subject: [Python-Dev] Setting project home path the best way

Hi friends,

I have a project that has its root somewhere on my machine. This project has many folders and contains quite some modules.

There is a common root of the module tree, and I want to use - either absolute imports - relative imports with '.'

Problem:

- I want to run any module inside the heirarchy from the command-line

- this should work, regardless what my 'cwd' is

- this should work with or without virtualenv.

So far, things work fine with virtualenv, because sys.executable is in the project module tree.

Without virtualenv, this is not so. But I hate to make settings like PYTHONPATH, because these are not permanent. .

Question:

How should I define my project root dir in a unique way, without setting an environment variable? What is the lest intrusive way to spell that?

Reason:

I'd like to make things work correctly and unambigously when I call a script inside the module heirarchy. Things are not fixed: there exist many checkouts In the file system, and each should know where to search its home/root in the tree.

Is this elegantly possible to deduce from the actually executed script file?

Cheers - chris

Sent from my Ei4Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python- dev/kristjan%40ccpgames.com

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? K From: Nick Coghlan [mailto:ncoghlan@gmail.com] Sent: 18. nóvember 2012 11:25 To: Kristján Valur Jónsson Cc: Christian Tismer; python-dev@python.org Subject: Re: [Python-Dev] Generally boared by installation (Re: Setting project home path the best way) Easily bundling dependencies is a key principle behind the ability to execute directories and zipfiles that contain a top level __main__.py file that was added back in 2.6 (although the zipfile version doesn't play nicely with extension modules). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.commailto:ncoghlan@gmail.com | Brisbane, Australia

On 20.11.12 12:39, Nick Coghlan wrote:

On Tue, Nov 20, 2012 at 7:06 PM, Kristján Valur Jónsson mailto:kristjan@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. ;-) Is the issue tracker permanent enough to reference it? 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? ciao - chris -- Christian Tismer :^) mailto:tismer@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

On Tue, Nov 20, 2012 at 9:44 AM, Nick Coghlan wrote:

On Tue, Nov 20, 2012 at 11:45 PM, Christian Tismer 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@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

On Thu, Nov 22, 2012 at 9:44 PM, Kristján Valur Jónsson < kristjan@ccpgames.com> wrote:

Where in the tracker? I tried searching but didn’t find it.

This one: http://bugs.python.org/issue13475 This and the issue about being able to configure coverage.py cleanly in subprocesses (http://bugs.python.org/issue14803) are the two issues which have got me thinking about the interpreter startup and configuration process in general lately. Both would add *more* complexity to an already complicated and hard to follow initialisation sequence, so I now think we should be look at opportunities for rationalisation *first*, before we make things even messier. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Tue, Nov 27, 2012 at 9:19 PM, Eric Snow wrote:

On Thu, Nov 22, 2012 at 5:09 AM, Nick Coghlan wrote:

...

On Thu, Nov 22, 2012 at 9:44 PM, Kristján Valur Jónsson wrote:

...

Where in the tracker? I tried searching but didn’t find it.

This one: http://bugs.python.org/issue13475

This and the issue about being able to configure coverage.py cleanly in subprocesses (http://bugs.python.org/issue14803) are the two issues which have got me thinking about the interpreter startup and configuration process in general lately. Both would add *more* complexity to an already complicated and hard to follow initialisation sequence, so I now think we should be look at opportunities for rationalisation *first*, before we make things even messier.

There's also http://bugs.python.org/issue15716 ("Ability to specify the PYTHONPATH via a command line flag").

-eric

I knew there was one more: http://bugs.python.org/issue16499 ("CLI option for isolated mode"). -eric