Mailman 3 March 2001 - Distutils-SIG

RE: [Distutils] The 'test' command
by Moore, Paul 26 Mar '01

26 Mar '01

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.

1 0

Install questions
by James Thompson 26 Mar '01

26 Mar '01

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 ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

1 0

ANNOUNCE: Distutils upload patch (PEP243)
by Sean Reifschneider 25 Mar '01

25 Mar '01

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.patch ftp://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

1 0

RE: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism
by Moore, Paul 25 Mar '01

25 Mar '01

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.

7 15

New draft of PEP, and list of licenses
by Andrew Kuchling 23 Mar '01

23 Mar '01

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

4 7

PEP241 platforms
by Rene Liebscher 23 Mar '01

23 Mar '01

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

2 1

Final PEP 241 patch
by A.M. Kuchling 23 Mar '01

23 Mar '01

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

2 1

Peer Review
by Pete Shinners 23 Mar '01

23 Mar '01

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.

2 1

PEP 241 checked in, and 1.5.2 compatibility
by A.M. Kuchling 22 Mar '01

22 Mar '01

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

3 3

Re: [Distutils] Metadata fields
by Amos Latteier 21 Mar '01

21 Mar '01

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

5 11