From: Andrew Kuchling [mailto:akuchlin@mems-exchange.org]
> An open question: what should the 'test' command do? We could adopt
> some convention to automatically locate test scripts automatically
> (all files matching test/*.py, for example), with a
> tests=['dir/test1.py', dir/test2.py'] override to explicitly list test
> scripts and ignore the convention.
Yes. That seems correct to me.
> Next, what would it do with the test scripts? In 2.1b2,
> test.test_support.run_unittest() raises TestFailed when a test suite
> fails. Would it be sufficient to execfile() all the test scripts,
> note which ones raise TestFailed, and print a list of failing tests
> (which would come after the output of individual test scripts).
I would keep it as minimal as possible for now, so that we can make things
more elaborate in the future without breaking anything.
Suggestion for a specification:
"Each test file will be executed. At the end of the test runs, a summary of
the results will be displayed."
In particular, I don't think we are in a position at this stage to mandate
(or even presume) in what form test scripts should return their results. As
things mature (and in particular, as unittest gets more exposure and use),
standardising on an output format will be easier, and we should be prepared
to take advantage of that. But let's not jump the gun.
As an implementation, what you suggested is pretty good: execfile each test
script, and note any exceptions (I don't see any particular benefit in just
trapping TestFailed here). At the end of the run, print out a summary: xxx
test scripts run, yyy failed (TestFailed exception), zzz terminated
abnormally (any other exception).
This leaves the way open to "improve" things, for example by grabbing the
test output and postprocessing/formatting it, or by changing the format of
the summary. For example, Perl's standard test harness runs test scripts
which print a series of "ok N" messages, but grabs the output and reformats
it as "testname..........m/n" where n is the expected number of tests, and m
gradually increases as the tests run. This is very nice, both as a progress
indicator, and for a "feelgood factor" ("This module ran 4,700 tests! It
must be reliable!"). But we don't want this sort of detail just yet, hence
my suggestion of a minimal spec.
Paul.
I'm building an application, not a python module and am having some
troubles figuring out how to get distutils to install things where I'd
like them.
First problem is with install_data and win32 platforms. If i specify a
directory of /usr/local/gnue/shared as my target then the initial /
prevents the images from being included in the .exe If I leave it off
then it installs under c:\python20 which I don't want.
Next, what is the accepted method of altering installation locations and
files that point to that location. I guess what I'm after is how should a
person grab the value of --prefix and alter files to point to the install
location at runtime. Is there a standard that people follow?
If anyone is interested the setup.py's I'm working with are at
http://subversions.gnu.org/cgi-bin/cvsweb3/gnue/gnue/gnuef/setup.py?rev=1.1…
and
http://subversions.gnu.org/cgi-bin/cvsweb3/gnue/gnue/python-gnue-base/setup…
Thanks for any help you can provide,
James
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561
Kansas State University Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
I've got the server and client side of my PEP243 implementation (for
uploading distributions made by distutils to the repository server) built.
I've also created the code for distutils (2.1b2) to do the upload. For
example:
guin:python-netstring$ ./setup.py sdist --submit
[...]
gzip -f9 dist/python-netstring-1.14.tar
removing 'python-netstring-1.14' (and everything under it)
Submitting to repository server...
sending dist/python-netstring-1.14.tar.gz...
Succeeded.
done.
Currently, I have the repository server set up on our "public service"
server "community.tummy.com".
The files you will need are:
ftp://ftp.tummy.com/pub/tummy/swalow/swalow-1.13/distutils-swalow.patchftp://ftp.tummy.com/pub/tummy/swalow/swalow-1.13/swalowsupp.py
See the README below for information on how to apply it.
The server for handling the requests is also available at the above site,
you'll need a few support modules as well (like the tar module for
extraction of the PKG-INFO file).
I need to update the repository server and client for PEP241, but that
should be pretty straight-forward. Also, if anyone else wants to get
copies of the data sent to my repository, I can certainly arrange that...
Any comments?
Sean
=========================
swalow + Distutils README
Sean Reifschneider <jafo-swalow(a)tummy.com>
==========================================
The file "distutils-swalow.patch" contains a patch against the 2.1b2
distutils which allows "setup.py sdist --submit" to upload the completed
distribution file to the repository server. This will allow automatic or
semi-automatic submissions of modules.
To gain this functionality, apply the above patch, and copy "swalowsupp.py"
into the main distutils package directory.
If the environment variable "PYTHON_MODULE_SERVER" is set, that value
overrides the default host for uploading the distribution to.
--
That weapon will replace your tongue. You will learn to speak through
it. And your poetry will now be written with blood. -- _Dead_Man_
Sean Reifschneider, Inimitably Superfluous <jafo(a)tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
From: Sean Reifschneider [mailto:jafo@tummy.com]
> PEP: 243
> Title: Module Repository Upload Mechanism
> platform (optional) -- A string representing the target
> platform for this distribution. This is only for binary
> distributions. It is encoded as
> "<os_name>-<os_version>-<platform architecture>".
This probably needs to include the Python version for which a binary
distribution was compiled.
> signature (optional) -- A GPG signature of the uploaded
> distribution as signed by the author. This may be used by the
> cataloging system to automate acceptance of uploads.
Why GPG? Is that available on all platforms? Could PGP signatures be used
for people on Windows (for example), who probably don't have GPG?
> The upload client must submit the page in the same form as
> Netscape Navigator version 4.76 for Linux produces when presented
> with the following form:
I'd suggest this format be spelled out. I don't have Linux or Netscape, so I
can't determine what the submitted page should look like from this
description...
> Platforms
>
> The following are valid os names:
>
> debian
> hpux
> mandrake
> redhat
> solaris
> suse
> windows
> yellowdog
dos? beos? mac? This feels very Unix-specific...
> Version is the official version string specified by the vendor for
> the particular release. For example, "nt" (Windows), "9.04"
> (HP-UX), "7.0" (RedHat, Mandrake).
That's not likely to be precise enough. Is Windows 2000 "2000" or "nt"? It's
binary-compatible with NT. Same goes (and more so) for Windows 9x, which are
most definitely NOT NT, but which are binary-compatible.
Take a Windows security module. It's binary compatible with Windows 9x, NT,
and 2000. But the API calls involved either don't exist, or produce errors
or do nothing on Windows 9x, which has no security features (ducks, waiting
for the "Windows in general has no security features" jokes :-)
Paul.
I've updated the text of PEP 241:
http://python.sourceforge.net/peps/pep-0241.html
The changes are:
Rename METADATA file to PKG-INFO
Specify RFC-822 as the format
Add Metadata-Version field (must be 1.0)
Rename Description->Summary, Long-Description->Description
Remove some XXXs for keywords and author data.
Slightly reword the text about using the e-mail address as a key
Fix incorrect example for author-email
Add list of licenses
Here's the initial list of licenses; additions/deletions?
Artistic, BSD, GPL, LGPL, "MIT/X11", MPL, "public domain",
Python, QPL, ZPL, other
--amk
May be I have missed that, but if you also want to
support binary packages, shouldn't be there a field for
which python version it was compiled?
(platforms is not enough, you could use python 1.5.2, 1.6
or 2.0 on Windows and it would have in all cases "windows"
as platform.)
Ok, this is dependy checking code, but this one isn't
very hard to realize.
Kind regards
Rene Liebscher
After two long-distance calls to Montreal and another hour of work,
I've uploaded a new version of the PEP 241 patch that is ready to go
in. Can some please review it for me before I check it in (on
Wednesday, I hope).
Final questions:
* When the 'platforms' argument isn't specified, the option will be
set to ['UNKNOWN'], not an empty list. Is that OK? The keywords
argument, if not specified, will be treated as an empty list, which
does seem the obviously correct thing to do.
* 'Author' in the metadata comes from the maintainer fields, my
argument here being that, if they're different, the catalog is only
interested in who maintains the package *now*, not whoever wrote it
originally. Is that OK? Adding a maintainer field to the metadata,
thus preserving the author/maintainer division, would be trivial.
I'll bow to cataloguers; if it would be useful, let me know and I'll
add it.
--amk
Hello distutils. I'm excited about the recent developments
going on with distutils, but I'm becoming concerned that my
own package using distutils will not work at all with the
new features.
Currently it compiles and installs my modules quite well, but
I am completely unable to use any of the 'dist' commands,
since it doesn't get nearly enough of my files.
I'd like to ask for a little peer review of the 'setup.py'
for my project. I've had to "hack" together quite a few
things to make them work as best i saw fit.
The project also has a 'config.py' script which makes a
semi-reasonable attempt to find all the dependency
libraries/headers and create the "Setup" file.
Anyways, like i mentioned, things are working fine enough
for now, but i have serious concerns about my usage of
distutils. I would be very greatful for those of you who
know your way around distutils to look things over.
For now i'm also completely ignoring my documentation
and examples in distutils. I just package them in with
my projects by hand.
Ok, the project is "pygame", and it is a python wrapper for
SDL and several other of its multimedia daughter libraries.
The project is here, http://pygame.seul.org/
but you can download the source and examine my "setup.py"
and build instructions from here
http://pygame.seul.org/ftp/pygame-0.9.tar.gz
Thanks a lot for those of you who can do this. The project
is right around the corner from a 1.0 release, and I'd like
to make sure my distutils installing is in as good as shape
as it can be.
I've checked in the patch implementing PEP 241, unchanged from the
last version posted to SourceForge. If you notice problems before
Friday, when 2.1b2 is supposed to be released, please let me know
*immediately*.
Also, I backed out the conversion to string methods that was performed
on some of the files, so the CVS tree should work with Python 1.5.2
again. If you're still using 1.5.2, please let me know if you run
into problems.
I'll wrap up a 1.0.2pre1 release in a few days, assuming no problems
show up in the meantime.
--amk
Andrew Kuchling wrote:
> Information about a package
> ===========================
> Name
> Version
> Supported Platforms
> Description
> Keywords
> Homepage URL
> Author IDs
> License
> Download link
> Date of release
Thanks for the great start Andrew! I have a couple comments.
The distutils currently has both a description and a
long_description. I think that both are useful.
It also has a couple "derived" fields - contact and
contact_email are set to either the maintainer (if
available) or the author. It also has a fullname field which
is name-version. I think that we can dispense with these
"derived" fields.
For fields like platforms, and license we should have a list
of possible choices.
Keywords are tricky. Should we have a restricted vocabulary?
I think that a controled vocabulary is preferable, but
agreeing on a vocabulary is difficult. I suggest that we use
an existing categorization system. For example, CPAN, Source
Forge, and Freshmeat have ways of categorizing software. I'm
sure that there are lots of other examples too.
I wonder about the download link. The distribution packager
may not know what this is, assuming that the software can be
downloaded from the catalog. Maybe this field is set by the
catalog. Or maybe it doesn't belong in the meta-data.
Finally, maybe you should be able to find out which files a
package installs. Maybe this information is not properly
speaking meta-data.
> Information about a document
> ============================
> Name
> Author
> Description
> URL of HTML version
> URL of printable version
> URL and format of downloadable version
> (Any of these URLs can be omitted if not applicable.)
>
> The "Information about a document" section is only
relevant to a
> catalog that includes non-software things such as
documentation, and
> can probably be ignored for now.
I agree that we should hold off on this for now. There are
lots of other pieces of information which may be relevant to
documents (for example, the Dublin Core).
> The "Information about an author"
> section makes sense for a CPAN-like system where authors
are
> registered as independent entities, but not for one where
packages are
> the only entities. On the other hand, maybe registering
developers is
> worth preserving; otherwise you'd have to put your URL and
GPG key in
> every single package you maintain, which is kind of
annoying.
I think that it's worth having author information seperate
from package information. I also think that email address is
a good author id. This probably means that the catalog
system will be in charge of managing author meta-data, while
packag meta-data will be managed by distribution packagers.
Thanks again Andrew for offering to write this up as a PEP.
-Amos
