Differences between revisions 1 and 7 (spanning 6 versions)
Revision 1 as of 2010-04-11 16:08:59
Size: 2012
Editor: 101
Comment: New proposal: Distributions that run from a checkout
Revision 7 as of 2011-03-28 21:12:07
Size: 2078
Editor: sp137-2-89-86-29-40
Comment: Add issues
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
Give users a way to run code from a version control system checkout without building or installing it. Give Python developers using distutils2 a way to import modules and packages from a source tree without building or installing it.
Line 7: Line 7:
People want to import their modules or run their scripts to try them while developing without reinstalling them constantly or mucking with import paths. People want to import their modules to try them while developing without reinstalling them constantly or mucking with import paths. The code will most of the time come from a version-controlled directory or an unpacked archive.
Line 9: Line 9:
== Requirements/Ideas ==
Provide a command that makes a code checkout available for import and use without requiring to rebuild or reinstall it when the files change.
This proposal does not talk about VCS integration (for example building distributions from branches or tags).
Line 12: Line 11:
The command name could be in the bdist family (bdist_checkout) or be something new like vdist (virtual dist), ddist (development dist), cdist (checkout dist) or something better. Open issues: how to enable scripts provided by the distribution; how to make the dist-info directory available to pkgutil.
Line 14: Line 13:
When the code includes C extensions, users will need to run the build_ext command, but they will not have to run cdist again. With pure Python code, there will be no command to run to make the new code available as distribution. == Detailed Plan ==
Provide a command that makes code in an arbitrary directory available for import and use without requiring to rebuild or reinstall it when the files change.
Line 16: Line 16:
The mechanism for enabling such a checkout distribution would be as simple as adding a .pth file on the user’s site-package directory (overridable with an option). The mechanism for enabling such a devel installation would be as simple as adding a .pth file on the user’s site-package directory (overridable with an option).
Line 18: Line 18:
To stop using a checkout distribution, a command to remove the .pth file has to be provided, perhaps as an option to cdist. Since this is a type of installation, the feature should be implemented as an option to the install command. More specifically, since data, headers or scripts are not handled, an option to the install_lib command. This option would imply --skip-build.
Line 20: Line 20:
Alternative idea: Implement this feature as “install --develop” and use uninstall to remove the .pth file. --develop would imply --skip-build. When the code includes C extensions, users will need to run build_ext --inplace, but they will not have to run install_lib --link-only again. With pure Python code, there will be no command to run to make the new code available as distribution.
Line 22: Line 22:
We may take a leaf from Buildutils’ book and use a name that conveys the meaning of “making this distribution available”, i.e. build and pseudo-install at the same time: use, activate, deploy... An option to the uninstall command would be used to remove the .pth file.
Line 25: Line 25:
 1. [[http://peak.telecommunity.com/DevCenter/EasyInstall|Setuptools’ develop command]]  1. [[http://peak.telecommunity.com/DevCenter/setuptools#development-mode|Setuptools’ develop command]]
Line 27: Line 27:
 3. Issue:8668

Abstract

Give Python developers using distutils2 a way to import modules and packages from a source tree without building or installing it.

Rationale

People want to import their modules to try them while developing without reinstalling them constantly or mucking with import paths. The code will most of the time come from a version-controlled directory or an unpacked archive.

This proposal does not talk about VCS integration (for example building distributions from branches or tags).

Open issues: how to enable scripts provided by the distribution; how to make the dist-info directory available to pkgutil.

Detailed Plan

Provide a command that makes code in an arbitrary directory available for import and use without requiring to rebuild or reinstall it when the files change.

The mechanism for enabling such a devel installation would be as simple as adding a .pth file on the user’s site-package directory (overridable with an option).

Since this is a type of installation, the feature should be implemented as an option to the install command. More specifically, since data, headers or scripts are not handled, an option to the install_lib command. This option would imply --skip-build.

When the code includes C extensions, users will need to run build_ext --inplace, but they will not have to run install_lib --link-only again. With pure Python code, there will be no command to run to make the new code available as distribution.

An option to the uninstall command would be used to remove the .pth file.

References

  1. Setuptools’ develop command

  2. Buildutils’ use command

  3. 8668

I, ÉricAraujo, make this document available to anyone for all purposes and intents, including edition and distribution, in the limits allowed by their jurisdictions. (There is no such thing as “placing in the public domain”.)

Distutils/Proposals/DevelopmentDistributions (last edited 2011-03-28 21:12:07 by sp137-2-89-86-29-40)

Unable to edit the page? See the FrontPage for instructions.