At 06:53 AM 3/10/04 +0000, Moore, Paul wrote:
>From: Mark W. Alexander
> > Why does everyone seem to think that the prefered method of Distutils
> > package installations is "setup.py install"?
>FWIW, I agree. On Windows I *always* do setup.py bdist_wininst and then
>run the generated installer. This gives me an uninstall option, which
>"raw" distutils doesn't.
Clever idea. I think I'll try that myself. Indeed, it might be amusing to
make a 'winstall' command that does bdist_wininst and then runs the executable!
>This is *not* a plea for uninstall capability in distutils :-)
I think some other folks actually *are* working on that, however.
From: Mark W. Alexander
> Why does everyone seem to think that the prefered method of Distutils
> package installations is "setup.py install"?
FWIW, I agree. On Windows I *always* do setup.py bdist_wininst and then
run the generated installer. This gives me an uninstall option, which
"raw" distutils doesn't.
This is *not* a plea for uninstall capability in distutils :-)
I'm working on a set of distutils enhancements called "setuptools". The
"setuptools" extend the base Distribution class with the ability to do:
* feature management -- you can define subsets of a distribution as
"features" that can be enabled or disabled via '--with-X' and '--without-X'
options to 'setup.py'. Features can (recursively) depend on other
features, and be included or excluded by default. (Their inclusion or
exclusion affects all commands, as the relevant
packages/modules/data/scripts/whatever are added or removed just after
command line arguments are parsed.)
* package data installation -- you can specify filenames or globs to be
searched for in package source directories, for installation alongside the
package .py files. All without munging the 'install_data' command or
manually copying files, and the data files are correctly included in the
'get_outputs()' manifest for all the distutils features that depend on
knowing what files were copied.
* 'test' command -- optionally run a user-specified or 'setup.py'-specified
test suite via the 'unittest' module.
* Packages and modules can be simultaneously specified as arguments to
'setuptools.setup()', unlike the standard distutils 'setup()'.
The above features are all fully implemented and documented via docstrings,
and the majority of them are covered by an extensive unit test
suite. "setuptools" uses itself for its own 'setup.py', in order to enable
the 'test' command to run its built-in unit tests.
The purpose of "setuptools" is to collect commonly useful distutils
enhancements for large or complex packages like Zope X3 and PEAK. It's
also intended to be the starting point for developing simple installer-side
dependency support, as described/proposed at:
Finally, I also intend to add some type of general-purpose documentation
build and install facilities, to replace the rather hacky documentation
support in my current setup scripts.
At this point, the package isn't quite ready for general release, as it
doesn't include documentation beyond docstrings, and of course the
dependency and documentation features aren't written yet. But I believe it
is ready for feedback from interested parties such as PyCon sprinters, and
people who are undertaking complex distutils projects. I'm interested in
your comments, especially as they may relate to the viability of eventually
merging setuptools into a "Distutils 2.0" (or maybe "1.5"). Setuptools is
specifically laid out to match the package layout and naming conventions of
the distutils in order to facilitate such porting.
You can currently find the setuptools CVS at:
although there has been some discussion about moving it to the Zope X3 CVS
in the near future to facilitate the coming sprint, and other contributions.
Please follow up with discussion to the distutils-sig mailing list. Thanks.
At 09:04 AM 3/8/04 -0500, A.M. Kuchling wrote:
>On Sun, Mar 07, 2004 at 10:26:38PM -0500, Phillip J. Eby wrote:
> > Hi Andrew. I was looking over PEP 262 today for possible
> implementation in
> > "setuptools", and I had a few questions and comments.
>You should have sent this post to the catalog-sig or distutils-sig, because
>it raises some interesting issues.
> > 1) be called 'install-db', to avoid conflict with a package name
>Good idea; PEP updated.
> > 2) be potentially present on every directory in sys.path, with the
> > merged in sys.path order. This would allow home-directory or other
> > alternate-location installs to work, and ease the process of a distutils
> > install command writing the file.
>Hm; for some reason I find the idea of multiple databases disturbing; would
>it be too confusing and error-prone? On the other hand, it does mean that
>package manager tools can take into account packages that a user has
>privately installed, which is a nice feature. On balance I suppose it's a
>Ooh, but what does setup.py do if it's told to install packages to a
>directory not on sys.path? Does it write an install-db directory to the
>directory it's told to write to, or does it do nothing?
The directory where it's installing packages to. Also, for purposes of
uninstallation, it should include that installation directory on the list
of directories scanned for package installation info. This all means that
the installdb API needs to be able to be told what directories to search,
perhaps with a default of sys.path.
In a manner analogous to the way modules can shadow each other on sys.path,
distributions found earlier in the directory searches should shadow later
distributions with the same name. (This prevents confusion between a
user's local version of a distribution, and the system-supplied version.)
> > Next, I'd like to ask if it's okay to have the minimum contents of a
> > package file be PKG-INFO FILES instead of also requiring PROVIDES and
> > REQUIRES. The latter two seem a bit premature for
>PROVIDES and REQUIRES can simply be left empty, though. I can weaken the
>language in this section a bit.
> > * Should the package-database file itself be included in the files
> > list? (I would think yes, but of course it can't contain its own
>Does it really matter? The only case I can think where this matters is
>removing a package, where you could just read all of the files listed in the
>database and delete them. But the code implementing this will be in the
>InstallationDatabase class, which will already have the filename of the
>database file. In short, I don't think this really matters. Do you have a
>use case for including it?
If you use 'setup.py install --result=somefile', the distribution's
information file should be included (for compatibility with external
packaging tools that use --result). So, that means the 'install' command
object should have it listed in its 'get_outputs()'. But, presumably the
list that goes into the file is going to *come* from 'get_outputs()'. So,
it seems like the list would include the file itself, if that makes sense.
> > * The spec says that checksums of .pyc/.pyo files should not have their
> > checksums stored, but does not say *how* to not store them. By omitting
> > the field? By placing 'unknown' there?
>I was thinking that the field would simply be '-'. It could be omitted, but
>then if we ever add another column there will be problems. PEP updated to
Come to think of it, why *shouldn't* those files be verified as to
checksum? Is it simply because they contain an internal timestamp?
>Hey, this raises another issue; should we guarantee the format of
>installation databases remains compatible across Python versions, or is it
>subject to arbitrary change?
I would think it needs to be guaranteed. If there's a change, it would
need to be by adding a new section name like 'FILES2' for the new
format. In practice, though, FILES is extensible via additional columns,
and the metadata section is extensible via adding new header lines. So,
all in all, the format is reasonably future-proof, at least for the
> > * Are there any legal or other issues regarding deployment of SHA1? I'm
>No, SHA just does hashing, not encryption, so there are no problems with its
>inclusion in Python.
> > Finally, there's a bit of a terminology issue. I think that the term
> > "package" should be used for Python packages exclusively, using perhaps
> > "distribution" to refer to an installed unit. So, instead of looking up a
> > "package", you would look up a "distribution". Currently, the use of
> > "package" in the PEP is ambiguous, making it difficult to understand in
> > parts.
> > Anyway, apart from these issues/questions, I think it should be possible
> > for me to move forward with an implementation, possibly complete with a
> > facility to uninstall/upgrade/verify, although I can't guarantee *when*
>Note that there's already an implementation in nondist/sandbox/pep262 in
>CVS, though I don't remember how complete it was. I'm planning to dust it
>off before PyCon.
Ah. If I'd known where it was, I'd have UTSL'ed to see if it answered any
of these questions. I'll take a look at it when I get a chance.
Another spec question: is there a blank line after the line listing the
sections? Can there be one? Are sections separated by a *single* blank
line, or can there be more than one blank line between them?
Cialis IsA NewImpotenceDrug.
Cialis is in a class of medications known as PDE-5Inhibitors, which are used to treat MaleImpotence.
Up to 86% of patients WhoTakeCialis experience an improvement in their erections. CialisActs in the SameWay As Viagr.
YouGainE-rections faster and easier with Cialis.
take it easy
------------------ Virus Warning Message (on the network)
msg.com is removed from here because it contains a virus.
------------------ Virus Warning Message (on the network)
Found virus WORM_NETSKY.B in file msg.com
The file is deleted.
Therefore we removed the attachment-file
by Mail Server and sent the message to you.
Dear user of Python.org gateway e-mail server,
Your e-mail account will be disabled because of improper using in next
three days, if you are still wishing to use it, please, resign your
Advanced details can be found in attached file.
Attached file protected with the password for security reasons. Password is 10246.
The Python.org team http://www.python.org
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<p>Yo limp dizzle, I got the salooshin to yer bodies palooshin'. Take one dose
of thizz, give that ho a kizz, drop yo draws, she'll luv how hard it izz. She
be breaking down your door, begging for more. Spreadin' them legs like a dirty
<p>- Life just seems to flow with <a href="http://effectiveherbs.com/sv/index.php?pid=eph6636">Ciliazz</a>.
Don't want any dis, then flow <a href="http://effectiveherbs.com/sv/applepie.php">owt
with our lizt</a>. </p>
<p>World famous rapper, Shawtie Flave of Dawty Soüth Reckardz</p>