On Tue, Apr 02, 2002 at 07:45:50PM -0500, Love, Jay wrote:
> We'll also need to install the main AppServer startup script
> somewhere in the standard PATH so that there is something they can execute
> without having to type the whole path to the Webware package.
Distutils installs it in the same directory the Python executable
was originally installed. Tavis says that's /usr/local/bin/, but
in my experience it's been $PYTHONHOME/bin/. So if that's not already
in your path, you either have to put it in or copy/symlink into your
normal bin directory. But if you put that directory in your PATH,
you only have to do it once, even if you install another Python
package later with its own executables.
If we switch to distutils, does that necessarily mean switching to
Tavis' directory structure:
site-packages/Webware/WebKit/AppServer.py, HTTPServer.py, ...
site-packages/Webware/UserKit/User.py, UserManager.py, ...
site-packages/Webware/Webware/Exceptions.py, Log.py, ...
file containing "Webware" ; this makes Python put
site-packages/Webware on the default Python path, so any program
can do "from WebKit import HTTPServer",
"from UserKit import User", "from Webware import SettingsManager"
The mildly controversial portion is the Webware/ superdirectory.
It doesn't cause any problems so I don't see it as an issue.
Tavis wants to put third-party packages in this directory too:
site-packages/Webware/Cheetah, site-packages/Webware/FunFormKit, etc.
as they are installed separately. Again, Webware.pth ensures that
"from Cheetah.Template import Template" work as expected.
The more controversial portion is that Tavis combined MiscUtils/ and
WebUtils/ into one package, "Webware" (site-packages/Webware/Webware).
[Or did you keep the two types of modules distinct somehow?]
Chuck was strongly against this because he didn't want to have to
do "from Webware import Exceptions" for a module he might use in
a non-Webware context.
The counter-argument is that with distutils, MiscUtils and WebUtis would
become global packages visible to all Python scripts, and they are
polluting the global package namespace with generic names that don't
connote the project they come from. This strikes Tavis and me as
being bad neighborly. Fortunately the packages aren't *so* generic
as to be called "misc" or something.
-Mike (Iron) Orr, iron@... (if mail problems: mso@...)
http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol