Re: [Distutils] [Python-Dev] shal we redefine "module" and "package"?
On 10:53 pm, steve@holdenweb.com wrote:
zooko wrote:
Unfortunately these answers aren't quite right. A "package" is actually a directory containing an __init__.py file, and a distribution is actually what you think of when you say "package" -- a reusable package of Python code that you can, for example, get from the Python package index.
The fact that the Python "package" index is a place where you get "distributions" does seem a bit weird to me, but this is not necessarily a problem that can be fixed. Ambiguity is part of human language. Perhaps suggest transliterations of these terms for talking about python in lojban? :)
1. A "module" shall henceforth be the name for either a foo.py file (a single-file module), or a directory with an __init__.py in it (a directory module).
I have a less disruptive counterproposal. How about just starting to refer to directories (or "folders", or zip entries) with '__init__.py' in them as "package modules"? A package is-a module anyway.
2. A "package" shall henceforth be the name of the thing that is currently called a "distribution".
I belive a multi-word term here would be similarly more memorable and precise. A "package distribution" would include the more familiar term while still being specific, consistent with the old terminology, and correct. Using a qualifying word is probably a good idea in this context anyway. I usually say "debian package", "RPM", "MSI", or "tarball" unless I'm specifically talking about "packages for your platform", almost always in the phrase, "please do not use distutils to do a system install of Twisted, use the specific package for your platform".
-1
I do, however, agree with Steve emphatically on your original proposal. Changing the terminology now will make billions upon billions of Python web pages, modules (c.f. twisted.python.modules.PythonModule.isPackage()) documents, and searchable message archives obsolete, not to mention that 90% of the community will probably ignore you and use the old terminology anyway, creating more confusion than it eliminates.
On Apr 30, 2008, at 5:11 PM, glyph@divmod.com wrote:
I have a less disruptive counterproposal. How about just starting to refer to directories (or "folders", or zip entries) with '__init__.py' in them as "package modules"? A package is-a module anyway.
That's a good idea.
I belive a multi-word term here would be similarly more memorable and precise. A "package distribution" would include the more familiar term while still being specific, consistent with the old terminology, and correct. Using a qualifying word is probably a good idea in this context anyway. I usually say "debian package", "RPM", "MSI", or "tarball" unless I'm specifically talking about "packages for your platform",
That's a good one too.
almost always in the phrase, "please do not use distutils to do a system install of Twisted, use the specific package for your platform".
This is a tangent, but why do you give that advice? I typically give people the opposite advice on how to install Twisted.
I do, however, agree with Steve emphatically on your original proposal. Changing the terminology now will make billions upon billions of Python web pages, modules (c.f. twisted.python.modules.PythonModule.isPackage()) documents, and searchable message archives obsolete, not to mention that 90% of the community will probably ignore you and use the old terminology anyway, creating more confusion than it eliminates.
I suspect 90% of the community already uses my proposed terminology -- that was my original challenge to round up a Python programmer and find out. But I agree that my proposal would contribute to confusion and disruption, and I like your counterproposals better, at least for now. Directories, folders, or zip entries with __init__.py in them are "package modules", and Python packages are "package distributions". Regards, Zooko
I'm not on distutils-sig, but this is probably of little interest to python-dev. Please Cc: me if you think my continued input would be useful to this discussion. On 08:25 pm, zooko@zooko.com wrote:
almost always in the phrase, "please do not use distutils to do a system install of Twisted, use the specific package for your platform".
This is a tangent, but why do you give that advice? I typically give people the opposite advice on how to install Twisted.
The #1 reason: * distutils does not provide an uninstaller. This means that a user who has installed a Python library - but especially a package like Twisted, which uses a shared namespace with other libraries that use it, twisted.plugins - can't easily get rid of it. I only ever use 'setup.py' in conjunction with '--prefix'; in my opinion, the *default* behavior of distutils should be "--prefix ~/.local". Definitely not the only reason, though. Even if distutils had a great uninstaller, I still probably wouldn't recommend it... * distutils will interfere with the system package manager, potentially breaking it, by writing files to locations reserved for the system package manager (/usr, et. al.) * distutils won't uninstall a system-installed version of the package first, so if you use e.g. --force to overwrite your system files, you may end up with leftover system packaged (incompatible, earlier-version) plugins or modules which break your distutils install * running arbitrary, non-vendor-supported code as root as a matter of habit is, in my humble opinion, bad; distutils requires you to run as root for the default behavior to work. the system package manager typically requires root permission too, but at least it's the sort of thing which has been audited. * not only can you not reverse the process, there's no way to *tell* if distutils has crapped all over your system installation of a particular package * setuptools causes seemingly random breakages (in packages which support it), and I don't want to deal with bug reports from users related to packaging; packagers are capable of dealing with setuptools' interactions with the platform and creating a nice, neat bundle that works as expected. * when you say "distutils", what do you mean? running 'setup.py' from some random revision of trunk? doing 'sdist' from trunk, then install? Using operating-system packages at least suggests that you're using a release, or if not an actual release, you've gone through something approximating the actual release/build process that we suggest for users. * if the user is installing for development anyway, and not for deployment, then why bother doing any installation step at all? It's probably better to just drop an SVN checkout on PYTHONPATH somewhere. And, finally... * why bother having installers prepared for particular systems, if they are not the preferred way of doing things? If and when distutils is ready to be the thing I will suggest to users, I imagine that we'll stop having operating system packages. (Of course, that begs the question why distutils would have commands like "bdist_wininst" - it's difficult to beat the native packages for convenience.)
On May 1, 2008, at 2:51 PM, glyph@divmod.com wrote:
I'm not on distutils-sig, but this is probably of little interest to python-dev. Please Cc: me if you think my continued input would be useful to this discussion.
I use distutils (or setuptools) plus GNU stow to solve the following subset of your complaints:
The #1 reason:
* distutils does not provide an uninstaller.
...
* distutils will interfere with the system package manager, potentially breaking it, by writing files to locations reserved for the system package manager (/usr, et. al.) * distutils won't uninstall a system-installed version of the package first, so if you use e.g. --force to overwrite your system files, you may end up with leftover system packaged (incompatible, earlier-version) plugins or modules which break your distutils install * running arbitrary, non-vendor-supported code as root as a matter of habit is, in my humble opinion, bad; distutils requires you to run as root for the default behavior to work. the system package manager typically requires root permission too, but at least it's the sort of thing which has been audited. * not only can you not reverse the process, there's no way to *tell* if distutils has crapped all over your system installation of a particular package
GNU stow + distutils or setuptools solves all of the above for me. It does not solve the following:
* setuptools causes seemingly random breakages (in packages which support it), and I don't want to deal with bug reports from users related to packaging; packagers are capable of dealing with setuptools' interactions with the platform and creating a nice, neat bundle that works as expected. * when you say "distutils", what do you mean? running 'setup.py' from some random revision of trunk? doing 'sdist' from trunk, then install? Using operating-system packages at least suggests that you're using a release, or if not an actual release, you've gone through something approximating the actual release/build process that we suggest for users. * if the user is installing for development anyway, and not for deployment, then why bother doing any installation step at all? It's probably better to just drop an SVN checkout on PYTHONPATH somewhere.
And, finally...
* why bother having installers prepared for particular systems, if they are not the preferred way of doing things? If and when distutils is ready to be the thing I will suggest to users, I imagine that we'll stop having operating system packages. (Of course, that begs the question why distutils would have commands like "bdist_wininst" - it's difficult to beat the native packages for convenience.)
Why indeed? I personally prefer to distribute my code in the form of source .tar.gz's which are to be installed either with easy_install or by untarring them and running "setup.py", and I prefer to re-use code from other people in that same format. Regards, Zooko
On May 1, 2008, at 4:51 PM, glyph@divmod.com wrote:
I'm not on distutils-sig, but this is probably of little interest to python-dev. Please Cc: me if you think my continued input would be useful to this discussion.
On 08:25 pm, zooko@zooko.com wrote:
almost always in the phrase, "please do not use distutils to do a system install of Twisted, use the specific package for your platform".
This is a tangent, but why do you give that advice? I typically give people the opposite advice on how to install Twisted.
The #1 reason:
* distutils does not provide an uninstaller.
This means that a user who has installed a Python library - but especially a package like Twisted, which uses a shared namespace with other libraries that use it, twisted.plugins - can't easily get rid of it. I only ever use 'setup.py' in conjunction with '-- prefix'; in my opinion, the *default* behavior of distutils should be "--prefix ~/.local".
Definitely not the only reason, though. Even if distutils had a great uninstaller, I still probably wouldn't recommend it...
* distutils will interfere with the system package manager, potentially breaking it, by writing files to locations reserved for the system package manager (/usr, et. al.) * distutils won't uninstall a system-installed version of the package first, so if you use e.g. --force to overwrite your system files, you may end up with leftover system packaged (incompatible, earlier-version) plugins or modules which break your distutils install * running arbitrary, non-vendor-supported code as root as a matter of habit is, in my humble opinion, bad; distutils requires you to run as root for the default behavior to work. the system package manager typically requires root permission too, but at least it's the sort of thing which has been audited. * not only can you not reverse the process, there's no way to *tell* if distutils has crapped all over your system installation of a particular package * setuptools causes seemingly random breakages (in packages which support it), and I don't want to deal with bug reports from users related to packaging; packagers are capable of dealing with setuptools' interactions with the platform and creating a nice, neat bundle that works as expected. * when you say "distutils", what do you mean? running 'setup.py' from some random revision of trunk? doing 'sdist' from trunk, then install? Using operating-system packages at least suggests that you're using a release, or if not an actual release, you've gone through something approximating the actual release/build process that we suggest for users. * if the user is installing for development anyway, and not for deployment, then why bother doing any installation step at all? It's probably better to just drop an SVN checkout on PYTHONPATH somewhere.
And, finally...
* why bother having installers prepared for particular systems, if they are not the preferred way of doing things? If and when distutils is ready to be the thing I will suggest to users, I imagine that we'll stop having operating system packages. (Of course, that begs the question why distutils would have commands like "bdist_wininst" - it's difficult to beat the native packages for convenience.)
These are very good arguments for not using distutils to install packages into a system Python. Well said. I'll note that I *never* use distutils that way. :) (I may be in the minority though.) Jim -- Jim Fulton Zope Corporation
participants (3)
-
glyph＠divmod.com -
Jim Fulton -
zooko