[Distutils] How to handle launcher script importability?

Jason R. Coombs jaraco at jaraco.com
Sun Aug 11 19:58:26 CEST 2013

> -----Original Message-----
> From: PJ Eby [mailto:pje at telecommunity.com]
> Sent: Sunday, 11 August, 2013 12:17
> Here's another problem with #1: you will break single-directory standalone
> portable app installs, where you use "easy_install -mad somedir" to
install all
> of an app's dependencies to a single directory that the app can then be
> from (assuming Python is available).
> In order to work around this issue, you'd need to hardcode sys.path
> for the dependencies, or do something else more complicated in order to
> ensure that dependency resolution will pick up the adjacent distributions
> before searching anything else on sys.path.
> > Third, is it possible some users are depending on the presence of
> > sys.path[0]
> Absolutely.  It's a documented feature of Python that the script directory
> always first on sys.path, so that you can provide modules and packages
> adjacent to it.  That's how portable app installs work with easy_install.

All good points to be considered. Thanks.
> May I suggest an option 5 instead?  Use the new .pyz (or .pyzw for non-
> console apps) as a zipped Python application.  .pyz files aren't
> but *are* executable.  That's basically all that's needed to prevent
> -- a file extension that's launchable but not importable.

This sounds like a suitable idea, but as you mention in a subsequent
message, this format has issues with sys.path assumptions as well. In this
case, I'm inclined to suggest yet another option (7) - create another
extension to specifically represent executable but not importable scripts,
perhaps .pys/.pysw (or .pycs/.pygs to more closely match console script and
gui script).

It sounds as if there is a fundamental need for Python to define an
extension that distinguishes a script from a module.
> (There's also an option 6, which is to use import system hooks to prevent
> script modules from being found in the sys.path[0] entry, but that's
> hairier.)

Agreed, this sounds like it has its own subtle challenges.

> Using option 5 means the feature can only work with versions of Python on
> Windows that install the necessary PATHEXT support to allow that extension
> to work, but you're kind of limited to that anyway, because by default .py
> files aren't findable via PATH on Windows.
> Your post doesn't make it clear whether you're aware of that, btw:
> IIUC, on most Windows setups, executing a .py file via PATH doesn't work
> unless you've set up PATHEXT to include .py.  So your feature's going to
> until that's fixed, and AFAIK there is *no* Windows Python that fixes
> with the possible exception of 3.4 alpha, possibly a future alpha that
> been released yet, because last I saw on Python-Dev it was still being
> discussed *how* to update PATHEXT safely from the installer.
> In short: dropping .exe wrappers is not supportable on *any* current
> of Python for Windows, in the sense that anybody who uses it will not yet
> able to execute the scripts if they are currently doing so via PATH (and
> haven't manually fixed their PATHEXT).  (This was one of the main reasons
> for using .exe wrappers in the first
> place.)
> The .pyz approach of course has the same drawback, but at least it should
> viable for future Python versions, and doesn't have the sys.path[0]
> I think you are going to have to keep .exe wrappers the default for all
> versions < 3.4.

I am aware of the PATHEXT factor. I personally add .py and .pyw to the
PATHEXT (for all users) on my systems, so I was unsure if Python 3.3 did add
those or if pylauncher would add them (if installed separately). I was
_hoping_ that was the case, but it sounds like it is not. I did include in
the documentation notes about this requirement

I do want to explore the possibility of setuptools facilitating this
configuration such that it's easy for a Windows user to enable these
settings even if Python does not.

The nice thing about (7) is it would define an extension that's specifically
meant to be executable, so would be an obvious (and potentially less
controversial) choice to include in PATHEXT.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6572 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130811/56809015/attachment.bin>

More information about the Distutils-SIG mailing list