New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support external launchers using native scripts #60

Closed
bb-migration opened this Issue Aug 6, 2013 · 5 comments

Comments

Projects
None yet
1 participant
@bb-migration

bb-migration commented Aug 6, 2013

Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)


With the inception of Vinay Sajip's pylauncher and its defacto inclusion in Python 3.3 (with backward-support for other Python versions), the need for Setuptools to provide launcher executables in these environments is now diminished.

Setuptools should now be able to create simple '.py' scripts, exactly as it does on Unix except with the additional .py or .pyw extension.

One necessity to make this work smoothly will be for .py and .pyw to be registered with the pylauncher and for those extensions to be present in PATHEXT. Perhaps Setuptools can help facilitate that support.

While I believe leveraging the pylauncher is the right thing to do, it will need to be done with care and a smooth transition planned. Here's what I have in mind:

  1. Refactor the code to allow for two modes (exe launchers and native .py launchers).
  2. Initially enable the native-only launcher support by way of an environment variable, allowing users to adopt the future behavior voluntarily and not by default.
  3. After some period of exposure and addressing any issues, deprecate the exe launchers and make native .py launchers the default. Allow exe support to be enabled by a different environment variable.
  4. Consider removing exe support.

@bb-migration

This comment has been minimized.

bb-migration commented Aug 6, 2013

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


In these changes, I've done some refactoring to enable selecting of another technique for generating the launcher. I've also drafted this diff to enable the future support if the SETUPTOOLS_SUPPRESS_EXE_LAUNCHERS environment variable is present. I'll be trying out this technique myself, but I invite comments or others to give it a try.

@bb-migration

This comment has been minimized.

bb-migration commented Aug 10, 2013

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


In d3bbcc491d16, I've committed the experimental support for pylauncher. Instead of the variable name mentioned above, I used instead SETUPTOOLS_USE_PYLAUNCHER to more directly reference the intended replacement. This opt-in feature will be included in the upcoming 1.0 release.

@bb-migration

This comment has been minimized.

bb-migration commented Aug 15, 2013

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Due to issues with using .py extension in scripts (that indicates an importable python module), I'll be using another extension (currently .pya, python application) to distinguish a non-importable script from an importable module.

I've added a UserWarning if the SETUPTOOLS_USE_PYLAUNCHER is used but PATHEXT doesn't include the relevant extensions.

@bb-migration

This comment has been minimized.

bb-migration commented Aug 15, 2013

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Based on some discussion, the removal of executable launchers may be a long way off, so I'm narrowing the focus of this issue to focus on adding support for an external launcher.

@bb-migration

This comment has been minimized.

bb-migration commented Aug 25, 2013

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


The latest 1.0 release includes support for native scripts launched by pylauncher or similar. See the release notes for details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment