> -----Original Message----- > From: PJ Eby [mailto:p...@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 run > from (assuming Python is available). > > In order to work around this issue, you'd need to hardcode sys.path entries > 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 is > 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 importable, > but *are* executable. That's basically all that's needed to prevent importing > -- 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 the > script modules from being found in the sys.path[0] entry, but that's rather > 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 break > until that's fixed, and AFAIK there is *no* Windows Python that fixes this, > with the possible exception of 3.4 alpha, possibly a future alpha that hasn't > 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 version > of Python for Windows, in the sense that anybody who uses it will not yet be > 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 be > viable for future Python versions, and doesn't have the sys.path[0] problems. > I think you are going to have to keep .exe wrappers the default for all Python > 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 (https://bitbucket.org/pypa/setuptools/src/1.0b1/docs/easy_install.txt#cl-98 ). 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
