Hello, On behalf of the distutils-SIG, I'd like to propose PEP 376 for inclusion. This PEP is about defining a standard for installed Python projects. http://www.python.org/dev/peps/pep-0376/ It was created : - to allow interoperability among all package managers. - to provide a set of APIs in the stdlib to know what's installed (in pkgutil) - to provide a basic *uninstaller* feature in the distutils2 project. It is very similar to the retired PEP 262, but closer to the standard the Setuptools project have created, which is quite used in the community. Calendar-wise, I'd love to see it accepted for 2.7 but it might be too late to finish discussing it (2.7b1 is due in a few days). So I guess the next target will be Python 3.2. One topic has been ignored on purpose in this PEP : how to describe in a detailed way the resources file a project contains, and how they should be installed on a FHS-compliant system (like, a configuration file should go in /etc and such things) We are currently focusing our discussion efforts on the resource files (see the summary work so far here : http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst) and we will produce another PEP for that, that will not interfer with PEP 376. Regards Tarek -- Tarek Ziadé | http://ziade.org
First: thank you distutils-sig, and especially Tarek, for spearheading this effort! I'm particularly excited about the "Distribution" object that this PEP specifies. I've been waiting for a long time to be able to load an object describing a distribution, rather than running setup.py and hoping that it mutated the right state! On Apr 1, 2010, at 5:51 PM, Tarek Ziadé wrote:
- to provide a basic *uninstaller* feature in the distutils2 project.
Second: It seems to me that a major missing feature in the PEP is the ability to run some code during installation and uninstallation, especially since it is so easy to run ad-hoc code in setup.py with no way of un-doing what it did. Twisted's plugin system needs this in order to update a plugin index so that plugins can be quickly scanned without being loaded. However, since this is arguably a design flaw in Twisted that should be fixed, I should point out there are other systems that have similar requirements, which are considerably less mutable: COM registration, other registry keys, adding / removing crontab entries, windows services, start menu items, XDG desktop / menu entries, login items, edits to the user's shell configuration, etc. The list goes on and on. I appreciate the "installer marker" feature, since that will at least allow easy_install or pip or something like them to implement this feature with minimal risk of being broken by built-in package management tools, but it seems like such a simple addition that it would be a shame to leave it out. If we could get rid of setup.py entirely so that it wasn't so easy to run ad-hoc stuff during install, I would be happy to leave it to them :). I realize that there are a lot of potential complexities that might creep into the process of determining the execution environment for the code in question, but I personally think it would be good enough to say "You'd better be darn sure to encode all of the run-time state that you need into your own script, or it might break." Third: The PEP is silent on what happens to files whose hash _has_ changed from its install-time value. I guess the implied plan would be to leave them in place. However, this may have nasty side-effects; for example, if the files are test files, then they might be loaded during test discovery, and report exceptions since the code that they're testing has been removed. My suggestion would be to have a specific "quarantine" area where the distutils uninstaller can put modified files that would have been removed as part of a specific distribution, so they aren't still present on PYTHONPATH. I can also think of reasons why you might not want to do this, but either way, the consequence of changing an installed file should be made explicitly clear in the PEP: if they are to be left in place, it should emphasize that point. Finally, one minor bit of bikeshedding, of which I promise to say nothing more if there is not unanimous agreement: I dislike the use of "get_" in function names, since it adds more characters without really adding more information. get_file_users is particularly bad, since it makes me think that it's going to return a list of processes with a file open, or a list of UIDs or something like that. I suggest these names instead: get_distributions() -> active_distributions() get_distribution(name) -> active_distribution_named(name) get_file_users(path) -> distributions_using_path(path) where "active" means "on the current sys.path and thereby accessible by 'import'". This naming would also make the behavior of get_file_users a bit clearer; if the intention is to return only active, loadable distributions (you don't want to be able to use get_file_users to inspect other Python installations or virtualenvs) it could be called active_distributions_using_path. Thanks again to the PEP's author and many contributors, -glyph
On Fri, Apr 2, 2010 at 1:56 AM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
First: thank you distutils-sig, and especially Tarek, for spearheading this effort!
Thanks :)
I'm particularly excited about the "Distribution" object that this PEP specifies. I've been waiting for a long time to be able to load an object describing a distribution, rather than running setup.py and hoping that it mutated the right state!
Notice that this Distribution class will work with installed distributions, where the info where built by running setup.py. As opposed to distritbutions that are not yet installed where these infos are still hidden in setup.py. Although we are currently working in distutils2 to get rid of setup.py and have a pure static metadata file.
On Apr 1, 2010, at 5:51 PM, Tarek Ziadé wrote:
- to provide a basic *uninstaller* feature in the distutils2 project.
Second: It seems to me that a major missing feature in the PEP is the ability to run some code during installation and uninstallation, especially since it is so easy to run ad-hoc code in setup.py with no way of un-doing what it did.
That was a feature request for distutils: install/removal hooks like what RPM or the msi installer offers. I think this could be done in distutils2 no matter what happens to the PEP. I am adding this in the bug tracker.
Third: The PEP is silent on what happens to files whose hash _has_ changed from its install-time value. I guess the implied plan would be to leave them in place. However, this may have nasty side-effects; for example, if the files are test files, then they might be loaded during test discovery, and report exceptions since the code that they're testing has been removed. My suggestion would be to have a specific "quarantine" area where the distutils uninstaller can put modified files that would have been removed as part of a specific distribution, so they aren't still present on PYTHONPATH. I can also think of reasons why you might not want to do this, but either way, the consequence of changing an installed file should be made explicitly clear in the PEP: if they are to be left in place, it should emphasize that point.
The strategy about what should be done with modified files upon uninstallation is up to the implementation I guess. But the PEP should mention what Distutils2 basic uninstall function should do. The quarantine strategy sounds like a great idea. I propose to add this in the PEP in the implementation details section, and say in the specs that it's up to the implementation to decide.
Finally, one minor bit of bikeshedding, of which I promise to say nothing more if there is not unanimous agreement: I dislike the use of "get_" in function names, since it adds more characters without really adding more information. get_file_users is particularly bad, since it makes me think that it's going to return a list of processes with a file open, or a list of UIDs or something like that. I suggest these names instead: get_distributions() -> active_distributions() get_distribution(name) -> active_distribution_named(name) get_file_users(path) -> distributions_using_path(path) where "active" means "on the current sys.path and thereby accessible by 'import'".
"active" sounds superfluous too I think, since all distributions that are found *are* active. So it could be "distributions()". But I am not comfortable with this single word because it sounds to me like a sequence object rather than a function. But that might be just me..
This naming would also make the behavior of get_file_users a bit clearer; if the intention is to return only active, loadable distributions (you don't want to be able to use get_file_users to inspect other Python installations or virtualenvs) it could be called active_distributions_using_path.
+1 on distributions_using_path()
Thanks again to the PEP's author and many contributors,
Thanks for the feedback ! -- Tarek Ziadé | http://ziade.org
participants (2)
-
Glyph Lefkowitz
-
Tarek Ziadé