From bsass@freenet.edmonton.ab.ca Thu Mar 1 04:51:01 2001 From: bsass@freenet.edmonton.ab.ca (Bruce Sass) Date: Thu Mar 1 04:51:01 2001 Subject: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: <01022721090603.20069@branagan> Message-ID: On Tue, 27 Feb 2001, Doug Hellmann wrote: > On Tue, 27 Feb 2001, Bruce Sass wrote: > > I'm a little concerned about the privacy aspect of this... > > > > > That decision is up to the client. If the client has the smarts to turn > > > a distutils package into an RPM, then the client would list it's preferred > > > format as a distutils package and it would handle the rest. If it can't, > > > you can either select an RPM, or fall back to a distutils package. > > > > Why should the client need to "list" anything. > > > > client: what do you have? > > server: this(deb,rh-5.rpm,rh-6.2.rpm,rh-7.rpm) that() other(hqx) <...> > I'm not sure why the "what do you have" question is needed. The "send me > that(mandrake.rpm)" interaction is what we want. Automated tools need to query what is available so they can decide where to satisfy a dependency from. Packages will be available from a variety of outlets, not just the python archive. > The client requests packages in the formats prefered. A standard source format > should be available for all packages so that everybody can get every package in > some form. If the standard source format contains distutil-enabled scripts, > platform specific distribution files could be generated from the source. Yup. What do you think of having the server look like a platform specific distribution archive? So, when the server sees requests for (lets say) Debian style Packages and Release files (used to create the available packages DB), it assembles them from the list of python packages. Requests for URLs that look like those of packages in RHs archive whould result in a RH-rpm being served up. This would allow for complete integration with any client's native package archive system the server knows about, and give the CPyAn archive full control over package names, release numbers, etc. - the little bits that can cause simple to fix, but annoying, dependency problems. just a thought > > This could work... > > client: only show me (deb) and () > > client: what do you have? > > Right, that would be a bit more efficient than specifying a format for every > package for every request. There could also be an (all) format, why limit the possibilities. > > The server should NOT be usable as a tool to track Python users and > > their habits, and making it do so should require a conscious effort on > > the operators part (so there is no opportunity for the operator to > > say, "I don't track you, that's just how the software works"). > > The server is likely to be a cgi, which by its nature means requests may be > written to a log file. Should that be disallowed? Obviuosly there is nothing that can be done about normal system logging, but the cgi/factory-object/whatever should not keep any persistent user/connection information around (i.e., no log from the CPyAN software which lists who got what in which format when). - Bruce From phrxy@csv.warwick.ac.uk Thu Mar 1 07:15:03 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Thu Mar 1 07:15:03 2001 Subject: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: <20010228170725.B1781@tummy.com> Message-ID: On Wed, 28 Feb 2001, Sean Reifschneider wrote: > On Wed, Feb 28, 2001 at 09:59:38AM -0000, Moore, Paul wrote: [...] > >The h2xs program > >---------------- > > That seems like a distutils tool to me. > > >A social structure > >------------------ > > Based on my experimenting with Distutils last night, I don't know that this > will be a problem. Distutils is totally cool -- I can't imagine going back. > > >Interestingly, developers probably don't "expect" to have to include > >dependency information, and hence many don't - resulting in the problems you > > I think we can deal with that in an iterative manner. First get them to build > distutils packages, then when it fails to install on some user's machine > because they don't have foo.py we can educate them on the joys of listing > third-party module requirements. I think an iterative approach is a recipe for an archive full of packages that only very patchily take advantage of all the facilities on offer. The perl approach of making 'stubs' generation very easy for tests, docs, etc. is a very good idea -- it encourages you to actually put something more useful in the stubs (if not immediately, then later on). It's self perpetuating: they're always generated and the standard instructions for uploading stuff say you should include them (presumably), so it becomes widespread in the archive; people making new packages then see that everyone makes packages that way, so they'll do the same thing. I'm not suggesting everyone's about to start writing huge comprehensive manuals and test suites for everything, but a little encouragement and standardisation can go a long way, with a relatively small effort on the part of the developer. Same for dependencies, even more so probably. > >still (relatively) new, and so there are LOTS of packages which don't come > >with a setup.py yet. Often, adding one isn't hard, but it is still to > > The biggest win of using distutils is that it makes it easier for the > developer to run their software on multiple machines. That selfish > reason is enough for me. And, as selfish users of other people's software, you can use that as a hook to get people to start making documentation and tests at the same time. Getting started is often the 'rate limiting step'. > >Things are looking better with Python 2.1, though. Included with 2.1, it > >looks like there will be a standard unit testing module, and a new "pydoc" > >package, which will extract documentation from module docstrings. So the > > Should be sweet... [...] Especially if this and PyUnit, and whatever else, can all be tied together in Distutils. But *only* if there are actually some proper docs and good howto examples for Distutils itself!! What happened to the effort a while back on that? What remains to be done -- a todo list would be useful to spread the load, wouldn't it? John From thomas.heller@ion-tof.com Thu Mar 1 07:29:00 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 1 07:29:00 2001 Subject: [Distutils] Re: CPAN functionality for python - requirements References: Message-ID: <032e01c0a24b$13d30fa0$e000a8c0@thomasnotebook> > [...] But *only* if there are actually some proper docs and good > howto examples for Distutils itself!! What happened to the effort a while > back on that? What remains to be done -- a todo list would be useful to > spread the load, wouldn't it? > I wrote some docs. They are online already in Fred Drake's development version: http://python.sourceforge.net/devel-docs/ Thomas From tony@lsl.co.uk Thu Mar 1 08:31:04 2001 From: tony@lsl.co.uk (Tony J Ibbs (Tibs)) Date: Thu Mar 1 08:31:04 2001 Subject: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: <032e01c0a24b$13d30fa0$e000a8c0@thomasnotebook> Message-ID: <005d01c0a253$bc513dc0$f05aa8c0@lslp7o.int.lsl.co.uk> John Lee grumbled about a lack of documentation for distutils, and Thomas Heller replied: > I wrote some docs. They are online already in Fred Drake's development > version: > http://python.sourceforge.net/devel-docs/ Erm - all I can see there that sound at all relevant are "Distributing Python Modules" and "Installing Python Modules", both credited to Greg Ward, and both in that infernally infuriating "one smidgeon of text per HTML page" format (which is worse than useless, so far as I'm concerned!)[1]. Could you give a clearer reference, please? ..[1] or am I missing some (undocumented) trick of the trade which will lead me to whole documents? Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ Give a pedant an inch and they'll take 25.4mm (once they've established you're talking a post-1959 inch, of course) My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) From Anthony@COMPUTRONIX.com Thu Mar 1 10:28:01 2001 From: Anthony@COMPUTRONIX.com (Anthony Tuininga) Date: Thu Mar 1 10:28:01 2001 Subject: [Distutils] Question Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A264.1B2FF150 Content-Type: text/plain; charset="iso-8859-1" In the past I have used the "freeze" method available in the tools section of the Python distribution for distributing binaries to those without Python. Just recently I started using DistUtils for compiling my C extension but unfortunately that breaks the freezing process if the extension module is going to be folded in to the resulting executable (rather than a standalone shared library). Before I go off and try to make this work, I was wondering if anyone knew if freezing was being planned for DistUtils. If so, what can I do to help, and if not, what ought to be replacing it? I suspect it shouldn't be too difficult to take the code that determines modules, compile them and generate C files, then use the DistUtils modules to actually compile the executable. But I don't want to do that if someone already has or there is something better to use. Comments anyone? Anthony ------_=_NextPart_001_01C0A264.1B2FF150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question

In the past I have used the = "freeze" method available in the tools section of the Python = distribution for distributing binaries to those without Python. Just = recently I started using DistUtils for compiling my C extension but = unfortunately that breaks the freezing process if the extension module = is going to be folded in to the resulting executable (rather than a = standalone shared library). Before I go off and try to make this work, = I was wondering if anyone knew if freezing was being planned for = DistUtils. If so, what can I do to help, and if not, what ought to be = replacing it? I suspect it shouldn't be too difficult to take the code = that determines modules, compile them and generate C files, then use = the DistUtils modules to actually compile the executable. But I don't = want to do that if someone already has or there is something better to = use. Comments anyone?

Anthony

------_=_NextPart_001_01C0A264.1B2FF150-- From thomas.heller@ion-tof.com Thu Mar 1 10:49:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 1 10:49:01 2001 Subject: [Distutils] Re: CPAN functionality for python - requirements References: <005d01c0a253$bc513dc0$f05aa8c0@lslp7o.int.lsl.co.uk> Message-ID: <037301c0a267$07e60460$e000a8c0@thomasnotebook> > Thomas Heller replied: > > I wrote some docs. They are online already in Fred Drake's development > > version: > > http://python.sourceforge.net/devel-docs/ > Tony J Ibbs wrote: > Erm - all I can see there that sound at all relevant are "Distributing > Python Modules" and "Installing Python Modules", both credited to Greg > Ward, and both in that infernally infuriating "one smidgeon of > text per HTML page" format (which is worse than useless, so far as I'm > concerned!)[1]. > > Could you give a clearer reference, please? This is the patch I posted: http://mail.python.org/pipermail/distutils-sig/2001-February/001969.html Note that I didn't say that the docs are complete... Thomas From cppy@gmx.de Thu Mar 1 14:13:00 2001 From: cppy@gmx.de (matthes markers) Date: Thu Mar 1 14:13:00 2001 Subject: [Distutils] changes neccesary to natively support unlimited c++ extensions Message-ID: <30531.983473927@www38.gmx.net> hi ! recently i experimented with the very bad native c++ support of python & distutils, but 'found' a very good library which adds exactly this to python (distutils). writing extensions in c is fully supported by the distutils. not a single error or warning on compilation. very nice! but compiling and extension-builing of c++ modules is not so extremely easy. (small probs with library-path, compileroptions, linkeroptions, no special distutils 'Extension') boring. that's why i'd want to propose to include and support the boost python library especialy into the python documentation, examples, and to special support them in distutils. so people dont have to go and search for their own, and all using different libs and inventing the wheel twice. (same thing with py2exe) proposal: """ 1) include the boost-python c++ extension library into the distutils to get the opensource power concentrated on this fine library. finaly making it the 'standart'. 2) add some more power to the build process of the distutils, by automaticaly considering the systems 'include' variable. 3) add system independend compile-options to the distutils. +RTTI -RTTI [+Force_C -Force_C ] [+Force_C++ -Force_C++] ... (because boost needs >extra_compile_args=["/GR"]< and it would be great to have this determinated automaticaly (regex-search for "dynamic_cast" in the library source). this would hit in "extension_class.hpp" for boost) 4) most important: document the use of boost in the python documentation, so writing c++ extension becomes the most natural thing one comes in mind to extend python with. """ maybe you remember me, some time ago i posted a question, how to extend python with c++ code. i got a hint about swig. (greetings to thomas heller!) so i got myself going and started to explore the possibilities, beginning with swig. my findings were basicaly: swig (shadowclasses-mode) cXX (very limited) zope-ExtensionClass boost-ExtensionClass i compared the tools, and found cxx and swig unusable for large projects. (containing overloaded operators, templates..) wxwindows is not using this powerfull extended features, and so swig does a good job this case. dont argue about this. and yes, wrapping for instance mesa with boost makes no sense. swig is probably still the best for such tasks. but that's not the point here. however, i found that the boost-ExtensionClass had the most advanced design, which simplifies even the reference-counting and operator overloading for you. please visit the comparison-page of boost for pro and con of most existing tools to make writing c++ extensions easy. 1) the comparison page from boost says it all. swig and cxx won't do. as we have an interpreted language, we definitly dont want to use even another intermediate 'compiler' to get and maintain our extensions. + of course everyone is using templates, overloaded operators, and virtual functions this days. (great features, cant live without them). zope is great, but boost is basicaly same, and seems to do more. (still so?) it's very easy to incorporate into the c++ code, so it will not mess up python code in any way (wrappers, shaddow-classes, quirky calling conventions) and you need to compile your extension anyway, right? so i believe, the python community needs a fully supported 'foolproof' default way for POWERFULL c++ extensions, which feel like python classes, once imported. first this means: build of bosst-lib itself should be automated using distutils "make_boost_lib(path)" which makes the lib, and automaticaly links it to the extensions build subsequently using boost headers. (you'll find a better sytax. it's just the idea.) why? you are right, everyone CAN write this into a setup-script already, but why was distutils introduced? -> your answer. i tried, but gave up on compilerswitches. i used the included msvc workspace to compile boost. uhh.. 2) from doc: 'os.confstr(name)' #Return string-valued system configuration values. is documented in os. but works not for windows. (at least for me) this command (?) is neccessary to implement a systemvariable lookup for the "include" variable, people use to 'install' librarys. system_incl_dirs = os.confstr("include") system_incl_dirs += os.confstr("Include") extension.py line 98 can become: if include_dirs is None: include_dirs=[] self.include_dirs = include_dirs + [system_incl_dirs] now it would be easy for me to extend os for confstr, but i did not found the body of this function (using a overall search) and dont want to mess up something i just begin to understand should i implement it? this change opens the door for python extensions to all 'installed' librarys (ok, some ideas for the linker?) 3) noone wants to look up man gcc + msvc + bc5.5 for the exact syntax of a special compilerswitch. (platform) people have more important stuff to do. 4) docs are the key to get features used. ====================================== documentation of boost - python lib is erm.. medium. i would contribute a rewritten documentation of boost, and self-made examples. not the incomplete buggy examples given in the boost doc, but compiling and working ones. (using modified distutils + a setup.py) please tell me your opinion! i think of c++ and python as the 2 languages of the future. (for general programming tasks) c++ parts interconnected by python code, which even binds other crap erm.. code crash-proof (exceptions) to the whole package if realy neccesary. easily maintainable by changing the script holding high quality, fast, templated c++ libs and apps together. python is the dot which makes c++ perfect. actualy i reorganize my c++ code (mostly commandline) to be controlled from python (using boost) and give them a gui (wxPython (by dunn, thanks man!)). this heavily uses: c++ (+stl+templates+virtual_funcs+operators..) python (laaaate binding) boost (c++ python interconnection) wxwindows (best crossplatform gui.) wxpython (swig python-binding of the above) py mods (ftp, url, regex, ...) py2exe (commercial stuff.. need to keep my refrigerator filled by myself :-( i think this is a fairly robust design-path. (thus deserving special support by python + distutils i believe.) ok, that's all. at least for now :-) no flames please. ml -- Sent through GMX FreeMail - http://www.gmx.net From cppy@gmx.de Thu Mar 1 14:34:03 2001 From: cppy@gmx.de (cppy@gmx.de) Date: Thu Mar 1 14:34:03 2001 Subject: [Distutils] changes neccesary ... addition References: <30531.983473927@www38.gmx.net> Message-ID: <8216.983475182@www38.gmx.net> hi ! i've just seen that the python documentation was updated the last days, now containing some more info about extensions. >A Cookbook Approach< but first: the compile.py script from David Ascher is no more available from this page, (since a long time now..) nor should it be used. this is a job for the distutils !! same for extensions under unix. so it should be documented rather then mystic scripts making just msvc projects. ml -- Sent through GMX FreeMail - http://www.gmx.net From cppy@gmx.de Thu Mar 1 15:14:01 2001 From: cppy@gmx.de (cppy@gmx.de) Date: Thu Mar 1 15:14:01 2001 Subject: [Distutils] changes neccesary .... boost webpage url (forgot that) References: <30531.983473927@www38.gmx.net> Message-ID: <20464.983477572@www33.gmx.net> boost-python lib for 'making' python-classes from c++ classes http://www.boost.org/libs/python/doc/index.html comparison page: !!! http://www.boost.org/libs/python/doc/comparisons.html -- Sent through GMX FreeMail - http://www.gmx.net From jack@oratrix.nl Fri Mar 2 04:16:01 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri Mar 2 04:16:01 2001 Subject: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: Message by Sean Reifschneider , Wed, 28 Feb 2001 16:54:49 -0700 , <20010228165449.A1781@tummy.com> Message-ID: <20010302091545.DD722373C95@snelboot.oratrix.nl> > On Wed, Feb 28, 2001 at 10:13:51AM +0100, Jack Jansen wrote: > >Well, one of the things I'd like to do is integrate all this in MacPython IDE, > >and the same probably holds for PythonWin and Idle. Then the "what do you > >have" is pretty useful for building menus and such. > > I anticipate having a web-based interface to the database as well. I'm > sure that we can get the CGI to let the user do that sort of search [...] Right, but an IDE can do better. For instance, if an import fails it can offer to do a lookup on the packages site to see whether such a package is available. On the other hand: it could also do so by firing up your browser with a carefully constructed URL. Ah well... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From bsass@freenet.edmonton.ab.ca Fri Mar 2 09:53:00 2001 From: bsass@freenet.edmonton.ab.ca (Bruce Sass) Date: Fri Mar 2 09:53:00 2001 Subject: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: <20010228165449.A1781@tummy.com> Message-ID: On Wed, 28 Feb 2001, Sean Reifschneider wrote: > On Wed, Feb 28, 2001 at 10:13:51AM +0100, Jack Jansen wrote: > >Well, one of the things I'd like to do is integrate all this in MacPython IDE, > >and the same probably holds for PythonWin and Idle. Then the "what do you > >have" is pretty useful for building menus and such. > > I anticipate having a web-based interface to the database as well. I'm > sure that we can get the CGI to let the user do that sort of search, but > at the moment it's restricted so that the user has to specify the name > of the package they're looking for. I figured dumping gigabytes across > some user's line wouldn't be optimal. ;-) Gigabytes? ~$ avail=/var/lib/dpkg/available ~$ du -h $avail 3.4M /var/lib/dpkg/available ~$ grep Package: $avail | wc -l 4698 An entry in Debian's available DB looks like this... Package: python-zlib Priority: optional Section: interpreters Installed-Size: 80 Maintainer: Gregor Hoffleit Architecture: i386 Source: python Version: 1.5.2-10 Depends: python-base (= 1.5.2-10), libc6 (>= 2.1.2), libz1 Filename: dists/potato/main/binary-i386/interpreters/python-zlib_1.5.2-10.deb Size: 16578 MD5sum: 7226b0d0edf21374c1b09295c0d9497b Description: A compression module for Python using zlib. A compression module for Python using the zlib library. zlib implements the deflate compression method used in gzip and pkzip. ...megabytes perhaps. Of course if someone is querying for what is available they should be expecting a lot of information. Killing two birds with one stone... It's not quite as bad as you think. If the server can spit out a file containing the above info for each package, you are partially apt-get-able; the other part is returning the properly formatted package when you get a request for the Filename: URI. - Bruce From bsass@freenet.edmonton.ab.ca Fri Mar 2 10:10:03 2001 From: bsass@freenet.edmonton.ab.ca (Bruce Sass) Date: Fri Mar 2 10:10:03 2001 Subject: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: <20010228170725.B1781@tummy.com> Message-ID: > >Interestingly, developers probably don't "expect" to have to include > >dependency information, and hence many don't - resulting in the problems you > > I think we can deal with that in an iterative manner. First get them to build > distutils packages, then when it fails to install on some user's machine > because they don't have foo.py we can educate them on the joys of listing > third-party module requirements. Has anyone written a program that looks at a .py and tries to determine the versions of Python it will work with? Maybe have a module that grabs info about the system the code is being developed on, then use some of that to generate default dependencies which the developer can modify (be made less restrictive in most cases, I imagine) before submitting the package to the archive. Even if the developer doesn't modify the dependencies, the user will at least have some idea of what is required. - Bruce From jafo@tummy.com Fri Mar 2 12:04:02 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Fri Mar 2 12:04:02 2001 Subject: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: <20010302091545.DD722373C95@snelboot.oratrix.nl>; from jack@oratrix.nl on Fri, Mar 02, 2001 at 10:15:45AM +0100 References: <20010302091545.DD722373C95@snelboot.oratrix.nl> Message-ID: <20010302095103.C7084@tummy.com> On Fri, Mar 02, 2001 at 10:15:45AM +0100, Jack Jansen wrote: >Right, but an IDE can do better. For instance, if an import fails it can offer >to do a lookup on the packages site to see whether such a package is The client program is in python, so I don't forsee any problems with integrating the functionality in an IDE or whatnot. Sean -- Good idea: Slaves Girls of Gor Bad idea: Slave Girls of Al Gore. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From paulp@ActiveState.com Fri Mar 2 19:03:01 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Fri Mar 2 19:03:01 2001 Subject: [Distutils] Custom "build steps" Message-ID: <3AA0357C.F4EBC639@ActiveState.com> What's the best way to extend distutils with "custom steps" like a call to an IDL compiler or an M4 pre-process? I could just put all of the code in my setup.py but it seems very inelegant and not necessarily always effective (i.e. what if I have to do a post-process between the build and install step?) Is there a technique I can use? -- Vote for Your Favorite Python & Perl Programming Accomplishments in the first Active Awards! http://www.ActiveState.com/Awards From Mike.Olson@fourthought.com Sat Mar 3 03:46:05 2001 From: Mike.Olson@fourthought.com (Mike Olson) Date: Sat Mar 3 03:46:05 2001 Subject: [Distutils] Custom "build steps" References: <3AA0357C.F4EBC639@ActiveState.com> Message-ID: <3AA0ADFC.EA97E6B@FourThought.com> Paul Prescod wrote: We do this for IDL and ODL files in 4Suite. you can check it out in the DistExt.py. Its in the admin directory (and installed into Ft.Lib). Mike > > What's the best way to extend distutils with "custom steps" like a call > to an IDL compiler or an M4 pre-process? I could just put all of the > code in my setup.py but it seems very inelegant and not necessarily > always effective (i.e. what if I have to do a post-process between the > build and install step?) Is there a technique I can use? > > -- > Vote for Your Favorite Python & Perl Programming > Accomplishments in the first Active Awards! > http://www.ActiveState.com/Awards > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com (303)583-9900 x 102 Fourthought, Inc. http://Fourthought.com Software-engineering, knowledge-management, XML, CORBA, Linux, Python From enrico.sirola@riskmap.net Mon Mar 5 07:38:02 2001 From: enrico.sirola@riskmap.net (Enrico Sirola) Date: Mon Mar 5 07:38:02 2001 Subject: [Distutils] Distutils suggestion - test action In-Reply-To: "Thomas Heller"'s message of "Wed, 28 Feb 2001 16:46:06 +0100" References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD45@UKRUX002.rundc.uk.origin-it.com> <20010228074901.A17704@newcnri.cnri.reston.va.us> <03a901c0a19d$903eb520$e000a8c0@thomasnotebook> Message-ID: <87g0u5bnj0.fsf@sirola01.risk> >>>>> "Thomas" == Thomas Heller writes: Thomas> I still have this code in one of my setup-scripts, the Thomas> original version should be still in the archives, also Thomas> some discussion about a test command: Ah! This is just what I needed. I've read the distutils' docs on www.python.org, but the "Extending the distutils" chapter is empty. I do i use this test class from a setup.py? Thanks, Enrico -- Enrico Sirola Key fingerprint = B446 7332 ED55 BC68 5FE8 DE0F 98DF EC86 377F E07F From Paul.Moore@uk.origin-it.com Mon Mar 5 08:31:01 2001 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Mon Mar 5 08:31:01 2001 Subject: [Distutils] Distutils suggestion - test action Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AD72@UKRUX002.rundc.uk.origin-it.com> From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > > I still have this code in one of my setup-scripts, > the original version should be still in the archives, > also some discussion about a test command: I found the discussion. It looked good, but it seemed to peter out without consensus or any action. Can I suggest that *something* needs to be built in, even if it is minimal. Users can always override the default with something more complex, if they need to (or want to). My personal preference is to go with something like Greg Ward's suggestions, based on the Perl test harness. But there was never any code implemented to support this. Your version, if I understand it, simply imports each test module and runs its test() routine. I'm not too happy that the "OK/Not OK" reporting is left solely to the test routine - I'd rather there be a standard format. But maybe that's a job for a standard "test harness" module, rather than for the distutils command. Your version also seems to include code coverage reporting (which I *like*!!) but I can't find the code_coverage module in my distribution - is it a local module? But as I said, I'd rather see your version (with all my reservations) included and standard, than have nothing at all. Paul. From thomas.heller@ion-tof.com Mon Mar 5 09:04:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Mar 5 09:04:01 2001 Subject: [Distutils] Distutils suggestion - test action References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD45@UKRUX002.rundc.uk.origin-it.com><20010228074901.A17704@newcnri.cnri.reston.va.us><03a901c0a19d$903eb520$e000a8c0@thomasnotebook> <87g0u5bnj0.fsf@sirola01.risk> Message-ID: <00d401c0a579$53b1a1f0$e000a8c0@thomasnotebook> (I think the following should go into the docs. Comments?) [Enrico Sirola] > Ah! This is just what I needed. I've read the distutils' docs on > www.python.org, but the "Extending the distutils" chapter is empty. I > do i use this test class from a setup.py? > Thanks, > Enrico First you have to make the test class known to the setup-script: setup(..., cmd_class = {'test': test}, ...) This allows to run 'python setup.py test', and since the 'run' method of the test class contains a call to build self.run_command('build'), the build step will be run first, and then your test. If you want the 'test'-step always be run at the end of the build-steps, you can install 'test' as a sub-command of build (Remove or comment-out the "self.run_command('build')" line before trying this, otherwise test and build would call each other recursively) in this way: from distutils.command import build build.build.sub_commands.append(('test', None)) setup(.....) You could replace the 'None' above by a method test.has_tests() for example which would answer true if there are test cases, false otherwise. Regards, Thomas From enrico.sirola@riskmap.net Mon Mar 5 09:50:02 2001 From: enrico.sirola@riskmap.net (Enrico Sirola) Date: Mon Mar 5 09:50:02 2001 Subject: [Distutils] Distutils suggestion - test action In-Reply-To: "Thomas Heller"'s message of "Mon, 5 Mar 2001 14:36:46 +0100" References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD45@UKRUX002.rundc.uk.origin-it.com> <20010228074901.A17704@newcnri.cnri.reston.va.us> <03a901c0a19d$903eb520$e000a8c0@thomasnotebook> <87g0u5bnj0.fsf@sirola01.risk> <00d401c0a579$53b1a1f0$e000a8c0@thomasnotebook> Message-ID: <87u2596qqg.fsf@sirola01.risk> >>>>> "Thomas" == Thomas Heller writes: Thomas> (I think the following should go into the docs. Thomas> Comments?) Thomas> [Enrico Sirola] >> Ah! This is just what I needed. I've read the distutils' docs >> on www.python.org, but the "Extending the distutils" chapter is >> empty. I do i use this test class from a setup.py? Thanks, >> Enrico Thomas> First you have to make the test class known to the Thomas> setup-script: Thomas> setup(..., cmd_class = {'test': test}, ...) Thomas> This allows to run 'python setup.py test', and since the Thomas> 'run' method of the test class contains a call to build Thomas> self.run_command('build'), the build step will be run Thomas> first, and then your test. Thomas> If you want the 'test'-step always be run at the end of Thomas> the build-steps, you can install 'test' as a sub-command Thomas> of build (Remove or comment-out the Thomas> "self.run_command('build')" line before trying this, Thomas> otherwise test and build would call each other Thomas> recursively) in this way: Thomas> from distutils.command import build Thomas> build.build.sub_commands.append(('test', None)) Thomas> setup(.....) Thomas> You could replace the 'None' above by a method Thomas> test.has_tests() for example which would answer true if Thomas> there are test cases, false otherwise. thanks a lot, i just tried and it works quite well, Enrico -- Enrico Sirola Key fingerprint = B446 7332 ED55 BC68 5FE8 DE0F 98DF EC86 377F E07F From Pearu Peterson Tue Mar 6 14:14:01 2001 From: Pearu Peterson (Pearu Peterson) Date: Tue Mar 6 14:14:01 2001 Subject: [Distutils] Using boost with distutils Message-ID: Hi! I am trying to use distutils with boost (www.boost.org) on MD 7.0 Linux and with gcc 2.95.2. When compiling/linking C++ codes, distutils uses gcc compiler. But then importing shared module fails (it cannot find `cerr'). When I manually used g++ for compiling/linking, import succeeded. Now I use the following code fragment ++++++++++++++++++++++++++++++++++++++++++++++ from distutils import sysconfig save_init_posix = sysconfig._init_posix def my_init_posix(): print 'my_init_posix: changing gcc to g++' save_init_posix() g = sysconfig._config_vars g['CC'] = 'g++' g['LDSHARED'] = 'g++ -shared' sysconfig._init_posix = my_init_posix +++++++++++++++++++++++++++++++++++++++++++++ in my setup.py file. I am wondering if there is a "nicer" way to change compiler and linker program in setup.py? If a package contains both C and C++ codes, then the above will not work. Any ideas how to build such mixed extension modules? And I'll appreciate an example setup.py that uses boost. Pearu From amos@digicool.com Fri Mar 9 21:08:01 2001 From: amos@digicool.com (Amos Latteier) Date: Fri Mar 9 21:08:01 2001 Subject: [Distutils] [PATCH] Write distribution meta-data an XML file Message-ID: Hi Guys, I've added a patch on sourceforge to allow distribution meta-data to be written to an XML file. This should help the catalog effort. http://sourceforge.net/tracker/index.phpfunc=detail&aid=407434&group_id=5470&atid=305470 The reason for the patch is that I've found out that it's hard to extract distribution meta-data by running setup.py. Often setup.py will not run if you don't have the required environment. Also, there is an inherent security problem in running setup.py to extra meta-data if you don't trust the distribution. By writing meta-data to a file programs like the catalog can find out the meta-data of a distribution without running any distribution code. In fact all they'll have to do is this: from distutils.dist import DistributionMetadata m=DistributionMetadata() f=open('metadata.xml', 'rb') m.read_data(f) f.close() # At this point m is a dictionary mapping # meta-data names to values -Amos P.S. I am not attached to any paticular format for the meta-data file. I chose XML since it seemed reasonable and easy. I also considered RFC822. In any event, if we decide that another format is better, all that is needed is to change the 'write_data' and 'read_data' methods on the DistributionMetadata class. From paulp@ActiveState.com Fri Mar 9 21:37:01 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Fri Mar 9 21:37:01 2001 Subject: [Distutils] [PATCH] Write distribution meta-data an XML file References: Message-ID: <3AA9940A.684E4CB1@ActiveState.com> Amos, we had agreed to this step at the conference. Great mind reading! I agreed to send information about some potential existing XML formats. Programmer's Package Description (PPD) is defined here: http://velocity.activestate.com/docs/ActivePerl/site/lib/XML/PPD.html PPD is based on OSD: http://www.w3.org/TR/NOTE-OSD.html which is a pseudo-standard that never got much traction. Some PPD files are here: http://ppm.activestate.com/PPMPackages/PyPPM/2.0/ I've also stumbled across this one: http://www.asp-shareware.org/pad/ There is a link to examples on that page... -- Python: Programming the way Guido indented it. From amos@digicool.com Sat Mar 10 00:36:00 2001 From: amos@digicool.com (Amos Latteier) Date: Sat Mar 10 00:36:00 2001 Subject: [Distutils] [PATCH] Write distribution meta-data an XML file In-Reply-To: <3AA9940A.684E4CB1@ActiveState.com> Message-ID: > Amos, we had agreed to this step at the conference. Great > mind reading! Actually it you guys who were reading my mind ;-) > I agreed to send information about some potential > existing XML formats. Let's first figure out our requirements. My main concern is to allow the catalog to get access to a distribution's meta-data. I don't think that it's too important to choose an existing stardard because we already have a distutils meta-data schema (though not a standard XML representation of it) and I don't see much need to communicate distutils distribution meta-data to existing systems (with the exception of the Vaults of Parnasus - though I don't think it has any support for this now). Perhaps others disagree. Given these requirements, I think that the home-cooked format that I proposed is fine. BTW, for those who haven't checked out the patch here an example of the format: name Distutils version 1.0.1 ... This format has the advantages of not requiring that meta-data names be legal XML element names. It also does not impose any particular meta-data schema. It just requires that meta-data consist of a sequence of name, value pairs. If we adapt an existing format it will probably require changing the meta-data schema that the distutils currently use. My guess is that unless this buys us compatibility with some useful existing system it will not be worth it, considering how hard-coded the existing meta-data schema seems to be within the distutils code. > Programmer's Package Description (PPD) is defined here: > > http://velocity.activestate.com/docs/ActivePerl/site/lib/XML/PPD.html This has some Perl specific stuff. It also uses different meta-data than the distutils currently does. I'm not sure if this format has much to offer us. > PPD is based on OSD: > > http://www.w3.org/TR/NOTE-OSD.html > > which is a pseudo-standard that never got much traction. Are there any systems that use this format? It has some interesting features, but again, I don't think it maps very well onto the existing distutils meta-data schema. > I've also stumbled across this one: > > http://www.asp-shareware.org/pad/ This seems again to be more complex than we need, and does't seem to map well onto the existing meta-data schema, and doesn't seem to be used by any relevant systems. I think the real question is whether we want to change the distutils meta-data schema or not. Meta-data schemas seem to be a contentious issue. I don't have any stong feelings on the matter. I just want to make meta-data easily available outside setup.py. -Amos From paulp@ActiveState.com Sat Mar 10 00:58:01 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Sat Mar 10 00:58:01 2001 Subject: [Distutils] Re: Write distribution meta-data an XML file References: Message-ID: <3AA9C342.161750E4@ActiveState.com> Amos Latteier wrote: > > ... > > > This format has the advantages of not requiring that > meta-data names be legal XML element names. It also does not > impose any particular meta-data schema. It just requires > that meta-data consist of a sequence of name, value pairs. It is kind of verbose and consequently somewhat hard to read. I also think that defining a schema is one of the central goals. If everyone chooses their own metadata item names then there is no value in having a "standard" format. If everyone is supposed to use standard names then why not use compact, friendly-named element types. That also offers the possibility of DTD or schema validation, rich editing in XML editors etc. > If we adapt an existing format it will probably require > changing the meta-data schema that the distutils currently > use. My guess is that unless this buys us compatibility with > some useful existing system it will not be worth it, > considering how hard-coded the existing meta-data schema > seems to be within the distutils code. There isn't any requirement that the internal names and the XML names be the same. > > Programmer's Package Description (PPD) is defined here: > > > > http://velocity.activestate.com/docs/ActivePerl/site/lib/XML/PPD.html > > This has some Perl specific stuff. There is something called "PERLCORE" (which isn't used in practice). We would replace it with PYTHONCORE if we decided to use it. > ... > Meta-data schemas seem to be a contentious issue. I don't > have any stong feelings on the matter. I just want to make > meta-data easily available outside setup.py. I feel the same way but I think we want to do it in a way that feels natural as XML. Your model is really distutils metadata rendered as RFC: 822 which is in turn rendered as XML. And even if you were going to render 822 as XML, it would be more traditional to use name and value attributes and reduce the file size... Your model might be better for proprietary extensions TO the metadata format. .. ... -- Python: Programming the way Guido indented it. From paulp@ActiveState.com Sat Mar 10 06:48:01 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Sat Mar 10 06:48:01 2001 Subject: [Distutils] Uninstalling Message-ID: <3AAA1534.B729F9E5@ActiveState.com> I'd like to suggest the convention that uninstall logs be placed in an "uninstall" directory. Python top-level directories are messy enough as it is. The convention and syntax described here is fine with me: http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html All install commands should generate the appropriate logs. It should also be possible to insert an uninstall/remove_packagename.py for undoing-anything unusual (e.g. if the install modified an Apache config file or something). remove_packagename.py functions should be exceedingly rare but at ActiveState we have taken the position that people should be able to do arbitrary things in installers and uninstallers....more on that later... -- Python: Programming the way Guido indented it. From paulp@ActiveState.com Sat Mar 10 06:54:00 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Sat Mar 10 06:54:00 2001 Subject: [Distutils] Post-install scripts Message-ID: <3AAA168C.5380D192@ActiveState.com> Is there a convention for shipping post-install scripts through distutils? We've taken the route of simply shipping the setup.py with the PPM. Pre- or post- or even mid-install commands can go in that script. I'd like to know what the other bdist_*'s do. I see something about an install_script in the RPM one but I don't understand it well enough to know what it is really doing. Even though Python PPM is only a week old, we've already taken advantage of this feature to install packages that have both Python and Perl components. I'd like to use a shared convention so that module authors can depend upon it. "Good" bdist_ commands should have a way to launch a post-install script. The same should go for uninstall... -- Python: Programming the way Guido indented it. From amos@digicool.com Sat Mar 10 13:19:20 2001 From: amos@digicool.com (Amos Latteier) Date: Sat Mar 10 13:19:20 2001 Subject: [Distutils] [PATCH] Write distribution meta-data an XML file In-Reply-To: <3AA9940A.684E4CB1@ActiveState.com> Message-ID: You make some good points about the DTD. Ultimately I don't care what the DTD looks like. The only use case I am considering is that of the catalog parsing a meta-data file to get information about a distribution. The requirements for this are that distutils provide a standard way to read and write meta-data to a file, that all distribtions include this meta-data file, and that it is safe to read an untrusted meta-data file. Do you have other use cases that we should consider? To repeat, though, I think the only important decision is whether or not to change the distutils meta-data schema. >From your suggested list of DTDs I gather that you are considering changing the meta-data schema. That's fine, but if we decide to do that I'd like to know why. BTW, can you summarize what was decided at the conference? Thank! -Amos From paulp@ActiveState.com Sat Mar 10 13:56:27 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Sat Mar 10 13:56:27 2001 Subject: [Distutils] [PATCH] Write distribution meta-data an XML file References: Message-ID: <3AAA64C1.51FDB9E7@ActiveState.com> Amos Latteier wrote: > > You make some good points about the DTD. Ultimately I don't > care what the DTD looks like. The only use case I am > considering is that of the catalog parsing a meta-data file > to get information about a distribution. The requirements > for this are that distutils provide a standard way to read > and write meta-data to a file, that all distribtions include > this meta-data file, and that it is safe to read an > untrusted meta-data file. Do you have other use cases that > we should consider? I think that behind the word "standard" we need a more formal list of what is and isn't required, what is and isn't allowed and so forth. I don't think that this is a valid meta-data file: One of my use cases is mirroring the repository and building sub-repositories based on license. Therefore I would like to see license be a mandatory tag. Probably you could type but at least you will have made a choice (there is a ton of Python code out there with no clear license at all!). I would also like "name" to be required (it isn't in distutils). If someone uploads a file to a catalog with no name, "UNKNOWN-0.10.2.win32.zip", what are we supposed to do with that? > To repeat, though, I think the only important decision is > whether or not to change the distutils meta-data schema. > From your suggested list of DTDs I gather that you are > considering changing the meta-data schema. That's fine, but > if we decide to do that I'd like to know why. I don't know exactly what you mean when you talk about changing the metadata schema. If we serialize author as Author, have we changed the schema? If we serialize author as Creator, have we changed the schema? In general you need a mapping between the internal form of the information and the serialized form. As you see above, I would like to rethink which parts of the metadata are required and optional. So yes, I guess this implies some internal schema change insofar as I am asking for the schema to be a little bit more prescriptive. > BTW, can you summarize what was decided at the conference? We primarily decided that we needed to come up with an XML format and that someone would implement a tool that generated the XML after we had decided on the format. I promised to forward some example formats that we could use as starting points. -- Python: Programming the way Guido indented it. From akuchlin@mems-exchange.org Sat Mar 10 15:03:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat Mar 10 15:03:01 2001 Subject: [Distutils] Tasks arising from IPC9 Message-ID: Various events related to the Catalog- and Distutils-SIG happened at IPC9 this past week. To summarize them: * Sean Reifschneider demonstrated swalow during the Lightning Talks session and got a favorable reaction from the attendees. * Packaging was discussed at Paul Prescod's BoF session, and some decisions were made there. (More about that below...) * On Developer's Day, Moshe turned over half of his "Batteries Included" session to me for catalog discussion, and a few more items were added to the task list. So, here's the plan of action: 1) For 2.1final, change the Distutils sdist command to construct a text file containing the metadata for a package. Exactly *what* metadata to collect was left open for subsequent discussion on the Catalog-SIG. (Amos has a patch to implement this that I'll look at when I can.) This is the only thing to be done in time for 2.1, so it's the only really pressing task. 2) Once that metadata support is there, someone can start running an experimental swalow server and begin adding to its database. If Python 2.2 comes along in 6-12 months, that should be enough time to have an idea of what should go into 2.2 to support it. 3) Other Distutils changes would be to design and create a package database, and implement an uninstall command. The 'sdist' command would also grow an --upload or --register option that would automatically submit the package to the catalog (but first we'd need to finalize how that should be done). I'll make a separate post to start the metadata discussion. --amk From akuchlin@mems-exchange.org Sat Mar 10 15:58:00 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat Mar 10 15:58:00 2001 Subject: [Distutils] Metadata fields Message-ID: Following the IPC9 discussion, let's continue the thread on metadata. Here's a list I posted to the Catalog-SIG back in November. Information about a package =========================== Name Version Supported Platforms Description Keywords Homepage URL Author IDs License Download link Date of release Leaving out for now: dependency information, except perhaps as just a text field Information about an author =========================== Name Home page GnuPG/PGP key (both the actual key, and just the ID) E-mail address (used as ID?) E-mail address public: y/n 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. 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 plan to write this up as a PEP, and explain the contents and semantics of each field in detail. Comparison with OSD =================== Additional fields in OSD: LANGUAGE: for the implementation language, I assume, and not the human language it's documented in? OS, OSVERSION: operating system required to run this package. PYTHONCORE: Version of Python required to run this package. PROCESSOR: CPU required to run this package. CODEBASE, INSTALL, UNINSTALL: references to downloadable code, to an install script, to an uninstall script. Given the existence of the Distutils, the last 3 fields all collapse down into the code's location. PROCESSOR seems only marginally useful (can you name a Python extension that runs on only one processor?), but leaving it in is no big deal. OSD does not have fields for keywords or for a release date. Looking at the PAD format, there's little new there that's applicable; about the only thing is a field to indicate if a release is a minor or major update (perhaps there's a 'Security Bug' value, too). --amk From akuchlin@mems-exchange.org Sat Mar 10 16:37:00 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat Mar 10 16:37:00 2001 Subject: [Distutils] [PATCH] Write distribution meta-data an XML file In-Reply-To: ; from amos@digicool.com on Sat, Mar 10, 2001 at 11:55:37AM -0500 References: <3AA9940A.684E4CB1@ActiveState.com> Message-ID: <20010310163616.A4583@ute.cnri.reston.va.us> On Sat, Mar 10, 2001 at 11:55:37AM -0500, Amos Latteier wrote: >To repeat, though, I think the only important decision is >whether or not to change the distutils meta-data schema. >From your suggested list of DTDs I gather that you are >considering changing the meta-data schema. That's fine, but >if we decide to do that I'd like to know why. I don't think anything will change very seriously; most likely it's just a matter of adding a few fields and clarifying their semantics. Looking at PPD again, the only reason the tree-structure capabilities of XML are needed at all is because there can be multiple IMPLEMENTATION elements. It's not clear to me how useful this is, and if it's dropped, then RFC-822 headers can be used instead of XML. --amk From c.evans@clear.net.nz Sat Mar 10 17:05:00 2001 From: c.evans@clear.net.nz (Carey Evans) Date: Sat Mar 10 17:05:00 2001 Subject: [Distutils] Re: Write distribution meta-data an XML file In-Reply-To: <3AA9C342.161750E4@ActiveState.com> References: <3AA9C342.161750E4@ActiveState.com> Message-ID: <87r9051ds3.fsf@psyche.dnsalias.org> Paul Prescod writes: [...] > Your model might be better for proprietary extensions TO the metadata > format. > > > .. > ... > > Wouldn't this sort of thing be done better by letting proprietary extensions use their own namespaces? For example, parrot 0.9n -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Quiet, you'll miss the humorous conclusion." From amos@digicool.com Mon Mar 12 00:22:01 2001 From: amos@digicool.com (Amos Latteier) Date: Mon Mar 12 00:22:01 2001 Subject: [Distutils] Metadata fields Message-ID: 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 From thomas.heller@ion-tof.com Mon Mar 12 07:26:00 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Mar 12 07:26:00 2001 Subject: [Distutils] Post-install scripts References: <3AAA168C.5380D192@ActiveState.com> Message-ID: <026201c0aaef$714707c0$e000a8c0@thomasnotebook> > Is there a convention for shipping post-install scripts through > distutils? We've taken the route of simply shipping the setup.py with > the PPM. Pre- or post- or even mid-install commands can go in that > script. I'd like to know what the other bdist_*'s do. I see something > about an install_script in the RPM one but I don't understand it well > enough to know what it is really doing. install_script is a standard distutils command. Distutils installs these components: install_lib - pure python modules plus extension modules install_data - data files install_scripts - python files to be used as scripts install_headers - header files for extension modules So install_scripts has nothing to do with the installation process. > > Even though Python PPM is only a week old, we've already taken advantage > of this feature to install packages that have both Python and Perl > components. I'd like to use a shared convention so that module authors > can depend upon it. "Good" bdist_ commands should have a way to launch a > post-install script. The same should go for uninstall... I plan to support this in a new version of bdist_wininst. Thomas From thomas.heller@ion-tof.com Mon Mar 12 07:36:32 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Mar 12 07:36:32 2001 Subject: [Distutils] Uninstalling References: <3AAA1534.B729F9E5@ActiveState.com> Message-ID: <026801c0aaf0$e9c66460$e000a8c0@thomasnotebook> > I'd like to suggest the convention that uninstall logs be placed in an > "uninstall" directory. Python top-level directories are messy enough as > it is. The convention and syntax described here is fine with me: > > http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html > In addition to these entries 020 Reg DB Key: 040 Reg DB Value: 100 Made Dir: 200 File Copy: 200 File Overwrite: I plan to support additional logfile entries as well (has also been suggested by Marc Hammond in private mail) 020 Reg DB Tree: HKLM\Software\.... 100 File Tree: c:\python20\mydata\*.dat 100 File Tree: c:\python20\mydata to recursively delete a key in the registry, or to recursively delete files matching the mask, or removing a directory even if it would contain subdirectories and/or files. An entry like 600 Run Script: c:\python\Distutils\cleanup.py or 600 Run Program: c:\blabla.exe --remove could be used to trigger a script or an exe which will cleanup additional things (unregistering COM-servers comes to mind). > All install commands should generate the appropriate logs. Sounds easy. > It should > also be possible to insert an uninstall/remove_packagename.py for > undoing-anything unusual (e.g. if the install modified an Apache config > file or something). remove_packagename.py functions should be > exceedingly rare but at ActiveState we have taken the position that > people should be able to do arbitrary things in installers and > uninstallers....more on that later... > How would this logfile be used? Should distutils contain a clean-up command for this? Thomas From paulp@ActiveState.com Mon Mar 12 08:47:01 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Mon Mar 12 08:47:01 2001 Subject: [Distutils] Uninstalling References: <3AAA1534.B729F9E5@ActiveState.com> <026801c0aaf0$e9c66460$e000a8c0@thomasnotebook> Message-ID: <3AACD3FE.A3318099@ActiveState.com> Thomas Heller wrote: > > ... > > > It should > > also be possible to insert an uninstall/remove_packagename.py for > > undoing-anything unusual (e.g. if the install modified an Apache config > > file or something). remove_packagename.py functions should be > > exceedingly rare but at ActiveState we have taken the position that > > people should be able to do arbitrary things in installers and > > uninstallers....more on that later... > > > How would this logfile be used? Should distutils contain a clean-up > command for this? I'm confused. You quote a bunch of text talking about remove_package.py but then you ask about the logfile? I think distutils should have an uninstall command to provide a default implementation just as there is an install command. uninstall should undo everything it did by reading the logfile. If there happens to be a remove_packagename.py, distutils should run it before doing the file/registry uninstall. -- Python: Programming the way Guido indented it. - (originated with Skip Montanaro?) From dyoo@hkn.eecs.berkeley.edu Mon Mar 12 10:23:05 2001 From: dyoo@hkn.eecs.berkeley.edu (Daniel Yoo) Date: Mon Mar 12 10:23:05 2001 Subject: [Distutils] Re: [Python-Help] help with distutils (fwd) Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --545289610-825307379-984410576=:16386 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm forwarding this message to the distutils people; apparently, someone wants to allow spaces within recursive-include pathnames. To allow this, I've written a small "splitWithQuotes()" function that handles this sort of weird string splitting. There's probably a much better way to write this mini-parser (can we employ Python's line parser?), but in any case, I had fun writing this. If we replace the call to spring.split() in _parse_template_line (filelist.py): ### def _parse_template_line (self, line): words = string.split(line) ### with words = splitwithquotes(line) this should allow Dmitry's recursive-include to work, if everything else holds together (which it might not. *grin*) Is this feasible? ---------- Forwarded message ---------- Date: Mon, 12 Mar 2001 06:27:32 -0800 (PST) From: Daniel Yoo To: Balabanov Dmitry Cc: help@python.org Subject: Re: [Python-Help] help with distutils On Sat, 10 Mar 2001, Balabanov Dmitry wrote: > Hi!! > Problem is very simple but i can't solve it... > I have such string in MANIFEST.in: > recursive-include 'Max Fray' *.txt > But `python setup.py sdist --manifest-only` spawns: > running sdist > warning: sdist: missing required meta-data: url > reading manifest template 'MANIFEST.in' > warning: no files found matching 'Fray'' under directory ''Max' > warning: no files found matching '*.txt' under directory ''Max' > writing manifest file 'MANIFEST' First of all, apologies for the very late response. It's been a long week. Hmmm.. the problem is that the DistUtils assume that the directories don't have a space in them. That's why it's parsing the directories incorrectly. Specifically, the problem lies in the function _parse_template_line() in filelist.py of the Python Distutils, around line 111 --- they use a simple string.split(), which doesn't look at quoted directories. That's why we're getting those weird error messages. Given this, I'm not quite sure what the elegant solution to this would be. Is it possible to rename the directory "Max Fray" to Max_Fray without too much pain? Also, please contact the DistUtils SIG at: http://mail.python.org/mailman/listinfo/distutils-sig The best way to solve this is to get the distutils to be a little smarter when it comes to reading in those manifest lines; I'll see if I have time to provide a patch to this later. _______________________________________________ Python-Help maillist - Python-Help@python.org http://mail.python.org/mailman/listinfo/python-help --545289610-825307379-984410576=:16386 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="splitwithquotes.py" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="splitwithquotes.py" IiIiVGhpcyBwYXJzZXIgYWN0cyBsaWtlIHN0cmluZy5zcGxpdCgpLCBidXQg d2l0aCB0aGUgYWRkaXRpb25hbA0KYmVoYXZpb3IgdGhhdCBzdHVmZiBpbiBx dW90ZXMgd29ya3MuDQoNCkZvciBmdW4sIEknbGwgc2VlIGlmIEkgY2FuIGRv IHRoaXMgd2l0aG91dCByZWd1bGFyIGV4cHJlc3Npb25zLiAgSQ0Ka25vdyB0 aGF0IHVzaW5nIHJlZ3VsYXIgZXhwcmVzc2lvbnMgd2lsbCBiZSBhIGxvdCBt b3JlIGNvbXBhY3QsIGJ1dCBJDQpuZWVkIG1vcmUgZXhwZXJpZW5jZSB3aXRo IHBhcnNpbmcgcHJvZ3JhbXMgKGZvciBhIHBlcnNvbmFsIHByb2plY3QpLg0K IiIiDQoNCmZyb20gc3RyaW5nIGltcG9ydCB3aGl0ZXNwYWNlDQoNClNQQUNF UyA9IHdoaXRlc3BhY2UNClFVT1RFUyA9ICdcJyInDQoNCmRlZiBzcGxpdFdp dGhRdW90ZXMobGluZSk6DQogICAgcCA9IF9QYXJzZXIoKQ0KICAgIHJldHVy biBwKGxpbmUpDQoNCmNsYXNzIF9QYXJzZXI6DQogICAgZGVmIF9faW5pdF9f KHNlbGYpOg0KICAgICAgICBzZWxmLml0ZW1zID0gW10NCiAgICAgICAgc2Vs Zi50b2tlbnMgPSBbXQ0KDQogICAgZGVmIG5ldXRyYWwoc2VsZik6DQogICAg ICAgIHdoaWxlIHNlbGYudG9rZW5zIGFuZCBzZWxmLnRva2Vuc1swXSBpbiBT UEFDRVM6IHNlbGYudG9rZW5zLnBvcCgwKQ0KICAgICAgICBpZiBzZWxmLnRv a2VucyBhbmQgc2VsZi50b2tlbnNbMF0gaW4gUVVPVEVTOiBzZWxmLnJlYWRp bmdTdHJpbmdzKCkNCiAgICAgICAgZWxpZiBzZWxmLnRva2Vuczogc2VsZi5y ZWFkaW5nQ2hhcmFjdGVycygpDQoNCiAgICAjIyBOb3RlOiB0aGlzIGRvZXNu J3QgdGFrZSBjYXJlIG9mIGVzY2FwZWQgcXVvdGVzIHlldC4NCiAgICBkZWYg cmVhZGluZ1N0cmluZ3Moc2VsZik6DQogICAgICAgIHNlbGYudG9rZW5zLnBv cCgwKSAgICMgdGFrZSBvdXQgbGVhZGluZyBxdW90ZQ0KICAgICAgICBuZXdp dGVtID0gW10NCiAgICAgICAgd2hpbGUgc2VsZi50b2tlbnNbMF0gbm90IGlu IFFVT1RFUzoNCiAgICAgICAgICAgIGlmIHNlbGYuaXNFc2NhcGVkUXVvdGUo KToNCiAgICAgICAgICAgICAgICBuZXdpdGVtLmFwcGVuZChzZWxmLnRva2Vu cy5wb3AoMSkpDQogICAgICAgICAgICAgICAgc2VsZi50b2tlbnMucG9wKDAp DQogICAgICAgICAgICBlbHNlOg0KICAgICAgICAgICAgICAgIG5ld2l0ZW0u YXBwZW5kKHNlbGYudG9rZW5zLnBvcCgwKSkNCiAgICAgICAgc2VsZi5pdGVt cy5hcHBlbmQoJycuam9pbihuZXdpdGVtKSkNCiAgICAgICAgc2VsZi50b2tl bnMucG9wKDApICAgIyB0YWtlIG91dCB0cmFpbGluZyBxdW90ZQ0KDQogICAg ZGVmIHJlYWRpbmdDaGFyYWN0ZXJzKHNlbGYpOg0KICAgICAgICBuZXdpdGVt ID0gW10NCiAgICAgICAgd2hpbGUgc2VsZi50b2tlbnMgYW5kIHNlbGYudG9r ZW5zWzBdIG5vdCBpbiBTUEFDRVM6DQogICAgICAgICAgICBuZXdpdGVtLmFw cGVuZChzZWxmLnRva2Vucy5wb3AoMCkpDQogICAgICAgIHNlbGYuaXRlbXMu YXBwZW5kKCcnLmpvaW4obmV3aXRlbSkpDQoNCiAgICBkZWYgX19jYWxsX18o c2VsZiwgbGluZSk6DQogICAgICAgIHNlbGYuaXRlbXMgPSBbXQ0KICAgICAg ICBzZWxmLnRva2VucyA9IGxpc3QobGluZSkNCiAgICAgICAgd2hpbGUgc2Vs Zi50b2tlbnM6DQogICAgICAgICAgICBzZWxmLm5ldXRyYWwoKQ0KICAgICAg ICByZXR1cm4gc2VsZi5pdGVtcw0KDQogICAgZGVmIGlzRXNjYXBlZFF1b3Rl KHNlbGYpOg0KICAgICAgICByZXR1cm4gKGxlbihzZWxmLnRva2VucykgPiAx DQogICAgICAgICAgICAgICAgYW5kIHNlbGYudG9rZW5zWzBdID09ICdcXCcg YW5kIHNlbGYudG9rZW5zWzFdIGluIFFVT1RFUykNCg0KICAgIGRlZiBpc0Vz Y2FwZWRTcGFjZShzZWxmKToNCiAgICAgICAgcmV0dXJuIChsZW4oc2VsZi50 b2tlbnMpID4gMQ0KICAgICAgICAgICAgICAgIGFuZCBzZWxmLnRva2Vuc1sw XSA9PSAnXFwnIGFuZCBzZWxmLnRva2Vuc1sxXSBpbiBXSElURVNQQUNFKQ0K DQppZiBfX25hbWVfXyA9PSAnX19tYWluX18nOg0KICAgIHByaW50IHNwbGl0 V2l0aFF1b3RlcygnaGVsbG8gd29ybGQgdGhpcyAgICBpcyAicXVvdGVkIHRl eHQiICAieWVzISIgYWdhaW4nKQ0KICAgIHByaW50IHNwbGl0V2l0aFF1b3Rl cygnVGhpcyBpcyBhbm90aGVyIHRleHQgd2l0aCAiXFwiY29vbCBxdW90ZWRc XCIiIHRlc3QnKQ0K --545289610-825307379-984410576=:16386-- From thomas.heller@ion-tof.com Mon Mar 12 12:59:13 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Mar 12 12:59:13 2001 Subject: [Distutils] Uninstalling References: <3AAA1534.B729F9E5@ActiveState.com> <026801c0aaf0$e9c66460$e000a8c0@thomasnotebook> <3AACD3FE.A3318099@ActiveState.com> Message-ID: <043601c0ab1e$0573af10$e000a8c0@thomasnotebook> > > How would this logfile be used? Should distutils contain a clean-up > > command for this? > > I'm confused. You quote a bunch of text talking about remove_package.py > but then you ask about the logfile? > Sorry about the bad quotes. > I think distutils should have an uninstall command to provide a default > implementation just as there is an install command. uninstall should > undo everything it did by reading the logfile. If there happens to be a > remove_packagename.py, distutils should run it before doing the > file/registry uninstall. What I mean is: How does the user trigger the uninstall? Does he have to keep the setup.py file to trigger it? Usual sequence: download source distribution, unpack in a temporary directory, run 'setup.py install', delete the source distribution. Use the package, decide that it's not worth to be kept, but now the setup.py file is gone... Thomas From robin@alldunn.com Mon Mar 12 14:59:01 2001 From: robin@alldunn.com (Robin Dunn) Date: Mon Mar 12 14:59:01 2001 Subject: [Distutils] Metadata fields References: Message-ID: <00bf01c0ab2e$cf302c60$0100a8c0@Rogue> > > 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. > Perhaps an "alternate download" link. This could be a place the author maintains as a mirror of his own stuff. The catalog will still put the files where it wants, and distribute to catalog mirrors, etc., and the catalog clients will still prefer the catalog locations, but if there is an alternate location to fall back to then it would be nice. -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! From akuchlin@mems-exchange.org Mon Mar 12 15:32:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon Mar 12 15:32:01 2001 Subject: [Distutils] Metadata fields In-Reply-To: ; from amos@digicool.com on Mon, Mar 12, 2001 at 12:24:02AM -0500 References: Message-ID: <20010312153142.A13192@ute.cnri.reston.va.us> On Mon, Mar 12, 2001 at 12:24:02AM -0500, Amos Latteier wrote: >The distutils currently has both a description and a >long_description. I think that both are useful. What's the distinction? Maybe: description is a single line, and long_description is one or more full paragraphs? >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. Hmm... if get_contact_email() is removed, then users of the DistributionMetadata class will have to essentially repeat the same 'if maintainer is not None: else: ' logic, so I think it's worth keeping. A similar argument applies to fullname. I don't believe you can say fullname='blah' in the setup() call, can you? >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. Good point! It probably shouldn't, since the metadata tells you about the package that you have right here as a tarball/RPM/whatever and the package doesn't need to know where it's supposed to live on the Web. If we make this decision, some consequences are that the multiple implementations permitted by PPD, and hence the need to use XML instead of a simple text file, both vanish from the Distutils' field of view. (Not from the catalog's field of view, of course.) ActiveState's process would then look something like: grab a distribution, parse its metadata, convert the metadata to PPD adding extra things such as the location the package came from, and use the PPD from that point onward. >Finally, maybe you should be able to find out which files a >package installs. Maybe this information is not properly >speaking meta-data. I'm doubtful it can go in source dists, thinking of packages that have optional components. Here's another thing I'm not sure of: does METADATA go in both source and binary distributions? If so, where? Strawman convention: metadata goes in a METADATA file in the top directory of source dists. In binary dists... it should really drop into a Python package database, shouldn't it? >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. So, should we adopt the convention that the e-mail address returned by get_contact_email() can be used as an author-unique ID by external cataloguers? I'll put that in the PEP if the idea meets with approval. --amk From amos@digicool.com Mon Mar 12 16:13:01 2001 From: amos@digicool.com (Amos Latteier) Date: Mon Mar 12 16:13:01 2001 Subject: [Distutils] Metadata fields References: <20010312153142.A13192@ute.cnri.reston.va.us> Message-ID: <3AAD3B9A.C906E5DF@digicool.com> Andrew Kuchling wrote: > > On Mon, Mar 12, 2001 at 12:24:02AM -0500, Amos Latteier wrote: > >The distutils currently has both a description and a > >long_description. I think that both are useful. > > What's the distinction? Maybe: description is a single line, and > long_description is one or more full paragraphs? Exactly. Having both is useful since often the name is not enough to descriptively identify a package. It is often useful to have a one line description when browsing lists of packages, etc. We could do away with description and long description if there was a simple way to get a one line description from a long description. One solution is to just use the first line of the description. This sounds OK, but in practice I bet it wouldn't work well. > >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. > > Hmm... if get_contact_email() is removed, then users of the > DistributionMetadata class will have to essentially repeat the same > 'if maintainer is not None: else: ' > logic, so I think it's worth keeping. A similar argument applies to > fullname. I don't believe you can say fullname='blah' in the setup() > call, can you? I don't believe that currently you can set any derived meta-data. It feels to me that things like contact, download_url, last modified date, size, etc are more method-ish than meta-data-ish. Maybe this is an artificial distinction. Meta-data feels to me like static data that a packager provides, while these other pieces of information seem to require calculation on the part of the catalog. Maybe we shouldn't foist this distinction on the catalog client, though... > >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. > > Good point! It probably shouldn't, since the > metadata tells you about the package that you have right here as a > tarball/RPM/whatever and the package doesn't need to know where it's > supposed to live on the Web. > > If we make this decision, some consequences are that the multiple > implementations permitted by PPD, and hence the need to use XML > instead of a simple text file, both vanish from the Distutils' field > of view. (Not from the catalog's field of view, of course.) > ActiveState's process would then look something like: grab a > distribution, parse its metadata, convert the metadata to PPD adding > extra things such as the location the package came from, and use the > PPD from that point onward. Great point. Using a format like PPD or other known XML formats makes much more sense for communication between the catalog and its clients, than for communication between a package and the catalog. > Here's another thing I'm not sure of: does > METADATA go in both source and binary distributions? If so, where? > Strawman convention: metadata goes in a METADATA file in the top > directory of source dists. In binary dists... it should really drop > into a Python package database, shouldn't it? I'm not sure what you mean by Python package database. In general, it will be hard to put meta-data in a binary distribution in a way that the catalog can easily retrieve it. So I agree that metadata goes in source distributions. The upshot is that if you want to distribute your binary package with the catalog you'll need to also provide a source package, or else provide the metadata manually some how. I think that this is fine for now. > >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. > > So, should we adopt the convention that the e-mail address returned by > get_contact_email() can be used as an author-unique ID by external > cataloguers? I'll put that in the PEP if the idea meets with > approval. This seems reasonable to me. Also it doesn't matter if for some reason your email address is different for different packages you release. So long as you let the catalog know about all your email addresses, things should be fine. The only problem is if two developers claim to have the same email address. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From paulp@ActiveState.com Mon Mar 12 16:25:59 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Mon Mar 12 16:25:59 2001 Subject: [Distutils] Uninstalling References: <3AAA1534.B729F9E5@ActiveState.com> <026801c0aaf0$e9c66460$e000a8c0@thomasnotebook> <3AACD3FE.A3318099@ActiveState.com> <043601c0ab1e$0573af10$e000a8c0@thomasnotebook> Message-ID: <3AAD3F98.84026DEF@ActiveState.com> Thomas Heller wrote: > > ... > > What I mean is: How does the user trigger the uninstall? > Does he have to keep the setup.py file to trigger it? I think that uninstall should be just like install. If you installed from a source distribution you would probably uninstall from the setup.py. If you installed from a GUI you would probably uninstall from an equal and opposite GUI. :) Perhaps under the covers we should store away the setup.py instead of having my special remove_package.py, but the big problem with that is that it is extremely difficult to know what files a setup.py depends upon. We've already found in our binary distributions that this can be a problem even on install. If you try to handle both install and uninstall, it gets pretty complicated...I can't think of a solution off the top of my head...maybe later when I have more time to think. -- Python: Programming the way Guido indented it. - (originated with Skip Montanaro?) From jafo@tummy.com Mon Mar 12 20:14:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Mon Mar 12 20:14:01 2001 Subject: [Distutils] Uninstalling In-Reply-To: <3AAD3F98.84026DEF@ActiveState.com>; from paulp@ActiveState.com on Mon, Mar 12, 2001 at 01:28:56PM -0800 References: <3AAA1534.B729F9E5@ActiveState.com> <026801c0aaf0$e9c66460$e000a8c0@thomasnotebook> <3AACD3FE.A3318099@ActiveState.com> <043601c0ab1e$0573af10$e000a8c0@thomasnotebook> <3AAD3F98.84026DEF@ActiveState.com> Message-ID: <20010312181304.B1985@tummy.com> On Mon, Mar 12, 2001 at 01:28:56PM -0800, Paul Prescod wrote: >from a source distribution you would probably uninstall from the >setup.py. If you installed from a GUI you would probably uninstall from >an equal and opposite GUI. :) Based on our discussions at Python 9, I think the direction we're going to take is that there will be some stand-alone program that will allow a user to query what packages are installed, and remove them. Keeping the setup.py around is non-optimal. Sean -- I love the smell of napalm in the morning. It smells like... Victory. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From akuchlin@mems-exchange.org Tue Mar 13 11:09:02 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Mar 13 11:09:02 2001 Subject: [Distutils] PEP 241 draft Message-ID: [Followups set to distutils-sig@python.org, since that's where most of the posters are.] I've checked in a first draft of PEP 241. Here it is; please offer comments and changes. PEP: 241 Title: Metadata for Python Software Packages Version: $Revision: 1.1 $ Author: A.M. Kuchling Type: Standards Track Created: 12-Mar-2001 Status: Draft Post-History: Introduction This PEP specifies the names and semantics of the fields used to store metadata about Python software packages. Including Metadata in Packages The Distutils 'sdist' command will be modified to extract the metadata fields from the arguments and write them to a file in the generated zipfile or tarball. This file will be named METADATA and will be placed in the top directory of the source distribution (where the README, INSTALL, and other files usually go). Authors might expect to include a METADATA file of their own that would be used instead of the generated file, but this will not be permitted. It would be confusing if person B makes a custom release of person A's software, modifies setup.py accordingly, but uses identical metadata because person B didn't delete the METADATA file. When running the 'sdist' command, a user-supplied METADATA file will be ignored and a warning about this action will be printed. XXX are we sure RFC-822 is enough? The METADATA file format is a single set of RFC-822 headers parseable by the rfc822.py module. The field names listed in the following section are used as the header names. Fields This section specifies the names and semantics of each of the supported metadata fields. Name The name of the package. XXX what's the set of legal characters? Example: 'BeagleVote' Version A string containing the package's version number. This field should be parseable by one of the Version classes (StrictVersion or LooseVersion) in the distutils.version module. Example: '1.0a2' Platforms A (XXX whitespace? comma?)-separated list of platform specifications. Platform specifications are limited to the following list: XXX copy list from PPD? SourceForge? Example: 'XXX' Description A one-line summary of what the package does. Example: "A module for collecting votes from beagles." Long-Description (optional) A longer description of the package that can run to several paragraphs. (Software that deals with metadata should not assume any maximum size for this field, though one hopes that people won't include their instruction manual as the long-description.) Example: 'This module collects votes from beagles in order to determine their electoral wishes. Do NOT try to use this module with basset hounds; it makes them grumpy.' Keywords A list of additional keywords to be used to assist searching for this package in a larger catalog. XXX Keywords should probably be constrained to be from a fixed list, but I don't think this can be enforced by the 'sdist' command. (The list might be large, and it could only be updated with new Distutils releases, which seems too inflexible.) Example: 'dog puppy voting election' Home-page (optional) A string containing the URL for the package's home page. Example: 'http://www.example.com/~cschultz/bvote/' Author (optional) A string containing at a minimum the author's name. Contact information can also be added, separating each line with newlines. Example: 'C. Schultz\nUniversal Features Syndicate\nLos Angeles, CA' Author-email A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 'From:' header ("name " or "email (name)"). It's not optional because cataloging systems can use the e-mail portion of this field as a unique key representing the author. A catalog might provide authors the ability to store their GPG key, personal home page, and other additional metadata *about the author*. Author-related metadata fields are not covered by this PEP. (XXX should they be? I think not, since nothing in this PEP will deal with author data at all.) Example: 'C. Schultz ' License A string selected from a short list of choices, specifying the license covering the package. Some licenses result in the software being freely redistributable, so packagers and resellers can automatically know that they're free to redistribute the software. Other licenses will require a careful reading by a human to determine the software can be repackaged and resold. The choices are: XXX copy list from SourceForge, + 'Other' Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: From bkc@murkworks.com Tue Mar 13 12:38:13 2001 From: bkc@murkworks.com (Brad Clements) Date: Tue Mar 13 12:38:13 2001 Subject: [Distutils] Re: [Catalog-sig] PEP 241 draft In-Reply-To: Message-ID: <3AAE1673.21264.4EB93AB@localhost> How much more difficult would it be to generate this file in XML format? Couldn't distutils include a very tiny "xml generator" that writes out the data in XML format, rather than this ancient rfc822 form? Don't need a full XML package to write XML.. but using rfc822 format seems a step backwards. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements From akuchlin@mems-exchange.org Tue Mar 13 15:07:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Mar 13 15:07:01 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: <3AAE1673.21264.4EB93AB@localhost>; from bkc@murkworks.com on Tue, Mar 13, 2001 at 12:45:41PM -0500 References: <3AAE1673.21264.4EB93AB@localhost> Message-ID: <20010313150611.D14187@ute.cnri.reston.va.us> On Tue, Mar 13, 2001 at 12:45:41PM -0500, Brad Clements wrote: >Couldn't distutils include a very tiny "xml generator" that writes out the data in XML >format, rather than this ancient rfc822 form? This could equally be done by people who need the XML form; it would be a few lines of code: metadata = rfc822.Message(open('METADATA')) print "%s..." % (metadata['name'], ...) Since the RFC-822 parser is already written, we don't gain anything by having to write a SAX or xmllib handler... *unless* someone shows that we need the ability of XML to encode full-blown trees. I currently believe we don't need that, but will listen to a good argument. --amk From mwa@gate.net Tue Mar 13 17:10:19 2001 From: mwa@gate.net (Mark W. Alexander) Date: Tue Mar 13 17:10:19 2001 Subject: [Distutils] Re: [Catalog-sig] PEP 241 draft In-Reply-To: Message-ID: Is this referring to metadata or metadata, and to packages or to packages? We've had some discussions along these lines before.... First, there's the metadata that distutils needs to do it's basic work, e.g. install stuff in the python tree. Then there's the metadata that's needed by the bdist_* commands in order to produce a binary package. Now, there's the metadata for publishing in the catalog. Also, there's "package" as in "everything" this setup.py produces, and "package" as in the binary packages produced by the bdist_* commands as applied to this setup.py. For example, Marc's mx extensions are (I think, haven't tried his latest) in a single setup.py, yet could easily and properly produce up to 5 binary packages, from the standpoint of a native package manager. I realize that the PEP (which stands for ...what?) part of the thrust to get CyPhAN (probably not spelled right) capability, but it would certainly benefit bdist authors if we included as much metadata as they may require at the same time. To that end, I just laid out (what I know of) the fields used by RPM, DPKG, Solaris pkgtool, and HP's SD-UX. The union of all four resulted in the following set (some of which you've got): Name Version Revision (packaging revision) Short Description Long Description Vendor/Author Group/Classification (This could be dropped and assumed to be Languages/Python or whatever's approriate for the platform) Copyright License (Not necessarily the same as copyright :() Packager Requires Supported Architectures (I think your 'Platform' field would be a combination of Arch/OS) Supported Operating System Control Scripts Pre-install Postinstall Pre-remove Postremove Files to install (and attributes) These seem to be the minimum that a package manager will need to make a binary package. Some managers can do more, given more information, but those features should not be used. If they are, "python setup.py bdist --format=stoopidmgr" would always work, but "python setup.py bdist --format=smartdmgr" would fail. The idea is to support additional binary package managers, without having to change setup.py. A couple more that are supported by 2 of them that I think might be helpfull (e.g. optional?) are: Provides: What this package provides (virtual service) Conflicts: Packages that conflict with this Keywords, though not required by package managers is a definite keeper. I don't know if it needs any constraints though. Open source "products" tend to be fairly realistic in their claims. Including all this information provides (I think) most of what's needed for the catalog as well as most of what's needed for packaging. In order for the packaging support to be robust enough to support sub-packages (multiple binary packages), the metadata handler needs to allow multiple instances of most of these fields. At the top level, there should be basically the list you started with, since that information is constant for any sub-packages as well. With the addition of "sub-package Name", the remainder of the fields should be repeatable for as many sub-packages as I need to support. (At least one would be required.) I think that makes the RFC-822 header format a little restrictive, although I don't know as if XML might be overkill. Maybe parseable python dictionary style? e.g. MyPackage={name='SuperPackage', vendor="me", version="0.00001", ... {name='sub1', files=[....] } {name='sub2', files=[....] } } (Then again, isn't everything scheduled to be XML by this time tommorrow anyway?) The License field you put as a list of choices, which I think is good for the catalog, but bad for producing binary packages. How about a License-Style field for the catalog? The full license should be included in either source or binary packages. Whatever they're called, both need to be available. Anyway, that's my $.02 plus a little more. I think this is a good step towards a "standard" catalog system, and a great way to promote additional bdist modules. Mark Alexander mwa@gate.net On Tue, 13 Mar 2001, Andrew Kuchling wrote: > Date: Tue, 13 Mar 2001 11:08:35 -0500 > From: Andrew Kuchling > To: distutils-sig@python.org > Cc: catalog-sig@python.org > Followup-To: distutils-sig@python.org > Subject: [Catalog-sig] PEP 241 draft > > [Followups set to distutils-sig@python.org, since that's where most of > the posters are.] > > I've checked in a first draft of PEP 241. Here it is; please offer > comments and changes. > > PEP: 241 > Title: Metadata for Python Software Packages > Version: $Revision: 1.1 $ > Author: A.M. Kuchling > Type: Standards Track > Created: 12-Mar-2001 > Status: Draft > Post-History: > > Introduction [snip, see the archives] From amos@digicool.com Tue Mar 13 17:42:01 2001 From: amos@digicool.com (Amos Latteier) Date: Tue Mar 13 17:42:01 2001 Subject: [Distutils] PEP 241 draft References: Message-ID: <3AAEA1D0.8F67E2BE@digicool.com> Andrew Kuchling wrote: > I've checked in a first draft of PEP 241. Here it is; please offer > comments and changes. Looks good. > Authors might expect to include a METADATA file of their own that > would be used instead of the generated file, but this will not be > permitted. Important point! > XXX are we sure RFC-822 is enough? > The METADATA file format is a single set of RFC-822 headers > parseable by the rfc822.py module. The field names listed in the > following section are used as the header names. I agree that if meta-data is a flat list of names and values then rfc822 is probably fine. > Name > > The name of the package. XXX what's the set of legal characters? Why should the legal characters be restricted? OK, no newlines, but otherwise what do we care? > Author (optional) > Author-email Should we allow more than one contact email address? For example, there may be multiple authors, or there may be some other relevant contact email addresses. > Keywords > > A list of additional keywords to be used to assist searching > for this package in a larger catalog. > > XXX Keywords should probably be constrained to be from a fixed > list, but I don't think this can be enforced by the 'sdist' > command. (The list might be large, and it could only be updated > with new Distutils releases, which seems too inflexible.) > > Example: 'dog puppy voting election' It might be more useful to have categories like CPAN's categories http://cpan.org/modules/by-category/ or Source Forge's 'Trove' categories http://sourceforge.net/softwaremap/trove_list.php of the Vaults of Parnassus's categories http://www.vex.net/parnassus/apyllo.py?a=tree Your example keywords could probably be extracted from the description and long description and used by search engines when indexing. I'm not sure keywords are needed if we have full text description and long description. Categories, on the other hand, help not with searching so much as browsing. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From c.evans@clear.net.nz Wed Mar 14 04:45:02 2001 From: c.evans@clear.net.nz (Carey Evans) Date: Wed Mar 14 04:45:02 2001 Subject: [Distutils] Re: PEP 241 draft In-Reply-To: References: Message-ID: <87k85ssn13.fsf@psyche.dnsalias.org> Andrew Kuchling writes: [...] > Author-email > > A string containing the author's e-mail address. It can contain > a name and e-mail address in the legal forms for a RFC-822 > 'From:' header ("name " or "email (name)"). The IETF DRUMS working group's drafts deprecate the latter format, saying that the "name " form _should_ be used. This would probably be a good idea for the metadata. http://www.ietf.org/html.charters/drums-charter.html [...] > Example: 'C. Schultz ' Strictly speaking, this isn't a valid RFC 822 address - the name in that form of address is supposed to be a sequence of s, which doesn't include ".". In practice everything accepts it, but it should be written: "C. Schultz" -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Quiet, you'll miss the humorous conclusion." From Juergen Hermann" Message-ID: On Tue, 13 Mar 2001 15:06:11 -0500, Andrew Kuchling wrote: >This could equally be done by people who need the XML form; it would >be a few lines of code: > >metadata =3D rfc822.Message(open('METADATA')) >print "%s..." % (metadata['name'], ...) > >Since the RFC-822 parser is already written, we don't gain anything by >having to write a SAX or xmllib handler... *unless* someone shows that >we need the ability of XML to encode full-blown trees. I currently >believe we don't need that, but will listen to a good argument. I too believe that RFC822 is better for plain name/value pairs, especially since RFC822 is more available (Python 1.5). BUT (now comes the but ;), I believe we should define a _standard_ format (or even better, describe the _standard_ conversion of distutils = RFC822 metadata into a predefined XML DTD) for XML usage. Concrete sample uses of this: if we have a cpyan server, it could generate automatically a xml export of all the stored packages (or subsets thereof) so that clients can get summarized package data via SOAP or XMLRPC. This requires standardization. Ciao, J=FCrgen -- J=FCrgen Hermann, Developer (jhe@webde-ag.de) WEB.DE AG, http://webde-ag.de/ From paulp@ActiveState.com Wed Mar 14 09:01:00 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed Mar 14 09:01:00 2001 Subject: [Distutils] PEP 241 draft References: <3AAE1673.21264.4EB93AB@localhost> <20010313150611.D14187@ute.cnri.reston.va.us> Message-ID: <3AAF7A77.10255DCA@ActiveState.com> Andrew Kuchling wrote: > >... > > Since the RFC-822 parser is already written, we don't gain anything by > having to write a SAX or xmllib handler... *unless* someone shows that > we need the ability of XML to encode full-blown trees. I currently > believe we don't need that, but will listen to a good argument. When I look at the headers for mail messages, I see increasingly structured information stuffed into key/value pairs. That's because information tends to start simple and become complex as time goes by. Therefore I would prefer we choose a future-proof format now. I also think that Long Description looks a lot better as XML content than as a value-string. It makes perfect sense for Long Description to have hyperlinks in it so it may be that we will soon want it to be some form of structured text. Note that I can set up an XML editor to allow *only legal values* in an XML document but have no equivalent tool for RFC-822. -- Python: Programming the way Guido indented it. - (originated with Skip Montanaro?) From akuchlin@mems-exchange.org Wed Mar 14 10:28:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed Mar 14 10:28:01 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: <3AAEA1D0.8F67E2BE@digicool.com>; from amos@digicool.com on Tue, Mar 13, 2001 at 02:40:16PM -0800 References: <3AAEA1D0.8F67E2BE@digicool.com> Message-ID: <20010314102709.B15434@ute.cnri.reston.va.us> On Tue, Mar 13, 2001 at 02:40:16PM -0800, Amos Latteier wrote: >> Name >> The name of the package. XXX what's the set of legal characters? >Why should the legal characters be restricted? OK, no newlines, but >otherwise what do we care? That was there in case the Distutils restricted the name to a given set of chars; it doesn't seem to. >Should we allow more than one contact email address? For example, there >may be multiple authors, or there may be some other relevant contact >email addresses. I don't know; if so, that would be a point in XML's favor. >It might be more useful to have categories like CPAN's categories > http://cpan.org/modules/by-category/ Perhaps, but specifying what categories will be too time-consuming to do in time for 2.1. We can decide on a category format, though (category names separated by colons, or slashes, or whatever). Suggestions? And should we drop keywords in favor of categories, or have them both? --amk From akuchlin@mems-exchange.org Wed Mar 14 11:06:22 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed Mar 14 11:06:22 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: <3AAF7A77.10255DCA@ActiveState.com>; from paulp@ActiveState.com on Wed, Mar 14, 2001 at 06:04:39AM -0800 References: <3AAE1673.21264.4EB93AB@localhost> <20010313150611.D14187@ute.cnri.reston.va.us> <3AAF7A77.10255DCA@ActiveState.com> Message-ID: <20010314110521.D15434@ute.cnri.reston.va.us> On Wed, Mar 14, 2001 at 06:04:39AM -0800, Paul Prescod wrote: >When I look at the headers for mail messages, I see increasingly >structured information stuffed into key/value pairs. That's because >information tends to start simple and become complex as time goes by. >Therefore I would prefer we choose a future-proof format now. That still leaves the choice/design of a DTD, though, and given the community's propensity for trying to cover every possibility, I'm doubtful of getting that done in time. 2.1final is scheduled for April 13, just under a month away, and I'd like to get it in for beta2, so there's time pressure here. (Aside: While Amos' patch includes the ability for DistributionMetadata instances to be parsed from XML format, the Distutils don't actually *need* that capability right now, and may never need it at all, which means they don't need to contain a parser. DistributionMetadata could just generate XML using %s in 2.1, assuming a common DTD can be decided upon.) Here's a proposed compromise: use RFC-822 format in 2.1final, leaving us with 6 months over the Python 2.2 development cycle to arrive at a DTD, at which point 2.2 can switch to putting XML in the METADATA file. It's not difficult to determine if METADATA is XML or RFC-822 (look for an Message-ID: On Wed, 14 Mar 2001, Andrew Kuchling wrote: [...] > do in time for 2.1. We can decide on a category format, though > (category names separated by colons, or slashes, or whatever). > Suggestions? And should we drop keywords in favor of categories, or > have them both? Keywords do become useful for collections as large as Parnassus, and probably for smaller collections, too. I don't see why the keyword list would have to be fixed between releases of Distutils -- can't it just be in a standard place in the catalogue, as well as in Distutils? Anything / anyone using it would use the most up-to-date copy available. It would have to be standardised to achieve its full potential. If you have keywords I don't see why you'd need categories. The only reason I know of for using categories is when you're forced into it by having physical objects that can only be in one place at a time. A software catalogue is not a paper book library. John From akuchlin@mems-exchange.org Wed Mar 14 12:08:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed Mar 14 12:08:01 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: ; from phrxy@csv.warwick.ac.uk on Wed, Mar 14, 2001 at 04:59:00PM +0000 References: <20010314102709.B15434@ute.cnri.reston.va.us> Message-ID: <20010314120739.H15434@ute.cnri.reston.va.us> On Wed, Mar 14, 2001 at 04:59:00PM +0000, John J. Lee wrote: >probably for smaller collections, too. I don't see why the keyword list >would have to be fixed between releases of Distutils -- can't it just be >in a standard place in the catalogue, as well as in Distutils? Anything / Sorry; this isn't quite clear in the PEP. The issue is just that, if we have a fixed list of keywords, the Distutils can't enforce this when you run 'setup.py sdist'; it couldn't warn you that 'asdfgh' isn't a legal keyword. We could put a keyword list in the Distutils code, but as soon as we add another keyword, there's no way to make all the Python installations aware of this. It's a minor point; the Distutils can't enforce this, so catalogs will have to. --amk From mwa@gate.net Wed Mar 14 12:12:02 2001 From: mwa@gate.net (Mark W. Alexander) Date: Wed Mar 14 12:12:02 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: <20010314110521.D15434@ute.cnri.reston.va.us> Message-ID: On Wed, 14 Mar 2001, Andrew Kuchling wrote: > Subject: Re: [Distutils] PEP 241 draft > > Here's a proposed compromise: use RFC-822 format in 2.1final, leaving > us with 6 months over the Python 2.2 development cycle to arrive at a > DTD, at which point 2.2 can switch to putting XML in the METADATA > file. It's not difficult to determine if METADATA is XML or RFC-822 > (look for an implementors can just do that and support both. Come to think of it, > that's also easier if the initial DTD selected is all wrong and we > have to change it; imps need a simple RFC-822 converter, not two > handlers for two different XML formats. Sounds like a plan to me. A good one, too. Mark From phrxy@csv.warwick.ac.uk Wed Mar 14 13:03:01 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Wed Mar 14 13:03:01 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: <20010314120739.H15434@ute.cnri.reston.va.us> Message-ID: yOn Wed, 14 Mar 2001, Andrew Kuchling wrote: > On Wed, Mar 14, 2001 at 04:59:00PM +0000, John J. Lee wrote: > >probably for smaller collections, too. I don't see why the keyword list > >would have to be fixed between releases of Distutils -- can't it just be > >in a standard place in the catalogue, as well as in Distutils? Anything / > > Sorry; this isn't quite clear in the PEP. The issue is just that, if > we have a fixed list of keywords, the Distutils can't enforce this > when you run 'setup.py sdist'; it couldn't warn you that 'asdfgh' > isn't a legal keyword. We could put a keyword list in the Distutils > code, but as soon as we add another keyword, there's no way to make > all the Python installations aware of this. It's a minor point; the > Distutils can't enforce this, so catalogs will have to. Yeah, I see why it's a problem now, but I also agree that it's minor. ;-) I suppose Distutils could still usefully know about the list and give warnings about keywords not in the local list. John From mal@lemburg.com Wed Mar 14 15:06:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Mar 14 15:06:01 2001 Subject: [Distutils] PEP 241 draft References: <3AAEA1D0.8F67E2BE@digicool.com> Message-ID: <3AAFCF0B.D3B98BFE@lemburg.com> Amos Latteier wrote: > > Andrew Kuchling wrote: > > I've checked in a first draft of PEP 241. Here it is; please offer > > comments and changes. > > Looks good. Agreed :-) > > Authors might expect to include a METADATA file of their own that > > would be used instead of the generated file, but this will not be > > permitted. > > Important point! Can't we have arbitrary extra fields starting with e.g. 'X-MyHeader' which are then application defined ? (Mail headers work this way.) > > XXX are we sure RFC-822 is enough? > > The METADATA file format is a single set of RFC-822 headers > > parseable by the rfc822.py module. The field names listed in the > > following section are used as the header names. > > I agree that if meta-data is a flat list of names and values then rfc822 > is probably fine. Agreed. About the format you indicate: I don't think that the quotes around the values are necessary for RFC-822 (but could be wrong). At least mail headers don't have quotes, so it's probably ok to omit them. > > Name > > > > The name of the package. XXX what's the set of legal characters? > > Why should the legal characters be restricted? OK, no newlines, but > otherwise what do we care? Doesn't really matter as long as it's 7-bit, e.g. ASCII or UTF-7. > > Author (optional) > > Author-email > > Should we allow more than one contact email address? For example, there > may be multiple authors, or there may be some other relevant contact > email addresses. We could probably allow the value to be a comma separated list !? > > Keywords > > > > A list of additional keywords to be used to assist searching > > for this package in a larger catalog. > > > > XXX Keywords should probably be constrained to be from a fixed > > list, but I don't think this can be enforced by the 'sdist' > > command. (The list might be large, and it could only be updated > > with new Distutils releases, which seems too inflexible.) > > > > Example: 'dog puppy voting election' > > It might be more useful to have categories like CPAN's categories > > http://cpan.org/modules/by-category/ > > or Source Forge's 'Trove' categories > > http://sourceforge.net/softwaremap/trove_list.php > > of the Vaults of Parnassus's categories > > http://www.vex.net/parnassus/apyllo.py?a=tree > > Your example keywords could probably be extracted from the description > and long description and used by search engines when indexing. I'm not > sure keywords are needed if we have full text description and long > description. > > Categories, on the other hand, help not with searching so much as > browsing. Why not have both ? -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From paulp@ActiveState.com Wed Mar 14 15:13:01 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed Mar 14 15:13:01 2001 Subject: [Distutils] PEP 241 draft References: <3AAE1673.21264.4EB93AB@localhost> <20010313150611.D14187@ute.cnri.reston.va.us> <3AAF7A77.10255DCA@ActiveState.com> <20010314110521.D15434@ute.cnri.reston.va.us> Message-ID: <3AAFD183.103CD920@ActiveState.com> Andrew Kuchling wrote: > > .... > > That still leaves the choice/design of a DTD, though, and given the > community's propensity for trying to cover every possibility, I'm > doubtful of getting that done in time. I would suggest an algorithmic transformation from metadata to DTD (perhaps performed by hand). For instance turn every metadata item into an element of the same name with a value attribute or content. Then there are no decisions to be made. We should establish a convention for this format, just as we would for RFC 822,that unknown elements should be ignored or passed along silently (depending on the type of application). That gives us an upgrade path. Oh yeah, another reason for XML is Unicode. :) -- Python: Programming the way Guido indented it. - (originated with Skip Montanaro?) From akuchlin@mems-exchange.org Wed Mar 14 17:27:03 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed Mar 14 17:27:03 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: <3AAFD183.103CD920@ActiveState.com>; from paulp@ActiveState.com on Wed, Mar 14, 2001 at 12:16:03PM -0800 References: <3AAE1673.21264.4EB93AB@localhost> <20010313150611.D14187@ute.cnri.reston.va.us> <3AAF7A77.10255DCA@ActiveState.com> <20010314110521.D15434@ute.cnri.reston.va.us> <3AAFD183.103CD920@ActiveState.com> Message-ID: <20010314172607.A1603@ute.cnri.reston.va.us> On Wed, Mar 14, 2001 at 12:16:03PM -0800, Paul Prescod wrote: >I would suggest an algorithmic transformation from metadata to DTD >(perhaps performed by hand). For instance turn every metadata item into >an element of the same name with a value attribute or content. Then >there are no decisions to be made. Can you (or some volunteer) please write up a description of this transformation and post it? I can't really figure out what this would buy us, but am not quite sure what you're suggesting. --amk From paulp@ActiveState.com Wed Mar 14 18:40:01 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed Mar 14 18:40:01 2001 Subject: [Distutils] PEP 241 draft References: <3AAE1673.21264.4EB93AB@localhost> <20010313150611.D14187@ute.cnri.reston.va.us> <3AAF7A77.10255DCA@ActiveState.com> <20010314110521.D15434@ute.cnri.reston.va.us> <3AAFD183.103CD920@ActiveState.com> <20010314172607.A1603@ute.cnri.reston.va.us> Message-ID: <3AB00226.D42836C3@ActiveState.com> Andrew Kuchling wrote: > >... > > Can you (or some volunteer) please write up a description of this > transformation and post it? ... ... ... ... ... ... ... > I can't really figure out what this would > buy us, but am not quite sure what you're suggesting. The main one is easier extensibility to structured types. And other ones I've mentioned before...XML editor support, future potential sub-structure for long-description, i18n, ... -- Python: Programming the way Guido indented it. - (originated with Skip Montanaro?) From jafo@tummy.com Thu Mar 15 00:10:02 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Thu Mar 15 00:10:02 2001 Subject: [Distutils] Metadata fields In-Reply-To: <00bf01c0ab2e$cf302c60$0100a8c0@Rogue>; from robin@alldunn.com on Mon, Mar 12, 2001 at 11:58:28AM -0800 References: <00bf01c0ab2e$cf302c60$0100a8c0@Rogue> Message-ID: <20010314220956.F30951@tummy.com> On Mon, Mar 12, 2001 at 11:58:28AM -0800, Robin Dunn wrote: >Perhaps an "alternate download" link. This could be a place the author >maintains as a mirror of his own stuff. The catalog will still put the I figure that the uses of the "download" link is primarily for non-automated use (users who want to track something down). What other uses are there? Maybe just having a "homepage" link will suffice? If not, perhaps the name should change from "download" to "source" or "source-download" or the like. To differentiate it from what the catalog consumers are most likely to want to be downloading. Sean -- Give a man a match and he'll be warm for an hour... Set him on fire and he'll be warm for the rest of his life. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Thu Mar 15 00:20:00 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Thu Mar 15 00:20:00 2001 Subject: [Distutils] Metadata fields In-Reply-To: <3AAD3B9A.C906E5DF@digicool.com>; from amos@digicool.com on Mon, Mar 12, 2001 at 01:11:54PM -0800 References: <20010312153142.A13192@ute.cnri.reston.va.us> <3AAD3B9A.C906E5DF@digicool.com> Message-ID: <20010314221903.G30951@tummy.com> On Mon, Mar 12, 2001 at 01:11:54PM -0800, Amos Latteier wrote: >Andrew Kuchling wrote: >> What's the distinction? Maybe: description is a single line, and >> long_description is one or more full paragraphs? > >Exactly. Having both is useful since often the name is not enough to >descriptively identify a package. It is often useful to have a one line I'd recommend either using "Summary" and "Description", or "Short-Description" and "Description". To me, the word "description" does not imply an 80-character limitation... >> Good point! It probably shouldn't, since the >> metadata tells you about the package that you have right here as a >> tarball/RPM/whatever and the package doesn't need to know where it's >> supposed to live on the Web. I'd agree there. >I'm not sure what you mean by Python package database. In general, it There were talks at the conference about how it's likely that we'll need some sort of package database for handling installs and uninstalls or Python modules/packages... >will be hard to put meta-data in a binary distribution in a way that the >catalog can easily retrieve it. So I agree that metadata goes in source Metadata can be delivered out-of-band. For example, when writing the .tar.gz (or whatever), we could also write a ".mta" (or whatever) file of the same base name containing the meta-data. On the trip back I wrote some code for directly extracting the meta-data out of a .tar.* file, but it's easy enough to deal with getting the meta-data submitted seperately. I don't see any way of not providing the meta-data for binary packages (like trying to use the source meta-data instead), because we'll have to know things like: Architecture Platform-Name Platform-Version for binaries. >This seems reasonable to me. Also it doesn't matter if for some reason >your email address is different for different packages you release. So >long as you let the catalog know about all your email addresses, things It'd be nice to have some way that users could override that if, for example, they use different e-mail addresses for each package (as I often do), or there is a collision for some other reason... I don't think that using the e-mail address is unreasonable though... Sean -- ISA isn't dead, it's just that people wish it were. The correct term for this condition is "legacy"... -- Sean Reifschneider, 1999 Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Thu Mar 15 00:24:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Thu Mar 15 00:24:01 2001 Subject: [Distutils] Metadata fields In-Reply-To: <20010312153142.A13192@ute.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Mar 12, 2001 at 03:31:42PM -0500 References: <20010312153142.A13192@ute.cnri.reston.va.us> Message-ID: <20010314222324.H30951@tummy.com> On Mon, Mar 12, 2001 at 03:31:42PM -0500, Andrew Kuchling wrote: >METADATA go in both source and binary distributions? If so, where? >Strawman convention: metadata goes in a METADATA file in the top >directory of source dists. In binary dists... it should really drop "WHATSNEW", "LICENSE", "README" -- they all say something to the consumer. "METADATA" really doesn't. I'd prefer something like "PKG-INFO", or "setup-meta". The LSM went a long way with having ".lsm" files along-side ".tar.gz". Sean -- Think. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Thu Mar 15 00:46:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Thu Mar 15 00:46:01 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: ; from akuchlin@mems-exchange.org on Tue, Mar 13, 2001 at 11:08:35AM -0500 References: Message-ID: <20010314224525.I30951@tummy.com> On Tue, Mar 13, 2001 at 11:08:35AM -0500, Andrew Kuchling wrote: > generated zipfile or tarball. This file will be named METADATA See my previous message for why I don't like "METADATA". > Authors might expect to include a METADATA file of their own that > would be used instead of the generated file, but this will not be > permitted. It would be confusing if person B makes a custom > release of person A's software, modifies setup.py accordingly, but > uses identical metadata because person B didn't delete the > METADATA file. When running the 'sdist' command, a user-supplied > METADATA file will be ignored and a warning about this action will > be printed. Alternate wording: Developers may not provide their own "METADATA" file. The "sdist" command will, if it detects an existing "METADATA" file, terminate with an appropriate error message. This should prevent confusion caused by the "METADATA" and "setup.py" files being out of sync. > XXX are we sure RFC-822 is enough? > The METADATA file format is a single set of RFC-822 headers > parseable by the rfc822.py module. The field names listed in the > following section are used as the header names. RFC822 is an interesting choice. I was initially thinking XML, but I kind of like the RFC822 idea. Probably good to note above that multi-line entries must have white-space at the beginning of their continued lines... >Fields > Name > > The name of the package. XXX what's the set of legal characters? > > Example: 'BeagleVote' Questions: Is it expected this name corresponds either to the name of the package which is imported, or the package top-level directory name? If so, what do we do about alternative packages that provide different implementations of the same functionality? I suppose we could reasonably expect to make use of "import urllib2 as urllib" to take care of that. Proposed valid characters: [-a-zA-Z_0-9] > Platforms > > A (XXX whitespace? comma?)-separated list of platform > specifications. Platform specifications are limited to the > following list: Does this include platform name, platform version, and architecture? Like redhat-7.0-x86, windows-nt-hppa, etc? > Description See my other message about "Description" versus "Short-Description" and "Summary". What about: Freely-Redistributable Group (such as "Database", "Network/SMTP", etc)? Provides (maybe "urllib2" would provide "urllib"?) Requires (dependences -- RPM for example has multiple lines of the form "Requires: initscripts >= 3.25", "Requires: openssl >= 0.9.4") In general, it looks good. Sean -- There is no force so powerful as an idea whose time has come. -- Everett Dirkson Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Thu Mar 15 00:56:20 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Thu Mar 15 00:56:20 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: <3AAEA1D0.8F67E2BE@digicool.com>; from amos@digicool.com on Tue, Mar 13, 2001 at 02:40:16PM -0800 References: <3AAEA1D0.8F67E2BE@digicool.com> Message-ID: <20010314225517.J30951@tummy.com> On Tue, Mar 13, 2001 at 02:40:16PM -0800, Amos Latteier wrote: >> Author (optional) >> Author-email > >Should we allow more than one contact email address? For example, there >may be multiple authors, or there may be some other relevant contact >email addresses. The point that brings up is that the PEP doesn't include information on what entries are expected to be unique, and what will permit repetition. >or Source Forge's 'Trove' categories > http://sourceforge.net/softwaremap/trove_list.php The Trove Map is probably worth using for the "Group". Thanks for the URL. I don't know though -- is it too software-oriented and not enough programming-oriented? Sean -- Why would I want to be a Doctor, when I could be a MASTER? Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Thu Mar 15 00:59:02 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Thu Mar 15 00:59:02 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: <3AAFCF0B.D3B98BFE@lemburg.com>; from mal@lemburg.com on Wed, Mar 14, 2001 at 09:05:31PM +0100 References: <3AAEA1D0.8F67E2BE@digicool.com> <3AAFCF0B.D3B98BFE@lemburg.com> Message-ID: <20010314225825.K30951@tummy.com> On Wed, Mar 14, 2001 at 09:05:31PM +0100, M.-A. Lemburg wrote: >Can't we have arbitrary extra fields starting with e.g. 'X-MyHeader' >which are then application defined ? (Mail headers work this way.) Hmm, do you have something in mind? >Doesn't really matter as long as it's 7-bit, e.g. ASCII or UTF-7. Having "/" as a valid character could suck... >> Should we allow more than one contact email address? For example, there >> may be multiple authors, or there may be some other relevant contact >> email addresses. > >We could probably allow the value to be a comma separated list !? You mean like RFC-822? ;-) >> Categories, on the other hand, help not with searching so much as >> browsing. > >Why not have both ? Agreed. Automatic indexing usually doesn't work very well. Keywords is a good idea. Sean -- "We just wanted to give the band a little more thrust than most other bands." - Donald Fagen's reply to why they chose the name 'Steely Dan' Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Thu Mar 15 01:11:22 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Thu Mar 15 01:11:22 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: <20010314110521.D15434@ute.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Wed, Mar 14, 2001 at 11:05:21AM -0500 References: <3AAE1673.21264.4EB93AB@localhost> <20010313150611.D14187@ute.cnri.reston.va.us> <3AAF7A77.10255DCA@ActiveState.com> <20010314110521.D15434@ute.cnri.reston.va.us> Message-ID: <20010314231017.L30951@tummy.com> On Wed, Mar 14, 2001 at 11:05:21AM -0500, Andrew Kuchling wrote: >That still leaves the choice/design of a DTD, though, and given the >community's propensity for trying to cover every possibility, I'm Well, I think that Dublin Core is the logical choice of the place to start. However, I'm really not an XML guy, so for me it's much easier to deal with RFC822. The idea, as I understand it, is to get these things into 2.1, so that we can try them out in a more real-world environment and find out what works and what doesn't for 2.2. If XML *IS* better suited for the task, we change it for 2.2. If a DTD is ready for 2.2 or even 2.1, I'd be open to using it. I'm not likely to provide that though. ;-) Sean -- If you talk to God, you are praying; if God talks to you, you have schizophrenia. -- Thomas Szasz Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From Alexandre.Fayolle@logilab.fr Thu Mar 15 03:47:02 2001 From: Alexandre.Fayolle@logilab.fr (Alexandre Fayolle) Date: Thu Mar 15 03:47:02 2001 Subject: [Distutils] Re: Distutils-SIG digest, Vol 1 #478 - 13 msgs In-Reply-To: Message-ID: Andrew Kuchling wrote : > On Wed, Mar 14, 2001 at 12:16:03PM -0800, Paul Prescod wrote: > >I would suggest an algorithmic transformation from metadata to DTD > >(perhaps performed by hand). For instance turn every metadata item into > >an element of the same name with a value attribute or content. Then > >there are no decisions to be made. > > Can you (or some volunteer) please write up a description of this > transformation and post it? I can't really figure out what this would > buy us, but am not quite sure what you're suggesting. You may want to check vcalsax, available at http://www.logilab.org/vcalsax/. This module reads a vcalendar file (used by korganizer and gnomecal, which looks a lot like rfc822), and emits SAX2 events so that it is possible to process the file as if it were XML, and thus, for example build a DOM tree out of it. Alexandre Fayolle -- http://www.logilab.com Narval is the first software agent available as free software (GPL). LOGILAB, Paris (France). From paulp@ActiveState.com Thu Mar 15 06:29:01 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Thu Mar 15 06:29:01 2001 Subject: [Distutils] Re: Distutils-SIG digest, Vol 1 #478 - 13 msgs References: Message-ID: <3AB0A82F.BBC26289@ActiveState.com> Alexandre Fayolle wrote: > > ... > > You may want to check vcalsax, available at > http://www.logilab.org/vcalsax/. This module reads a vcalendar file (used > by korganizer and gnomecal, which looks a lot like rfc822), and emits SAX2 > events so that it is possible to process the file as if it were XML, and > thus, for example build a DOM tree out of it. I didn't really intend for it to be anything complex. for name in metadatanames: print "<"+name.lower()+">"+content+"" Maybe it is intrisically more complex them I am thinking... -- Take a recipe. Leave a recipe. Python Cookbook! http://www.activestate.com/pythoncookbook From Alexandre.Fayolle@logilab.fr Thu Mar 15 07:18:01 2001 From: Alexandre.Fayolle@logilab.fr (Alexandre Fayolle) Date: Thu Mar 15 07:18:01 2001 Subject: [Distutils] Re: Distutils-SIG digest, Vol 1 #478 - 13 msgs In-Reply-To: <3AB0A82F.BBC26289@ActiveState.com> Message-ID: On Thu, 15 Mar 2001, Paul Prescod wrote: > I didn't really intend for it to be anything complex. > > for name in metadatanames: > print "<"+name.lower()+">"+content+"" > > Maybe it is intrisically more complex them I am thinking... You'd need at least to escape '&' and '<' in content. Alexandre Fayolle -- http://www.logilab.com Narval is the first software agent available as free software (GPL). LOGILAB, Paris (France). From jack@oratrix.nl Thu Mar 15 09:07:01 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu Mar 15 09:07:01 2001 Subject: [Distutils] Metadata fields In-Reply-To: Message by Sean Reifschneider , Wed, 14 Mar 2001 22:09:56 -0700 , <20010314220956.F30951@tummy.com> Message-ID: <20010315140608.B217BEA11D@oratrix.oratrix.nl> Could we add a field that would allow for the functionality that is now in the (very little known) checkversion.py script? I think that it would be good enough if the metadata file contained the URL where the current metadata file is stored. What checkversion would then do is run through your Python installation looking for metadata files, and for each one found it would retrieve the current version of that file over the net. If the version number in the net-based file was higher than the one in the file on your disk it would tell you there's a new version of the package available (and probably offer to download it, etc). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From akuchlin@mems-exchange.org Thu Mar 15 11:13:18 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Mar 15 11:13:18 2001 Subject: [Distutils] RFC-822 or XML? In-Reply-To: ; from Alexandre.Fayolle@logilab.fr on Thu, Mar 15, 2001 at 01:20:37PM +0100 References: <3AB0A82F.BBC26289@ActiveState.com> Message-ID: <20010315111222.C2440@ute.cnri.reston.va.us> On Thu, Mar 15, 2001 at 01:20:37PM +0100, Alexandre Fayolle wrote: >> I didn't really intend for it to be anything complex. >> >> for name in metadatanames: >> print "<"+name.lower()+">"+content+"" >> >> Maybe it is intrisically more complex them I am thinking... > >You'd need at least to escape '&' and '<' in content. Indeed, and in the simple hack for 2.1, how should a field like: Long-description: Messed-up tags be handled? If <>& aren't escaped, this will generate invalid XML; if they are escaped, you can't represent a structured description anyway. I really, *really* think an XML format buys us nothing in the 2.1 time frame. An extensible format buys us nothing at this point since there will be no switch or override way to specify additional fields. Unicode would be missing, but CPAN's gotten this far without either Unicode or the ability to have multiple authors, and we can get along without them for 6 months. I'd also really like to get this checked in by next Monday, and am noting the tendency toward feature creep starting. Support for versioncheck and multiple authors and such things are all good ideas, but they'll require writing more code, and we're already at the beta stage, so I'm really anxious to minimize the changes. Shall we simply vote on the issue? RFC-822 or simple XML (from Paul's algorithm cited above)? +/-1, +/- 0 voting, as on python-dev. --amk From akuchlin@mems-exchange.org Thu Mar 15 11:22:08 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Mar 15 11:22:08 2001 Subject: [Distutils] Metadata fields In-Reply-To: <20010314222324.H30951@tummy.com>; from jafo@tummy.com on Wed, Mar 14, 2001 at 10:23:24PM -0700 References: <20010312153142.A13192@ute.cnri.reston.va.us> <20010314222324.H30951@tummy.com> Message-ID: <20010315112119.D2440@ute.cnri.reston.va.us> On Wed, Mar 14, 2001 at 10:23:24PM -0700, Sean Reifschneider wrote: >"METADATA" really doesn't. I'd prefer something like "PKG-INFO", or >"setup-meta". The LSM went a long way with having ".lsm" PKG-INFO is fine with me. --amk From Paul.Moore@uk.origin-it.com Thu Mar 15 11:22:11 2001 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Thu Mar 15 11:22:11 2001 Subject: [Distutils] RFC-822 or XML? Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AD94@UKRUX002.rundc.uk.origin-it.com> From: Andrew Kuchling [mailto:akuchlin@mems-exchange.org] > I'd also really like to get this checked in by next Monday, and am > noting the tendency toward feature creep starting. Support for > versioncheck and multiple authors and such things are all good ideas, > but they'll require writing more code, and we're already at the beta > stage, so I'm really anxious to minimize the changes. Shall we simply > vote on the issue? RFC-822 or simple XML (from Paul's algorithm cited > above)? +/-1, +/- 0 voting, as on python-dev. +1 for RFC-822 -0 for XML I agree, let's KISS and get something out. Overdesign is not a virtue - CPAN "just growed". Paul From paulp@ActiveState.com Thu Mar 15 11:44:15 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Thu Mar 15 11:44:15 2001 Subject: [Distutils] RFC-822 or XML? References: <3AB0A82F.BBC26289@ActiveState.com> <20010315111222.C2440@ute.cnri.reston.va.us> Message-ID: <3AB0F214.CF7150E4@ActiveState.com> Andrew Kuchling wrote: > > ... > > Indeed, and in the simple hack for 2.1, how should a field like: > > Long-description: Messed-up tags > > be handled? If <>& aren't escaped, this will generate invalid XML; if > they are escaped, you can't represent a structured description anyway. Long descriptions have tags in them NOW? If that's true, that's a bad thing. > I really, *really* think an XML format buys us nothing in the 2.1 time > frame. That's fine. You're doing the work. You decide. > ... Shall we simply > vote on the issue? RFC-822 or simple XML (from Paul's algorithm cited > above)? +/-1, +/- 0 voting, as on python-dev. I don't think there is any benefit then you shouldn't do it. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.activestate.com/pythoncookbook From akuchlin@mems-exchange.org Thu Mar 15 11:47:10 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Mar 15 11:47:10 2001 Subject: [Distutils] Metadata fields In-Reply-To: <20010314221903.G30951@tummy.com>; from jafo@tummy.com on Wed, Mar 14, 2001 at 10:19:03PM -0700 References: <20010312153142.A13192@ute.cnri.reston.va.us> <3AAD3B9A.C906E5DF@digicool.com> <20010314221903.G30951@tummy.com> Message-ID: <20010315114636.E2440@ute.cnri.reston.va.us> On Wed, Mar 14, 2001 at 10:19:03PM -0700, Sean Reifschneider wrote: >I'd recommend either using "Summary" and "Description", or >"Short-Description" and "Description". To me, the word "description" >does not imply an 80-character limitation... Good point; I'll make that change. >I wrote some code for directly extracting the meta-data out of a .tar.* >file, but it's easy enough to deal with getting the meta-data submitted >seperately. But then the meta-data file can get lost; I like having it in the tarball so if you have the source, you automatically have the metadata. >I don't see any way of not providing the meta-data for binary packages >(like trying to use the source meta-data instead), because we'll have >to know things like: > > Architecture > Platform-Name > Platform-Version The problem is, "where do we put it?" If I generate an RPM, where does PKG-INFO go? How do you find it again? Where does it go in a Windows .exe installer so that a catalog can read it out? This is a case where separate metadata would really make sense, but I think it can't be resolved for 2.1. >It'd be nice to have some way that users could override that if, for >example, they use different e-mail addresses for each package (as I often >do), or there is a collision for some other reason... I don't think that >using the e-mail address is unreasonable though... That's up to the cataloguer, not the Distutils. I'll reword that in the PEP. --amk From akuchlin@mems-exchange.org Thu Mar 15 12:03:05 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Mar 15 12:03:05 2001 Subject: [Catalog-sig] Re: [Distutils] PEP 241 draft In-Reply-To: <20010314224525.I30951@tummy.com>; from jafo@tummy.com on Wed, Mar 14, 2001 at 10:45:25PM -0700 References: <20010314224525.I30951@tummy.com> Message-ID: <20010315120212.F2440@ute.cnri.reston.va.us> On Wed, Mar 14, 2001 at 10:45:25PM -0700, Sean Reifschneider wrote: >Alternate wording: > Developers may not provide their own "METADATA" file. The "sdist" More fascist; I like it! Will add it... >Questions: Is it expected this name corresponds either to the name of the >package which is imported, or the package top-level directory name? If so, I don't think so; consider "Sketch", which may not actually have a Sketch package. >what do we do about alternative packages that provide different implementations >of the same functionality? I suppose we could reasonably expect to make >use of "import urllib2 as urllib" to take care of that. >Does this include platform name, platform version, and architecture? Like >redhat-7.0-x86, windows-nt-hppa, etc? I wish I knew! This is the last remaining XXX in the PEP. Thoughts? > Freely-Redistributable > Group (such as "Database", "Network/SMTP", etc)? > Provides (maybe "urllib2" would provide "urllib"?) > Requires (dependences -- RPM for example has multiple lines of the > form "Requires: initscripts >= 3.25", "Requires: openssl >= 0.9.4") I'm lukewarm; can we decide on syntax for all of those fields? (Semantics can wait; as long as users can put 'Group: blah', we can figure out what the groups should be later.) Can Freely-Redistributable be derived from the License field? (Side effect: discourages using your own Open Source license). Will comma-separated values be sufficient for the last 3? --amk From mal@lemburg.com Thu Mar 15 12:44:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Mar 15 12:44:01 2001 Subject: [Distutils] Storing metadata in XML vs. RFC-822 (Re: Distutils-SIG digest, Vol 1 #478 - 13 msgs) References: Message-ID: <3AB0FF00.FCB3CC7@lemburg.com> Alexandre Fayolle wrote: > > On Thu, 15 Mar 2001, Paul Prescod wrote: > > > I didn't really intend for it to be anything complex. > > > > for name in metadatanames: > > print "<"+name.lower()+">"+content+"" > > > > Maybe it is intrisically more complex them I am thinking... > > You'd need at least to escape '&' and '<' in content. I think this discussion is going overboard here... the metadata file will be generated by distutils, so the format is really secondary -- no human will read the file, so it can basically be any format you want it to. Please let's get on with defining the important parts first, i.e. which keywords to include and how the values should be formatted. The backend format can then be implemented in whatever machine readable format is suitable, be it XML or RFC-822 style headers. We can even change the format at some later point, since regenerating it will be easy. BTW, I don't remember having seen this in the discussion so far, but I think that we will definitely also need a version field for the metadata format itself (or maybe simply the distutils version which the package assumes being installed -- this can then be used to track the meta data format). -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Mar 15 12:48:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Mar 15 12:48:01 2001 Subject: [Distutils] Metadata fields References: <20010315140608.B217BEA11D@oratrix.oratrix.nl> Message-ID: <3AB0FFED.325593E6@lemburg.com> Jack Jansen wrote: > > Could we add a field that would allow for the functionality that is > now in the (very little known) checkversion.py script? Doesn't the Version field have this information ? > I think that it would be good enough if the metadata file contained > the URL where the current metadata file is stored. What checkversion > would then do is run through your Python installation looking for > metadata files, and for each one found it would retrieve the current > version of that file over the net. If the version number in the > net-based file was higher than the one in the file on your disk it > would tell you there's a new version of the package available (and > probably offer to download it, etc). Nice idea -- perhaps we could integrate this using the warning framework and using a special Python command line option to trigger the check version testing... -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller@ion-tof.com Thu Mar 15 13:14:02 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 15 13:14:02 2001 Subject: [Distutils] Metadata fields References: <20010315140608.B217BEA11D@oratrix.oratrix.nl> <3AB0FFED.325593E6@lemburg.com> Message-ID: <099d01c0ad7b$a37ffab0$e000a8c0@thomasnotebook> [Marc-Andre Lemburg] > Nice idea -- perhaps we could integrate this using the warning > framework and using a special Python command line option to trigger > the check version testing... Please keep distutils compatible with python 1.5.2! Thomas From akuchlin@mems-exchange.org Thu Mar 15 13:20:02 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Mar 15 13:20:02 2001 Subject: [Distutils] New draft of PEP, and list of licenses Message-ID: 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 From s-thapa-11@alumni.uchicago.edu Thu Mar 15 13:42:01 2001 From: s-thapa-11@alumni.uchicago.edu (s-thapa-11@alumni.uchicago.edu) Date: Thu Mar 15 13:42:01 2001 Subject: [Distutils] New draft of PEP, and list of licenses In-Reply-To: ; from akuchlin@mems-exchange.org on Thu, Mar 15, 2001 at 01:19:52PM -0500 References: Message-ID: <20010315125150.C1575@hepcat.telocity.com> --69pVuxX8awAiJ7fD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2001 at 01:19:52PM -0500, Andrew Kuchling wrote: > I've updated the text of PEP 241: > http://python.sourceforge.net/peps/pep-0241.html An optional size field would also be useful but can be left out until 2.2 --=20 ------------------------------------------------------------------ Suchandra S. Thapa=20 s-thapa-11@alumni.uchicago.edu ------------------------------------------------------------------ --69pVuxX8awAiJ7fD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6sQ9G0hoo1RInvaIRAuepAKDEVhlnzxy7kuXeRgrXXCsKhwskEQCfWQYZ y0f+8cbn8cy3WOsqgO+tsZY= =qzua -----END PGP SIGNATURE----- --69pVuxX8awAiJ7fD-- From jack@oratrix.nl Thu Mar 15 17:16:20 2001 From: jack@oratrix.nl (Jack Jansen) Date: Thu Mar 15 17:16:20 2001 Subject: [Distutils] Metadata fields In-Reply-To: Message by "M.-A. Lemburg" , Thu, 15 Mar 2001 18:46:21 +0100 , <3AB0FFED.325593E6@lemburg.com> Message-ID: <20010315221520.553B7EA11D@oratrix.oratrix.nl> Recently, "M.-A. Lemburg" said: > Jack Jansen wrote: > > > > Could we add a field that would allow for the functionality that is > > now in the (very little known) checkversion.py script? > > Doesn't the Version field have this information ? The version field has half the info. The other half needed is an easy way to find the most recent version. With a whole file of metainformation it's probably the easiest to just make the current metainformationfile readily accessible on the net (i.e. not only in an installer archive) and make the URL "permanent". Actually the URL doesn't even have to be permanent: if the version 1.0 metainfofile has a URL www.veryoldsite.com/bla/package/metainfo.xml, and that file (for version 2.0) has www.newersite.com/bla/package/metainfo.xml you could keep a chain of the things. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From phrxy@csv.warwick.ac.uk Thu Mar 15 18:46:04 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Thu Mar 15 18:46:04 2001 Subject: [Catalog-sig] Re: [Distutils] PEP 241 draft In-Reply-To: <20010315120212.F2440@ute.cnri.reston.va.us> Message-ID: On Thu, 15 Mar 2001, Andrew Kuchling wrote: [...] > figure out what the groups should be later.) Can > Freely-Redistributable be derived from the License field? (Side > effect: discourages using your own Open Source license). Will [...] Freely-Redist. is not something everyone understands in the same way, so I think it is best done (if at all) as a derived field. That way it is at least consistent. John From mal@lemburg.com Fri Mar 16 12:46:24 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Mar 16 12:46:24 2001 Subject: [Distutils] Metadata fields References: <20010315221520.553B7EA11D@oratrix.oratrix.nl> Message-ID: <3AB2513E.4E095C28@lemburg.com> Jack Jansen wrote: > > Recently, "M.-A. Lemburg" said: > > Jack Jansen wrote: > > > > > > Could we add a field that would allow for the functionality that is > > > now in the (very little known) checkversion.py script? > > > > Doesn't the Version field have this information ? > > The version field has half the info. The other half needed is an easy > way to find the most recent version. With a whole file of > metainformation it's probably the easiest to just make the current > metainformationfile readily accessible on the net (i.e. not only in > an installer archive) and make the URL "permanent". Actually the URL > doesn't even have to be permanent: if the version 1.0 metainfofile has > a URL www.veryoldsite.com/bla/package/metainfo.xml, and that > file (for version 2.0) has www.newersite.com/bla/package/metainfo.xml > you could keep a chain of the things. Good idea. How about a "Metainfo-URL" field which then points to the metainfo file on some web-site ?! (It could default to /-metainfo.xml) -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller@ion-tof.com Fri Mar 16 15:53:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Mar 16 15:53:01 2001 Subject: [Distutils] Is a version number required in the setup script? Message-ID: <01af01c0ae5a$fec029b0$e000a8c0@thomasnotebook> It has been reported by Riaan Booysen that executing 'python setup.py bdist_wininst' with a setup-script not defining a version number dies with a traceback. The reason is that distutils uses '???' as version number, and xxx-???.win32.zip is an invalid filename on windows: c:\util\zip.exe -rq C:\temp\test\build\bdist.win32\wininst\x-???.win32.zip . zip error: Invalid argument zip error: Could not create output file (C:/temp/test/build/bdist.win32/wininst/x-???.win32.zip) creating 'C:\temp\test\build\bdist.win32\wininst\x-???.win32.zip' and adding '.' to it Exception exceptions.AttributeError: "'ZipFile' instance has no attribute 'fp'" in ignored error: C:\temp\test\build\bdist.win32\wininst\x-???.win32.zip: Invalid argument IMO this should be fixed so that either a check is done for a version number - or - a version number of 0.0.0 should be used. Thomas From mal@lemburg.com Fri Mar 16 16:11:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Mar 16 16:11:01 2001 Subject: [Distutils] Is a version number required in the setup script? References: <01af01c0ae5a$fec029b0$e000a8c0@thomasnotebook> Message-ID: <3AB28119.C54F2C95@lemburg.com> Thomas Heller wrote: > > It has been reported by Riaan Booysen that executing > 'python setup.py bdist_wininst' with a setup-script > not defining a version number dies with a traceback. > The reason is that distutils uses '???' as version number, > and xxx-???.win32.zip is an invalid filename on windows: > > c:\util\zip.exe -rq C:\temp\test\build\bdist.win32\wininst\x-???.win32.zip . > zip error: Invalid argument > > zip error: Could not create output file (C:/temp/test/build/bdist.win32/wininst/x-???.win32.zip) > creating 'C:\temp\test\build\bdist.win32\wininst\x-???.win32.zip' and adding '.' to it > Exception exceptions.AttributeError: "'ZipFile' instance has no attribute 'fp'" in 00885B24> ignored > error: C:\temp\test\build\bdist.win32\wininst\x-???.win32.zip: Invalid argument > > IMO this should be fixed so that either a check is done > for a version number - or - a version number of 0.0.0 > should be used. I'd suggest that a DistutilsError is raised preventing the build altogether. Packages without version number don't really make sense, IMHO. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Fri Mar 16 16:17:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri Mar 16 16:17:01 2001 Subject: [Distutils] Is a version number required in the setup script? In-Reply-To: <3AB28119.C54F2C95@lemburg.com>; from mal@lemburg.com on Fri, Mar 16, 2001 at 10:09:45PM +0100 References: <01af01c0ae5a$fec029b0$e000a8c0@thomasnotebook> <3AB28119.C54F2C95@lemburg.com> Message-ID: <20010316161656.A5687@ute.cnri.reston.va.us> On Fri, Mar 16, 2001 at 10:09:45PM +0100, M.-A. Lemburg wrote: >Thomas Heller wrote: >> IMO this should be fixed so that either a check is done >> for a version number - or - a version number of 0.0.0 >> should be used. > >I'd suggest that a DistutilsError is raised preventing the build >altogether. Packages without version number don't really make >sense, IMHO. Agreed. --amk From jafo@tummy.com Sat Mar 17 03:17:00 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 17 03:17:00 2001 Subject: [Distutils] New draft of PEP, and list of licenses In-Reply-To: <20010315125150.C1575@hepcat.telocity.com>; from s-thapa-11@alumni.uchicago.edu on Thu, Mar 15, 2001 at 12:51:50PM -0600 References: <20010315125150.C1575@hepcat.telocity.com> Message-ID: <20010317011615.A29139@tummy.com> On Thu, Mar 15, 2001 at 12:51:50PM -0600, s-thapa-11@alumni.uchicago.edu wrote: > An optional size field would also be useful but can be left out until >2.2 My concern with that is having it get out of sync. "Ok, now I've built an HP-UX sd archive of this package, I just need to copy the meta-data over and... It would also be useful to have an MD5 and/or signature, but it runs into similar problems. However, I can say that in swalow it's very nice to have these fields. I use size and md5sum to verify a good download, and if they don't both match it goes on to another URL listed to try getting another copy of it. Sean -- If you talk to God, you are praying; if God talks to you, you have schizophrenia. -- Thomas Szasz Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sat Mar 17 03:47:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 17 03:47:01 2001 Subject: [Distutils] New draft of PEP, and list of licenses In-Reply-To: ; from akuchlin@mems-exchange.org on Thu, Mar 15, 2001 at 01:19:52PM -0500 References: Message-ID: <20010317014652.B29139@tummy.com> Hmm, I think the introduction needs to change. To me, it implies that it only talks about the fields. Something like: This PEP describes the processes used in adding metadata to Python packages. It includes specifics of the field names, encodings, descriptions, and usage. This PEP also specifies the file name which the metadata should be stored in. In the third paragraph, change "METADATA" to "PKG-INFO". I think it's useful to specify what fields must be specified once or multiple times. For example, add a paragaph to "Fields" section: Fields marked with "(Multiple use)" may be specified multiple times in a single "PKG-INFO" file. Other fields may only occur once in a "PKG-INFO" file. Fields marked with "(optional)" are not required to appear in a valid "PKG-INFO" file, all other fields must be present. How about instead of "Platforms", we have "Platform (Multiple use)"? The same may be said of "Keywords", though it probably makes sense to allow comma-separated lists as the RHS for these. Author could be a multiple use field, but then you need to specify how names and e-mails are linked. What about having "Author" act like "From:", and it can be either name, address, or both? Author: If it's multi-line, shouldn't it include spaces? Author: C. Schultz Universal Features Syndicate Los Angeles, CA (Yeah, I know this contradicts what I said above about combining author and author-email. I'm prepared to be wrong about one or both of these. ;-) Keywords: It should specify how the list is separated -- in the example it's space separated. RFC822 seems more fond of using commas... The examples should have the field names in them, as in the Author example above. Example: Metadata-Version: 1.0 Name: BeagleVote Version: 1.0a2 Summary: A module for collecting votes from beagles. Description: This module collects votes from beagles in order to determine their electoral wishes. Do NOT try to use this module with basset hounds; it makes them grumpy. Keywords: dog puppy voting election Home-page: http://www.example.com/~cschultz/bvote/ Author: C. Schultz Universal Features Syndicate Los Angeles, CA Author-email: "C. Schultz" License: Python Not sure why I missed these on the first go-round. Sean -- Why isn't phonetic spelled the way it sounds? Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sat Mar 17 03:54:02 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 17 03:54:02 2001 Subject: [Catalog-sig] Re: [Distutils] PEP 241 draft In-Reply-To: ; from phrxy@csv.warwick.ac.uk on Thu, Mar 15, 2001 at 11:45:22PM +0000 References: <20010315120212.F2440@ute.cnri.reston.va.us> Message-ID: <20010317015308.C29139@tummy.com> On Thu, Mar 15, 2001 at 11:45:22PM +0000, John J. Lee wrote: >Freely-Redist. is not something everyone understands in the same way, so I Such is life... There are a lot of things that not everyone understands in the same way. We put a reasonable definition in the PEP, and that's what's used as the guide for understanding it. If you think the name is bad, I'm open to another name, but I think specifying that is useful. To some, the "Freely-redistributable" field is more important than the License field. The lack of such a field has constantly been painful in CPAN. At the least, if we imply this from the License field, the PEP should list what licenses we imply that from. On thinking of it more, I'm thinking that another name is probably good. "Redistributable" with a value of "yes", "no", or "unmodified". For example, DJB's stuff is freely redistributable ONLY if it's unmodified or binaries built from an unmodified source. Sean -- Linux: When you need to run like a greased weasel. -- Sean Reifschneider, 1998 Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sat Mar 17 04:00:02 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 17 04:00:02 2001 Subject: [Distutils] Metadata fields In-Reply-To: <20010315221520.553B7EA11D@oratrix.oratrix.nl>; from jack@oratrix.nl on Thu, Mar 15, 2001 at 11:15:15PM +0100 References: <20010315221520.553B7EA11D@oratrix.oratrix.nl> Message-ID: <20010317015945.D29139@tummy.com> On Thu, Mar 15, 2001 at 11:15:15PM +0100, Jack Jansen wrote: >The version field has half the info. The other half needed is an easy >way to find the most recent version. With a whole file of Well, the idea is that once we have this meta-data in a standard format, it's easy to upload to the catalog server. Then a user could simply query the catalog server and ask it what the most recent version of the package is. This prevents (in theory) the problem of the URL changing after a version has been pushed out... I've even got the code together for automaticly pushing out the meta-data file (even if it's simply included in the sdist tar file) to the catalog server. Sean -- Put out fires during the daytime. Do your real work at night. Sleep is just an addiction. -- Dieter Muller Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sat Mar 17 04:08:03 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 17 04:08:03 2001 Subject: [Distutils] Metadata fields In-Reply-To: <20010315114636.E2440@ute.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Mar 15, 2001 at 11:46:36AM -0500 References: <20010312153142.A13192@ute.cnri.reston.va.us> <3AAD3B9A.C906E5DF@digicool.com> <20010314221903.G30951@tummy.com> <20010315114636.E2440@ute.cnri.reston.va.us> Message-ID: <20010317020705.E29139@tummy.com> On Thu, Mar 15, 2001 at 11:46:36AM -0500, Andrew Kuchling wrote: >But then the meta-data file can get lost; I like having it in the >tarball so if you have the source, you automatically have the >metadata. Yeah, I like it too. But it's harder to do when the "source" is an HP-UX sd format file (which I don't know the format on), for example. I wrote the code to directly extract the PKG-INFO data out of a .tar, .tar.gz, .tar.bz, or .tar.Z file on the trip back home, so we're covered on that side... .zip should be fairly easy to deal with... >The problem is, "where do we put it?" If I generate an RPM, where >does PKG-INFO go? How do you find it again? Where does it go in a >Windows .exe installer so that a catalog can read it out? This is a >case where separate metadata would really make sense, but I think it >can't be resolved for 2.1. Well, you could write it to the "dist" file with a different suffix, and/or upload the meta-data and the Windows .exe file to my catalog server as a multi-part MIME message. I have the code ready to do that from both the client and server side. Platform isn't really that much information, unless it's encoded like the GNU platforms. "redhat-7.0-x86" Something like that. >That's up to the cataloguer, not the Distutils. I'll reword that in >the PEP. I'll buy that. Sean -- I keep just enough vi knowledge in my head so that I can edit a Makefile and build Emacs. -- Tony Foiani, 1999 Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From mwa@gate.net Sat Mar 17 07:48:01 2001 From: mwa@gate.net (Mark W. Alexander) Date: Sat Mar 17 07:48:01 2001 Subject: [Distutils] Metadata fields In-Reply-To: <20010317020705.E29139@tummy.com> Message-ID: On Sat, 17 Mar 2001, Sean Reifschneider wrote: > Date: Sat, 17 Mar 2001 02:07:05 -0700 > From: Sean Reifschneider > To: Andrew Kuchling , distutils-sig@python.org > Subject: Re: [Distutils] Metadata fields > > On Thu, Mar 15, 2001 at 11:46:36AM -0500, Andrew Kuchling wrote: > >But then the meta-data file can get lost; I like having it in the > >tarball so if you have the source, you automatically have the > >metadata. > > Yeah, I like it too. But it's harder to do when the "source" is an > HP-UX sd format file (which I don't know the format on), for example. > I wrote the code to directly extract the PKG-INFO data out of a .tar, > .tar.gz, .tar.bz, or .tar.Z file on the trip back home, so we're > covered on that side... .zip should be fairly easy to deal with... But that's not really the source. Since distutils handles (in theory) all binary formats, the catalog should only have to manage information about the "real" distutils source with some kind of pointer to where particular binaries live. Also, Andrew, are these fields going to be implemented in the Distribution metatdata class? I'm playing with an abstract binary package class and it would be perfect to have all this info available via the distribution. Mark From mwa@gate.net Sat Mar 17 07:58:01 2001 From: mwa@gate.net (Mark W. Alexander) Date: Sat Mar 17 07:58:01 2001 Subject: [Distutils] New draft of PEP, and list of licenses In-Reply-To: <20010317011615.A29139@tummy.com> Message-ID: On Sat, 17 Mar 2001, Sean Reifschneider wrote: > Date: Sat, 17 Mar 2001 01:16:15 -0700 > From: Sean Reifschneider > To: Andrew Kuchling , > Distutils-sig > Subject: Re: [Distutils] New draft of PEP, and list of licenses > > On Thu, Mar 15, 2001 at 12:51:50PM -0600, s-thapa-11@alumni.uchicago.edu wrote: > > An optional size field would also be useful but can be left out until > >2.2 > > My concern with that is having it get out of sync. "Ok, now I've built > an HP-UX sd archive of this package, I just need to copy the meta-data > over and... > It would also be useful to have an MD5 and/or signature, but it runs into > similar problems. However, I can say that in swalow it's very nice to > have these fields. I use size and md5sum to verify a good download, and > if they don't both match it goes on to another URL listed to try getting > another copy of it. Both size and MD5 could only apply to the distutils archive. Binary packages produced in any format will have different sizes and signatures. I agree that they're usefull, but they'd need to be provided by the binary package routines and how they would be handled depends on that particular package manager. Unless the catalog manages the size and signatures of all files under it's control, but that raises the issue of whether the numbers can be trusted. mwa From mwa@gate.net Sat Mar 17 08:14:01 2001 From: mwa@gate.net (Mark W. Alexander) Date: Sat Mar 17 08:14:01 2001 Subject: [Distutils] New draft of PEP, and list of licenses In-Reply-To: <20010317014652.B29139@tummy.com> Message-ID: On Sat, 17 Mar 2001, Sean Reifschneider wrote: > Subject: Re: [Distutils] New draft of PEP, and list of licenses > The examples should have the field names in them, as in the Author > example above. > > Example: > Metadata-Version: 1.0 > Name: BeagleVote > Version: 1.0a2 > Summary: A module for collecting votes from beagles. > Description: This module collects votes from beagles in order to > determine their electoral wishes. > > Do NOT try to use this module with basset hounds; it makes > them grumpy. > Keywords: dog puppy voting election > Home-page: http://www.example.com/~cschultz/bvote/ > Author: C. Schultz > Universal Features Syndicate > Los Angeles, CA > Author-email: "C. Schultz" > License: Python Seing this laid out like this, I think we need the addition of "Revision" to indicate the version of the setup.py/distutils configuration stuff. There are a lot of times where the actual software doesn't change but the packaging process does. It would be important to know that BeagleVote 1.0a2 package revision 1 (which, say, the packager didn't include doc files) is different from package revision 2 (which did). Since distutils allows anyone to make a package, this may need to be a derived field. Maybe based on packager, since the same module could be packaged by multiple packagers. Also, hardcoded revisions in setup.py wouldn't make much sense, since the packager would be likely to leave it unchanged regardless of how many times they change the package. It would be best if it was a required command line option to the bdist* commands. This is all based on the way things work these days, where the package author is not necessarily (or even likely) to be the packager. If distutils gets broadly accepted, and most authors use it, this gets less significant. If you want to be broadly optimistic about distutils acceptance, ignore this suggestion (I'm not sure I'm convinced it's needed.) (I also don't see the packager information above, but I thought it was in the PEP. If it's not, it probably should be as well. Just name and email.) mwa From c.evans@clear.net.nz Sat Mar 17 08:20:01 2001 From: c.evans@clear.net.nz (Carey Evans) Date: Sat Mar 17 08:20:01 2001 Subject: [Distutils] Re: [Catalog-sig] Re: PEP 241 draft References: <20010315120212.F2440@ute.cnri.reston.va.us> <20010317015308.C29139@tummy.com> Message-ID: <877l1ov8h9.fsf@psyche.dnsalias.org> Sean Reifschneider writes: > To some, the "Freely-redistributable" field is more important than the > License field. The lack of such a field has constantly been painful in > CPAN. At the least, if we imply this from the License field, the PEP > should list what licenses we imply that from. CTAN has already done this for their packages, distinguishing "Free software" from "Nonfree software" according to whether the license "satisfies the criteria contained in the Debian Free Software Guidelines". They have a list of license keywords, and whether they are stored in their free or nonfree hierarchy, at: http://www.ctan.org/tex-archive/help/Catalogue/licenses.html With the addition of old- and new-style Python licenses to this list, I suggest we adopt CTAN's licenses and classifications. It seems to have worked for them for a while now. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Quiet, you'll miss the humorous conclusion." From akuchlin@mems-exchange.org Sat Mar 17 11:05:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat Mar 17 11:05:01 2001 Subject: [Distutils] PEP 241 draft In-Reply-To: <877l1ov8h9.fsf@psyche.dnsalias.org>; from c.evans@clear.net.nz on Sun, Mar 18, 2001 at 02:19:14AM +1300 References: <20010315120212.F2440@ute.cnri.reston.va.us> <20010317015308.C29139@tummy.com> <877l1ov8h9.fsf@psyche.dnsalias.org> Message-ID: <20010317110414.A6504@ute.cnri.reston.va.us> On Sun, Mar 18, 2001 at 02:19:14AM +1300, Carey Evans wrote: >With the addition of old- and new-style Python licenses to this list, >I suggest we adopt CTAN's licenses and classifications. It seems to >have worked for them for a while now. Good idea; done. The old Python license is just the MIT/X11 one, so only a single "Python" entry is needed. I've dropped the LaTeX license from the list, too. Thanks for pointing out CTAN! --amk From akuchlin@mems-exchange.org Sat Mar 17 11:30:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat Mar 17 11:30:01 2001 Subject: [Distutils] New draft of PEP, and list of licenses In-Reply-To: <20010317014652.B29139@tummy.com>; from jafo@tummy.com on Sat, Mar 17, 2001 at 01:46:52AM -0700 References: <20010317014652.B29139@tummy.com> Message-ID: <20010317112909.B6504@ute.cnri.reston.va.us> On Sat, Mar 17, 2001 at 01:46:52AM -0700, Sean Reifschneider wrote: >How about instead of "Platforms", we have "Platform (Multiple use)"? I'm starting to think we can't resolve the meaning of platforms. * The user has to specify it; we can't infer anything from sys.platform for a source package. sys.platform is useful for a binary package, though. * IMHO it's unreasonable to expect the user to include sys.platform values like 'linux2' or 'freebsd4'. So what could it be? A list of specifications from the list "POSIX", "Windows", "MacOS 9 or earlier", "BeOS", and a few more? Just a text field where you can put arbitrary things: "Linux 2.2 kernels with a working generic SCSI driver"? In the latter case, maybe developers would simply put that in their description, and "Platform" would only be present in the metadata for a binary release, never entered by a developer at all. We *really* need to resolve the platform issue; it's the last thing to do before posting the PEP to python-dev/c.l.p.a and implementing it. Your other rewrites have been applied; thanks! --amk From akuchlin@mems-exchange.org Sat Mar 17 15:21:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat Mar 17 15:21:01 2001 Subject: [Distutils] Is a version number required in the setup script? In-Reply-To: <3AB28119.C54F2C95@lemburg.com>; from mal@lemburg.com on Fri, Mar 16, 2001 at 10:09:45PM +0100 References: <01af01c0ae5a$fec029b0$e000a8c0@thomasnotebook> <3AB28119.C54F2C95@lemburg.com> Message-ID: <20010317152057.B13147@ute.cnri.reston.va.us> On Fri, Mar 16, 2001 at 10:09:45PM +0100, M.-A. Lemburg wrote: >I'd suggest that a DistutilsError is raised preventing the build >altogether. Packages without version number don't really make >sense, IMHO. I've just checked in a change to distutils/dist.py to signal an error if the version number isn't specified. We'll see if people scream about this being a problem (I expect not). --amk From dyoo@hkn.eecs.berkeley.edu Sat Mar 17 23:03:00 2001 From: dyoo@hkn.eecs.berkeley.edu (Daniel Yoo) Date: Sat Mar 17 23:03:00 2001 Subject: [Distutils] patching filelist.py to allow quoted strings Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --545289610-1437158962-984888123=:20909 Content-Type: TEXT/PLAIN; charset=US-ASCII Dmitry Balabanov on python-help had requested information about why the following Manifest.in line didn't work; he used the following line: ### recursive-include 'Max Fray' *.txt ### Because there were spaces in the directory, it didn't quite parse correctly. I've isolated filelist._parse_template_line() to be responsible for parsing out these lines. _parse_template_line() uses a simple string.split() to break a line into tokens. I'd like to know if it's a good idea to allow spaces in directory names like that. I'm attaching a patch that tries to split the line and takes quoted elements into account. I'm in digest mode, and a newbie at distutils, so please be gentle. *grin* --- Original message follows below: --- >From dimonb@beep.ru Sat Mar 10 11:36:01 2001 From: dimonb@beep.ru (Balabanov Dmitry) Date: Sat, 10 Mar 2001 11:36:01 +0000 Subject: [Python-Help] help with distutils Message-ID: <01031011360100.00515@doors> Hi!! Problem is very simple but i can't solve it... I have such string in MANIFEST.in: recursive-include 'Max Fray' *.txt But `python setup.py sdist --manifest-only` spawns: running sdist warning: sdist: missing required meta-data: url reading manifest template 'MANIFEST.in' warning: no files found matching 'Fray'' under directory ''Max' warning: no files found matching '*.txt' under directory ''Max' writing manifest file 'MANIFEST' problem is rather simple but i don't know how to solve it with simple methods:) do you? Best regards, DimonB --545289610-1437158962-984888123=:20909 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="filelist.py.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="filelist.py.diff" PyBmaWxlbGlzdC5weS5kaWZmDQpJbmRleDogZGlzdHV0aWxzL2ZpbGVsaXN0 LnB5DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2c3Jv b3QvcHl0aG9uL2Rpc3R1dGlscy9kaXN0dXRpbHMvZmlsZWxpc3QucHksdg0K cmV0cmlldmluZyByZXZpc2lvbiAxLjgNCmRpZmYgLWMgLXIxLjggZmlsZWxp c3QucHkNCioqKiBkaXN0dXRpbHMvZmlsZWxpc3QucHkJMjAwMC8wOS8yNiAw MjowMjo1MQkxLjgNCi0tLSBkaXN0dXRpbHMvZmlsZWxpc3QucHkJMjAwMS8w My8xOCAwMzo0NzozMA0KKioqKioqKioqKioqKioqDQoqKiogOTMsMTAxICoq KioNCiAgDQogIA0KICAgICAgIyAtLSAiRmlsZSB0ZW1wbGF0ZSIgbWV0aG9k cyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAg ICAgIA0KICAgICAgZGVmIF9wYXJzZV90ZW1wbGF0ZV9saW5lIChzZWxmLCBs aW5lKToNCiEgICAgICAgICB3b3JkcyA9IHN0cmluZy5zcGxpdChsaW5lKQ0K ICAgICAgICAgIGFjdGlvbiA9IHdvcmRzWzBdDQogIA0KICAgICAgICAgIHBh dHRlcm5zID0gZGlyID0gZGlyX3BhdHRlcm4gPSBOb25lDQotLS0gOTMsMTI3 IC0tLS0NCiAgDQogIA0KICAgICAgIyAtLSAiRmlsZSB0ZW1wbGF0ZSIgbWV0 aG9kcyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CisgDQorICAgICBkZWYgX3NwbGl0X3RlbXBsYXRlX2xpbmUgKHNlbGYsIGxp bmUpOg0KKyAgICAgICAgICIiIkEgdmVyc2lvbiBvZiBzdHJpbmcuc3BsaXQo KSB0aGF0IGFsbG93cyBxdW90ZWQgc3RyaW5ncy4iIiINCisgICAgICAgICBz dHJpbmdfbGl0ID0gIHInJycoWyJcJ10pICAgICAgICAgICAgIyBXZSBzdGFy dCB3aXRoIGEgcXVvdGUuDQorICAgICAgICAgICAgICAgICAgICAgICAgICAg KCAgICAgICAgICAgICAgICAgICMgVGhlIDJuZCBncm91cCBpcyBtYWRlIG9m DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCAgICAgICAgICAg ICAgICMgdGhlIGZvbGxvd2luZyBjaGFyczogICANCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFxcWyJcJ10gfCAgICAgIyBBbiBlc2NhcGVk IHF1b3RlLCBvcg0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg W15cMV0gICAgICAgICAjIGFueXRoaW5nIHRoYXQgZG9lcyBub3QNCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBt YXRjaCB0aGUgc3RhcnQgcXVvdGUsDQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICApKj8gICAgICAgICAgICAgICMgd2l0aCBub24tZ3JlZWRpbmVz cy4NCisgICAgICAgICAgICAgICAgICAgICAgICAgICApICAgICAgICAgICAg ICAgICAgICANCisgICAgICAgICAgICAgICAgICAgICAgICAgICBcMScnJyAg ICAgICAgICAgICAgIyBGaW5hbGx5LCBlbmQgd2l0aA0KKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIHRoZSBtYXRj aGluZyBmaXJzdCBxdW90ZS4NCisgICAgICAgICBzdHJpbmdfbGl0X3JlID0g cmUuY29tcGlsZShzdHJpbmdfbGl0LCByZS5WRVJCT1NFKQ0KKyAgICAgICAg IG5vbl9zcGFjZV9yZSA9IHJlLmNvbXBpbGUocicoKFteXHNdKikpJykNCisg ICAgICAgICAjIyBUaGUgZXh0cmEgcGFyZW5zIGFsbG93IHVzIHRvIHRha2Ug Z3JvdXAoMikgb2Ygbm9uX3NwYWNlX3JlIHRvby4NCisgICAgICAgICBpdGVt cyA9IFtdDQorICAgICAgICAgd2hpbGUgbGluZToNCisgICAgICAgICAgICAg bGluZSA9IHN0cmluZy5sc3RyaXAobGluZSkNCisgICAgICAgICAgICAgbTEs IG0yID0gc3RyaW5nX2xpdF9yZS5tYXRjaChsaW5lKSwgbm9uX3NwYWNlX3Jl Lm1hdGNoKGxpbmUpDQorICAgICAgICAgICAgIG1hdGNoID0gbTEgb3IgbTIN CisgICAgICAgICAgICAgaWYgbWF0Y2ggYW5kIG1hdGNoLmdyb3VwKCk6DQor ICAgICAgICAgICAgICAgICBpdGVtcy5hcHBlbmQobWF0Y2guZ3JvdXAoMikp DQorICAgICAgICAgICAgICAgICBsX2luZGV4ID0gbWF0Y2guc3BhbigwKVsx XQ0KKyAgICAgICAgICAgICAgICAgbGluZSA9IGxpbmVbbF9pbmRleDpdDQor ICAgICAgICAgcmV0dXJuIGl0ZW1zDQogICAgICANCiAgICAgIGRlZiBfcGFy c2VfdGVtcGxhdGVfbGluZSAoc2VsZiwgbGluZSk6DQohICAgICAgICAgd29y ZHMgPSBzZWxmLl9zcGxpdF90ZW1wbGF0ZV9saW5lKGxpbmUpDQogICAgICAg ICAgYWN0aW9uID0gd29yZHNbMF0NCiAgDQogICAgICAgICAgcGF0dGVybnMg PSBkaXIgPSBkaXJfcGF0dGVybiA9IE5vbmUNCg== --545289610-1437158962-984888123=:20909-- From akuchlin@mems-exchange.org Mon Mar 19 14:22:02 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon Mar 19 14:22:02 2001 Subject: [Distutils] Finishing PEP 241 Message-ID: I want to get the last XXX removed from PEP 241 so it can be posted to c.l.py.a and python-dev *today*. The missing bit is: Platform (multiple use) A (XXX whitespace? comma?)-separated list of platform specifications. Platform specifications are limited to the following list: XXX copy list from PPD? SourceForge? Example: 'XXX' So, what to do? Some options are: * Specify a short and incomplete list of platform specs: MacOS/Windows/POSIX/BeOS/... State in the PEP that this list is incomplete. Binary distributions will use a different metadata header (Compiled-Platform, Supported-Platform, or something like that) to specify the OS and CPU they were compiled for. * Leave 'Platform' to be filled in for binary distributions. Developers should put platform limitation notes in the 'Description'. I lean toward #1, and if I don't hear any strong reasons to do otherwise, that's what I'll check it and post, sometime after 5PM EST. --amk From phrxy@csv.warwick.ac.uk Mon Mar 19 14:45:01 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Mon Mar 19 14:45:01 2001 Subject: [Distutils] Finishing PEP 241 In-Reply-To: Message-ID: On Mon, 19 Mar 2001, Andrew Kuchling wrote: [...] > So, what to do? Some options are: > > * Specify a short and incomplete list of platform specs: > MacOS/Windows/POSIX/BeOS/... State in the PEP that this list is > incomplete. Binary distributions will use a different metadata > header (Compiled-Platform, Supported-Platform, or something like > that) to specify the OS and CPU they were compiled for. [...] Sounds okay. Is there any reason not to use the os.name values for this? ie. 'nt', 'dos', 'posix', 'mac', 'os2', 'java', 'ce' etc ('beos' doesn't seem to be in the list for 2.0 -- was it a recent port, or what?) John From akuchlin@mems-exchange.org Mon Mar 19 20:03:02 2001 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Mon Mar 19 20:03:02 2001 Subject: [Distutils] PEP 241 posted Message-ID: <200103200117.UAA00611@mira.erols.com> I've posted PEP 241 to c.l.py.a, so make any final comments. Time for me to start implementing... --amk From jafo@tummy.com Tue Mar 20 01:50:02 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Tue Mar 20 01:50:02 2001 Subject: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism Message-ID: <20010319234933.A4356@tummy.com> Here is PEP 243, discussing how to make Distutils submit .tar.gz packages (and the like) to the mythical catalog server. I've got code for this prototyped, but give me a couple of days to make it completely PEP-compliant. Moshe has already commented: a. you don't say which URL to post to (just spell it out: POST http://modules.python.org:80/ (and let upload override that) b. have the codes be HTTP codes and the headers HTTP non-standard (X-) headers. how about using the HTTP headers and error-codes, and have *all* the page human readable. Good comments, I'll look at building them in... I look forward to any comments -- I'd like to start working on distutils patches within the week. Thanks, Sean ========================================================================== PEP: 243 Title: Module Repository Upload Mechanism Version: $Revision$ Author: jafo-pep@tummy.com (Sean Reifschneider) Status: Draft Type: Standards Track Created: 18-Mar-2001 Python-Version: 2.1 Post-History: Discussions-To: distutils-sig@python.org Abstract For a module repository system (such as Perl's CPAN) to be successful, it must be as easy as possible for module authors to submit their work. An obvious place for this submit to happen is in the Distutils tools after the distribution archive has been successfully created. For example, after a module author has tested their software (verifying the results of "setup.py sdist"), they might type "setup.py sdist --submit". This would flag Distutils to submit the source distribution to the archive server for inclusion and distribution to the mirrors. This PEP only deals with the mechanism for submitting the software distributions to the archive, and does not deal with the actual archive/catalog server. Upload Process The upload will include the Distutils "PKG-INFO" meta-data information (as specified in PEP-241 [1]), the actual software distribution, and other optional information. This information will be uploaded as a multi-part form encoded the same as a regular HTML file upload request. This form is posted using ENCTYPE="multipart/form-data" encoding. The upload will be made to the host "modules.python.org" on port 80/tcp. The form will consist of the following fields: distribution -- The file containing the module software (for example, a .tar.gz or .zip file). distmd5sum -- The MD5 hash of the uploaded distribution, encoded in ASCII representing the hexadecimal representation of the digest ("for byte in digest: s = s + ('%02x' % ord(byte))"). pkginfo -- The file containing the distribution meta-data (as specified in PEP-241 [1]). infomd5sum -- The MD5 hash of the uploaded meta-data, encoded in ASCII representing the hexadecimal representation of the digest ("for byte in digest: s = s + ('%02x' % ord(byte))"). platform (optional) -- A string representing the target platform for this distribution. This is only for binary distributions. It is encoded as "--". 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. Return Data The upload will report the status of the upload by sending the string "Upload status:" followed by one of the following: SUCCESS -- Indicates that the upload has succeeded. FAILURE -- The upload is, for some reason, unable to be processed. TRYAGAIN -- The server is unable to accept the upload at this time, but the client should try again at a later time. Potential causes of this are resource shortages on the server, administrative down-time, etc... Following the above string may be a human-readable string providing further information. This message continues to the end of the returned data-stream. Returned data which does not fit the above format should be treated as a temporary failure. Sample Form 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:

Upload file







Platforms The following are valid os names: debian hpux mandrake redhat solaris suse windows yellowdog The above include a number of different types of distributions of Linux. Because of versioning issues these must be split out, and it is expected that when it makes sense for one system to use distributions made on other similar systems, the download client will make the distinction. 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). The following are valid architectures: alpha hppa ix86 powerpc sparc ultrasparc Status I currently have a proof-of-concept client and server implemented. I plan to have the Distutils patches ready for the 2.1 release. Combined with Andrew's PEP-241 [1] for specifying distribution meta-data, I hope to have a platform which will allow us to gather real-world data for finalizing the catalog system for the 2.2 release. References [1] Metadata for Python Software Package, Kuchling, http://python.sourceforge.net/peps/pep-0241.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: -- I used to think that the brain was the most wonderful organ in my body. Then I realized who was telling me this. -- Emo Phillips Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From R.Liebscher@gmx.de Tue Mar 20 03:51:38 2001 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Tue Mar 20 03:51:38 2001 Subject: [Distutils] PEP241 platforms Message-ID: <3AB7198B.9E75A686@gmx.de> 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 From Paul.Moore@uk.origin-it.com Tue Mar 20 04:27:04 2001 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Tue Mar 20 04:27:04 2001 Subject: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> 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 > "--". 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. From jafo@tummy.com Tue Mar 20 05:21:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Tue Mar 20 05:21:01 2001 Subject: [Catalog-sig] RE: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com>; from Paul.Moore@uk.origin-it.com on Tue, Mar 20, 2001 at 09:25:00AM -0000 References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> Message-ID: <20010320031945.Y29553@tummy.com> On Tue, Mar 20, 2001 at 09:25:00AM -0000, Moore, Paul wrote: >This probably needs to include the Python version for which a binary >distribution was compiled. Good idea. >Why GPG? Is that available on all platforms? Could PGP signatures be used Because GPG is available on the server that will be accepting these connections. My understanding is that GPG can read some PGP encondings (more now that RSA has fallen out of patent), so I've changed this to read "GPG-compatible signature". You will note that it said *OPTIONAL* there... >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... I'll see if I can find the RFC which specifies this. It seems like 2388 may be the one, but 1867 seems to look promising also. >dos? beos? mac? This feels very Unix-specific... I'd be willing to bet that it covers a larger percentage of non-unix platforms than it does the unix platforms. I've added the ones listed above. >> 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 Seems pretty precise to me. Windows 2000 is "2000", NT is "nt", 95 is "95"... Distutils can't make a judgement about wether a package is likely to work on other similar platforms. Only somone who knows the system intimately can really determine if it's likely to break on other similar platforms. If they are really that close together, then the catalog client can decide that if it doesn't find a 2k package it should check to see if there are any NT packages available... The thing I wondered was wether it was important to differentiate Windows by the build number, but I think splitting it out by the vendor version is good enough. Sean -- If you talk to God, you are praying; if God talks to you, you have schizophrenia. -- Thomas Szasz Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From R.Liebscher@gmx.de Tue Mar 20 05:38:02 2001 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Tue Mar 20 05:38:02 2001 Subject: [Catalog-sig] RE: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <20010320031945.Y29553@tummy.com> Message-ID: <3AB732A9.5F39079@gmx.de> Sean Reifschneider wrote: > > ... > > >dos? beos? mac? This feels very Unix-specific... > > I'd be willing to bet that it covers a larger percentage of non-unix > platforms than it does the unix platforms. I've added the ones listed > above. There are more: "aix", "qnx". > ... Kind regards Rene Liebscher From akuchlin@mems-exchange.org Tue Mar 20 10:12:03 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Mar 20 10:12:03 2001 Subject: [Distutils] Patch for PEP 241 Message-ID: I've got a preliminary version of the patch to implement PEP 241: https://sourceforge.net/tracker/?func=detail&aid=407434&group_id=5470&atid=305470 There are still issues to resolve; I have to figure the right place to convert the keyword and platform options from strings to lists, and implement checking on the license option. A sample package containing a PKG-INFO file is at http://www.amk.ca/files/python/Distutils-1.0.2pre.tar.gz, should you want to test some code on it. --amk From amos@digicool.com Tue Mar 20 19:18:08 2001 From: amos@digicool.com (Amos Latteier) Date: Tue Mar 20 19:18:08 2001 Subject: [Distutils] Patch for PEP 241 References: Message-ID: <3AB7F2B4.EFDD80DB@digicool.com> Andrew Kuchling wrote: > > I've got a preliminary version of the patch to implement PEP 241: > > https://sourceforge.net/tracker/?func=detail&aid=407434&group_id=5470&atid=305470 It looks good! If and when we move to a more complex format I still think that it would be a good idea to add methods to the Metadata class to read and write this format. Heck it might even be useful now. That way if and when we change the meta-data format we won't have to change tools that use the meta-data file. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From akuchlin@mems-exchange.org Tue Mar 20 21:59:00 2001 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Tue Mar 20 21:59:00 2001 Subject: [Distutils] Final PEP 241 patch Message-ID: <200103210313.WAA01343@mira.erols.com> 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 From mal@lemburg.com Wed Mar 21 05:38:02 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Mar 21 05:38:02 2001 Subject: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> Message-ID: <3AB8843E.C32FEE74@lemburg.com> "Moore, Paul" wrote: > > 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 > > "--". > > This probably needs to include the Python version for which a binary > distribution was compiled. ...at least for Windows this is mandatory. You get nasty error messages otherwise. > > 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? I'd say go with PGP -- it is far more available and known than GPG... after all the intent of a signature is for the people who download the code to check it and if they don't know what GPG is, then it is of no practical use for them (hard to tell, if it's of practical use for them at all ;-). > > 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... Can't we just specify: use HTTP POST with multipart/form-data encoding and then redirect to the RFC (can't remember the number) or Netscape description of the form upload proposal ?! > > 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 :-) You may want to take a look at platform.py available from my Python Pages for ways to "define" a platform information string. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Wed Mar 21 06:20:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Mar 21 06:20:01 2001 Subject: [Distutils] Tasks arising from IPC9 References: Message-ID: <3AB88E28.4D718C93@lemburg.com> Andrew Kuchling wrote: > > 1) For 2.1final, change the Distutils sdist command to construct a > text file containing the metadata for a package. Exactly *what* > metadata to collect was left open for subsequent discussion on the > Catalog-SIG. (Amos has a patch to implement this that I'll look at > when I can.) > > This is the only thing to be done in time for 2.1, so it's the only > really pressing task. > > 2) Once that metadata support is there, someone can start running an > experimental swalow server and begin adding to its database. > If Python 2.2 comes along in 6-12 months, that should be enough > time to have an idea of what should go into 2.2 to support it. > > 3) Other Distutils changes would be to design and create a package > database, and implement an uninstall command. The 'sdist' command > would also grow an --upload or --register option that would > automatically submit the package to the catalog (but first we'd need > to finalize how that should be done). Note that we already decided on the name of the uninstall command at the conference: "uninstall". Package developers can use this command name to implement this feature in a forward compatible way. Another point I'd like to raise is that of providing a generic "test" command. Most packages provide regression tests which allow to quickly find out where problems might be hiding. There is currently no support in distutils to run these tests. Could we make a similar decision on the name of the command (before actually adding support for it to distutils), so that package authors can start coding their own implementation now ?! -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From moshez@zadka.site.co.il Wed Mar 21 06:46:00 2001 From: moshez@zadka.site.co.il (Moshe Zadka) Date: Wed Mar 21 06:46:00 2001 Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism In-Reply-To: <3AB8843E.C32FEE74@lemburg.com> References: <3AB8843E.C32FEE74@lemburg.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> Message-ID: On Wed, 21 Mar 2001 11:36:46 +0100, "M.-A. Lemburg" wrote: > I'd say go with PGP -- it is far more available and known than > GPG As a data point, newer PGPs can read signatures made by GPG, and GPG can read any signature made by PGP. However, many people do not have PGP in their operating systems. There is the OpenPGP standard which both newer PGPs and GPG conform to --- while Sean seems to have a problem referring to standards instead of to implementations (<0.9 wink>), he should learn to cope with it. It is RFC 2440, and I suggest simply putting a refernce to the RFC in the PEP > Can't we just specify: use HTTP POST with multipart/form-data encoding > and then redirect to the RFC (can't remember the number) RFC 2388 +1 (Someone should really patch up pep2html.py to make RFC mentions hyperlinks) (The code can probably be stolen from pydoc.py) -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org From moshez@zadka.site.co.il Wed Mar 21 08:06:19 2001 From: moshez@zadka.site.co.il (Moshe Zadka) Date: Wed Mar 21 08:06:19 2001 Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism In-Reply-To: References: , <3AB8843E.C32FEE74@lemburg.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> Message-ID: On Wed, 21 Mar 2001 13:42:58 +0200, Moshe Zadka wrote: > (Someone should really patch up pep2html.py to make RFC mentions hyperlinks) Someone just did. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org From akuchlin@mems-exchange.org Wed Mar 21 12:32:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed Mar 21 12:32:01 2001 Subject: [Distutils] Tasks arising from IPC9 In-Reply-To: <3AB88E28.4D718C93@lemburg.com>; from mal@lemburg.com on Wed, Mar 21, 2001 at 12:19:04PM +0100 References: <3AB88E28.4D718C93@lemburg.com> Message-ID: <20010321123141.K15282@ute.cnri.reston.va.us> On Wed, Mar 21, 2001 at 12:19:04PM +0100, M.-A. Lemburg wrote: >Could we make a similar decision on the name of the command (before >actually adding support for it to distutils), so that package >authors can start coding their own implementation now ?! "test" seems the most obvious command name, so let's choose that. (Which reminds me... they don't seem to have added PyUnit to the core yet...) --amk From phrxy@csv.warwick.ac.uk Wed Mar 21 15:02:03 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Wed Mar 21 15:02:03 2001 Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism In-Reply-To: <3AB8843E.C32FEE74@lemburg.com> Message-ID: On Wed, 21 Mar 2001, M.-A. Lemburg wrote: > "Moore, Paul" wrote: [...] > > 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? > > I'd say go with PGP -- it is far more available and known than > GPG... after all the intent of a signature is for the people [...] As has been pointed out already, the idea was for signatures to be gpg *readable*. I think this includes all pgp signatures. There is an IDEA module if that's important for signatures (can't remember), and of course RSA, which is now free. John From akuchlin@mems-exchange.org Wed Mar 21 23:06:00 2001 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Wed Mar 21 23:06:00 2001 Subject: [Distutils] PEP 241 checked in, and 1.5.2 compatibility Message-ID: <200103220420.XAA03015@mira.erols.com> 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 From jafo@tummy.com Thu Mar 22 02:44:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Thu Mar 22 02:44:01 2001 Subject: [Distutils] Metadata fields In-Reply-To: ; from mwa@gate.net on Sat, Mar 17, 2001 at 07:48:21AM -0500 References: <20010317020705.E29139@tummy.com> Message-ID: <20010322004311.V1466@tummy.com> On Sat, Mar 17, 2001 at 07:48:21AM -0500, Mark W. Alexander wrote: >But that's not really the source. Since distutils handles >(in theory) all binary formats, the catalog should only have to >manage information about the "real" distutils source with >some kind of pointer to where particular binaries live. So, for a binary you would basicly just have a set of fields which indicated "binary of - built for in distribution format"? Sean -- The Roman Rule: The one who says it cannot be done should never interrupt the one who is doing it. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From thomas.heller@ion-tof.com Thu Mar 22 03:50:04 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 22 03:50:04 2001 Subject: [Distutils] Tasks arising from IPC9 References: <3AB88E28.4D718C93@lemburg.com> <20010321123141.K15282@ute.cnri.reston.va.us> Message-ID: <014701c0b2ac$ff1020e0$e000a8c0@thomasnotebook> > "test" seems the most obvious command name, so let's choose that. > > (Which reminds me... they don't seem to have added PyUnit to the core yet...) Now that PyUnit as added, we should start talking (or implementing) the 'test' command. Thomas From thomas.heller@ion-tof.com Thu Mar 22 10:27:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 22 10:27:01 2001 Subject: [Distutils] PEP 241 checked in, and 1.5.2 compatibility References: <200103220420.XAA03015@mira.erols.com> Message-ID: <04ca01c0b2e4$6618e8d0$e000a8c0@thomasnotebook> > 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 built distutils as well as py2exe (which also contains extension modules) itself using python 1.5.2. No problems at all. (Except the old problem that the resulting zip-file from 'sdist --formats=zip' is unusable because it contains filenames relative to the root directory) PKG-INFO: Author, Author-email are set to UNKNOWN, IMO they should not. Platform is set to UNKNOWN, is this correct? Thomas From akuchlin@mems-exchange.org Thu Mar 22 10:38:02 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Mar 22 10:38:02 2001 Subject: [Distutils] PEP 241 checked in, and 1.5.2 compatibility In-Reply-To: <04ca01c0b2e4$6618e8d0$e000a8c0@thomasnotebook>; from thomas.heller@ion-tof.com on Thu, Mar 22, 2001 at 04:25:59PM +0100 References: <200103220420.XAA03015@mira.erols.com> <04ca01c0b2e4$6618e8d0$e000a8c0@thomasnotebook> Message-ID: <20010322103701.C17254@ute.cnri.reston.va.us> On Thu, Mar 22, 2001 at 04:25:59PM +0100, Thomas Heller wrote: >No problems at all. (Except the old problem that the resulting zip-file from >'sdist --formats=zip' is unusable because it contains filenames relative to >the root directory) I'll look into it. I can't recall hearing about this bug before; is it in the SF bug tracker? >PKG-INFO: Author, Author-email are set to UNKNOWN, IMO they should not. Good point; I've changed it to use the get_contact_*() methods instead. > Platform is set to UNKNOWN, is this correct? Unless you've specified a platform, yes it is. I sent an e-mail to the SIG asking about this (should it be 'UNKNOWN' or just an empty string), and no one commented, so I assume it's OK. --amk From thomas.heller@ion-tof.com Thu Mar 22 10:48:23 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 22 10:48:23 2001 Subject: [Distutils] PEP 241 checked in, and 1.5.2 compatibility References: <200103220420.XAA03015@mira.erols.com> <04ca01c0b2e4$6618e8d0$e000a8c0@thomasnotebook> <20010322103701.C17254@ute.cnri.reston.va.us> Message-ID: <051701c0b2e7$75f872e0$e000a8c0@thomasnotebook> I wrote: > >[...] (Except the old problem that the resulting zip-file from > >'sdist --formats=zip' is unusable because it contains filenames relative to > >the root directory) > Sorry, it's not the sdist but the bdist command, which is probably not used very much since we have these nice ;-) rpm and wininst formats for binary distributions. > I'll look into it. I can't recall hearing about this bug before; is > it in the SF bug tracker? I don't think so. I argued about this issue with Greg a long time ago, maybe we misunderstood each other. IIRC, this may make sense on linux, but not on windows. Thomas From pete@visionart.com Thu Mar 22 12:55:13 2001 From: pete@visionart.com (Pete Shinners) Date: Thu Mar 22 12:55:13 2001 Subject: [Distutils] Peer Review Message-ID: <002e01c0b2f8$f95e3c30$f43f93cd@visionart.com> 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. From jafo@tummy.com Thu Mar 22 19:17:02 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Thu Mar 22 19:17:02 2001 Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism In-Reply-To: ; from moshez@zadka.site.co.il on Wed, Mar 21, 2001 at 01:42:58PM +0200 References: <3AB8843E.C32FEE74@lemburg.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> Message-ID: <20010322171344.Y1466@tummy.com> On Wed, Mar 21, 2001 at 01:42:58PM +0200, Moshe Zadka wrote: >newer PGPs and GPG conform to --- while Sean seems to have a problem >referring to standards instead of to implementations (<0.9 wink>), he I love the saying: "If you don't have time to do it right, when will you ever find time to do it over?" However, I'm guilty as charged. ;-) Sean -- Her eyes were like two brown circles with big black dots in the center. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From akuchlin@mems-exchange.org Fri Mar 23 13:00:00 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri Mar 23 13:00:00 2001 Subject: [Distutils] Peer Review In-Reply-To: <002e01c0b2f8$f95e3c30$f43f93cd@visionart.com>; from pete@visionart.com on Thu, Mar 22, 2001 at 09:53:16AM -0800 References: <002e01c0b2f8$f95e3c30$f43f93cd@visionart.com> Message-ID: <20010323125859.A14620@ute.cnri.reston.va.us> On Thu, Mar 22, 2001 at 09:53:16AM -0800, Pete Shinners wrote: >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. A quick look through setup.py, and everything looks reasonable. The setup.py/config.py combination is complex, but then pygame is fairly complex, having to adapt to the presence of various libraries. One oddity: #hmm, findbasepath is failing on irix, we'll avoid it for now def findbasepath(deps): "find a common prefix in all paths" allpaths = [] for d in deps: if d.found: allpaths.append(d.inc_dir) allpaths.append(d.lib_dir) basepath = os.path.commonprefix(allpaths) lastslash = basepath.rfind('/') if(lastslash < 3 or len(basepath) < 3): basepath = "" else: basepath = basepath[:lastslash] return basepath I don't see why this would fail on one particular platform; what's the failure? --amk From jafo@tummy.com Sat Mar 24 03:15:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 24 03:15:01 2001 Subject: [Distutils] Tasks arising from IPC9 In-Reply-To: <20010321123141.K15282@ute.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Wed, Mar 21, 2001 at 12:31:41PM -0500 References: <3AB88E28.4D718C93@lemburg.com> <20010321123141.K15282@ute.cnri.reston.va.us> Message-ID: <20010324011446.E4804@tummy.com> On Wed, Mar 21, 2001 at 12:31:41PM -0500, Andrew Kuchling wrote: >On Wed, Mar 21, 2001 at 12:19:04PM +0100, M.-A. Lemburg wrote: >>Could we make a similar decision on the name of the command (before >>actually adding support for it to distutils), so that package >>authors can start coding their own implementation now ?! > >"test" seems the most obvious command name, so let's choose that. >(Which reminds me... they don't seem to have added PyUnit to the core yet...) Along with the name, I think that it'll have to have a default stub which does an "exit(0)" (the default test succeeds) so that the lack of a test doesn't show up the same as a test failure. Sean -- "Having computers is a lot like having kids, except it's not as much of a problem if they die while you're away." -- Sean Reifschneider, 1997 Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sat Mar 24 03:21:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 24 03:21:01 2001 Subject: [Distutils] Final PEP 241 patch In-Reply-To: <200103210313.WAA01343@mira.erols.com>; from akuchlin@mems-exchange.org on Tue, Mar 20, 2001 at 10:13:27PM -0500 References: <200103210313.WAA01343@mira.erols.com> Message-ID: <20010324012014.F4804@tummy.com> On Tue, Mar 20, 2001 at 10:13:27PM -0500, A.M. Kuchling wrote: > * When the 'platforms' argument isn't specified, the option will be >set to ['UNKNOWN'], not an empty list. Is that OK? The keywords Yeah, I think that'll be fine. > * '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. Well, the question is: What is the intended use for this field? I don't really see much use for this in the catalog. I don't imagine we'll be sending e-mail to the author or maintainer. The only case I can imagine where it would be passable would be if we got a binary uploaded we could notify the author. That doesn't REALLY seem like a feature to me though. Sean -- A computer lets you make more mistakes faster than any invention in human history -- with the possible exceptions of handguns and tequila. -- Mitch Ratcliffe Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sat Mar 24 03:40:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 24 03:40:01 2001 Subject: [Distutils] PEP241 platforms In-Reply-To: <3AB7198B.9E75A686@gmx.de>; from R.Liebscher@gmx.de on Tue, Mar 20, 2001 at 09:49:15AM +0100 References: <3AB7198B.9E75A686@gmx.de> Message-ID: <20010324013925.J4804@tummy.com> On Tue, Mar 20, 2001 at 09:49:15AM +0100, Rene Liebscher wrote: >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? It's already in there. I'll get a new version of the PEP out this weekend, hopefully along with the code and patches required for this. Thanks, Sean -- But I woke up when somone slammed the door so hard I fell outta bed screaming "Mama's little baby loves shortnin' bread". -- Aerosmith Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sat Mar 24 03:51:03 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 24 03:51:03 2001 Subject: [Distutils] New draft of PEP, and list of licenses In-Reply-To: <20010317112909.B6504@ute.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Sat, Mar 17, 2001 at 11:29:09AM -0500 References: <20010317014652.B29139@tummy.com> <20010317112909.B6504@ute.cnri.reston.va.us> Message-ID: <20010324015045.L4804@tummy.com> On Sat, Mar 17, 2001 at 11:29:09AM -0500, Andrew Kuchling wrote: >We *really* need to resolve the platform issue; it's the last thing to >do before posting the PEP to python-dev/c.l.p.a and implementing it. In PEP243 I'm listing a bunch of platforms simply because if we don't list them they're undefined. I believe we need to have a wealth of them, and also need to include version numbers because of library issues for binary distributions. Is there any platform where it's not possible to get this information programmaticly? For example, on RedHat you can get it from /etc/redhat-release... I expect the list in PEP243 to be a living list, but I don't think we're going to get the platform issues resolved before 2.1. Once we have the things in place to get this to critical mass for source distributions, we'll be in a position to be collecting this information for binaries. I think we need some more experience to get this, much as is the situation for dependencies. Sean -- Men are from Mars. Women are from Venus. Computers are from hell. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sat Mar 24 04:14:06 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 24 04:14:06 2001 Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism In-Reply-To: <3AB8843E.C32FEE74@lemburg.com>; from mal@lemburg.com on Wed, Mar 21, 2001 at 11:36:46AM +0100 References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> Message-ID: <20010324021321.O4804@tummy.com> On Wed, Mar 21, 2001 at 11:36:46AM +0100, M.-A. Lemburg wrote: >...at least for Windows this is mandatory. You get nasty error >messages otherwise. It's gonna be required on most platforms for at least some of the distributions. >I'd say go with PGP -- it is far more available and known than >GPG... after all the intent of a signature is for the people >who download the code to check it and if they don't know what >GPG is, then it is of no practical use for them (hard to tell, >if it's of practical use for them at all ;-). I'm thinking of specifying OpenPGP as the standard and leave the implementation outta it. >Can't we just specify: use HTTP POST with multipart/form-data encoding >and then redirect to the RFC (can't remember the number) or Netscape >description of the form upload proposal ?! RFC 2388 is what I'll change it to. >You may want to take a look at platform.py available from my >Python Pages for ways to "define" a platform information string. Most excellent. I don't think we want it to include kernel information though... Sean -- Got Source? Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From moshez@zadka.site.co.il Sat Mar 24 04:48:05 2001 From: moshez@zadka.site.co.il (Moshe Zadka) Date: Sat Mar 24 04:48:05 2001 Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism In-Reply-To: <20010324021321.O4804@tummy.com> References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> Message-ID: On Sat, 24 Mar 2001 02:13:21 -0700, Sean Reifschneider wrote: > Most excellent. I don't think we want it to include kernel information > though... I'm not sure if you can get away from it completely. Three words for you: Large file support -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org From jafo@tummy.com Sat Mar 24 05:44:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 24 05:44:01 2001 Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism In-Reply-To: ; from moshez@zadka.site.co.il on Sat, Mar 24, 2001 at 11:45:37AM +0200 References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <20010324021321.O4804@tummy.com> Message-ID: <20010324034212.I1466@tummy.com> On Sat, Mar 24, 2001 at 11:45:37AM +0200, Moshe Zadka wrote: >I'm not sure if you can get away from it completely. >Three words for you: Large file support Yeah, but knowing if you're running 2.2.18 doesn't tell you the information you want to know -- do I have the LFS patch in my kernel. You make my head hurt. ;-) Sean -- "Bill and Ted on cryptography: If you are really us... What number are we thinking of?" -- Sean Reifschneider, 1998 Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From martin@loewis.home.cs.tu-berlin.de Sat Mar 24 08:21:01 2001 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat Mar 24 08:21:01 2001 Subject: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism In-Reply-To: (message from Moshe Zadka on Sat, 24 Mar 2001 11:45:37 +0200) References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> Message-ID: <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de> > > Most excellent. I don't think we want it to include kernel information > > though... > > I'm not sure if you can get away from it completely. > > Three words for you: > Large file support Maybe I'm missing something, but ... I don't think the packaging system should deal with "minor" details of the operating system. Instead, the package should, at run-time, determine whether the feature is present or not. Otherwise, we end up with packages that require, say, /proc support (*), and fail to install if /proc was not mounted, or is missing from the kernel configuration. IMO, the right behaviour in this case is to produce an exception at run-time (whether from a deliberate test, or by just using the missing feature). Regards, Martin (*) Or the Fiber API, for you Windows users :-) From mal@lemburg.com Sat Mar 24 08:40:03 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat Mar 24 08:40:03 2001 Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <20010324021321.O4804@tummy.com> <20010324034212.I1466@tummy.com> Message-ID: <3ABCA371.A8F73C4F@lemburg.com> Sean Reifschneider wrote: > > On Sat, Mar 24, 2001 at 11:45:37AM +0200, Moshe Zadka wrote: > >I'm not sure if you can get away from it completely. > >Three words for you: Large file support > > Yeah, but knowing if you're running 2.2.18 doesn't tell you the information > you want to know -- do I have the LFS patch in my kernel. > > You make my head hurt. ;-) With the pointer to platform.py I just wanted to let you know that there is a Python module for these sort of things out there which can handle many different platform issues. Whether you use the different features or not is really totally up to you... BTW, I think that information such as the libc version are more important than, say, the patch level of the OS. Again, these issues are OS-specific (e.g. on Windows the C RTL version isn't all that important since MS tries hard to maintain backward compatibility). -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From jafo@tummy.com Sat Mar 24 15:03:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 24 15:03:01 2001 Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism In-Reply-To: <3ABCA371.A8F73C4F@lemburg.com>; from mal@lemburg.com on Sat, Mar 24, 2001 at 02:38:57PM +0100 References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <20010324021321.O4804@tummy.com> <20010324034212.I1466@tummy.com> <3ABCA371.A8F73C4F@lemburg.com> Message-ID: <20010324130214.J1466@tummy.com> On Sat, Mar 24, 2001 at 02:38:57PM +0100, M.-A. Lemburg wrote: >With the pointer to platform.py I just wanted to let you know >that there is a Python module for these sort of things out there It doesn't detect LFS though, does it? I don't see that it does... It's definitely useful though. >BTW, I think that information such as the libc version are more >important than, say, the patch level of the OS. Again, these OS patch level tends to indicate the set of libraries you have. Much easier than having to list *ALL* the libraries on your system which might impact a binary module. RPM actually looks at the files to see what they're linked against, which would be the ultimate... Sean -- Language is the most important .. uh.. I think you know what I'm trying to say. -- Steve Martin Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sat Mar 24 18:18:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sat Mar 24 18:18:01 2001 Subject: [Distutils] RFC: PEP243: Module Repository Upload Mechanism Message-ID: <20010324161735.A19818@tummy.com> Included below is the version of PEP243 after it's initial round of review. I welcome any feedback. Thanks, Sean ============================================================================ PEP: 243 Title: Module Repository Upload Mechanism Version: $Revision$ Author: jafo-pep@tummy.com (Sean Reifschneider) Status: Draft Type: Standards Track Created: 18-Mar-2001 Python-Version: 2.1 Post-History: Discussions-To: distutils-sig@python.org Abstract For a module repository system (such as Perl's CPAN) to be successful, it must be as easy as possible for module authors to submit their work. An obvious place for this submit to happen is in the Distutils tools after the distribution archive has been successfully created. For example, after a module author has tested their software (verifying the results of "setup.py sdist"), they might type "setup.py sdist --submit". This would flag Distutils to submit the source distribution to the archive server for inclusion and distribution to the mirrors. This PEP only deals with the mechanism for submitting the software distributions to the archive, and does not deal with the actual archive/catalog server. Upload Process The upload will include the Distutils "PKG-INFO" meta-data information (as specified in PEP-241 [1]), the actual software distribution, and other optional information. This information will be uploaded as a multi-part form encoded the same as a regular HTML file upload request. This form is posted using ENCTYPE="multipart/form-data" encoding [RFC1867]. The upload will be made to the host "modules.python.org" on port 80/tcp (POST http://modules.python.org:80/swalowpost.cgi). The form will consist of the following fields: distribution -- The file containing the module software (for example, a .tar.gz or .zip file). distmd5sum -- The MD5 hash of the uploaded distribution, encoded in ASCII representing the hexadecimal representation of the digest ("for byte in digest: s = s + ('%02x' % ord(byte))"). pkginfo (optional) -- The file containing the distribution meta-data (as specified in PEP-241 [1]). Note that if this is not included, the distribution file is expected to be in .tar format (gzipped and bzipped compreesed are allowed) or .zip format, with a "PKG-INFO" file in the top-level directory it extracts ("package-1.00/PKG-INFO"). infomd5sum (required if pkginfo field is present) -- The MD5 hash of the uploaded meta-data, encoded in ASCII representing the hexadecimal representation of the digest ("for byte in digest: s = s + ('%02x' % ord(byte))"). platform (optional) -- A string representing the target platform for this distribution. This is only for binary distributions. It is encoded as "---". signature (optional) -- A OpenPGP-compatible signature [RFC2440] of the uploaded distribution as signed by the author. This may be used by the cataloging system to automate acceptance of uploads. protocol_version -- A string indicating the protocol version that the client supports. This document describes protocol version "1". Return Data The status of the upload will be reported using HTTP non-standard ("X-*)" headers. The "X-Swalow-Status" header may have the following values: SUCCESS -- Indicates that the upload has succeeded. FAILURE -- The upload is, for some reason, unable to be processed. TRYAGAIN -- The server is unable to accept the upload at this time, but the client should try again at a later time. Potential causes of this are resource shortages on the server, administrative down-time, etc... Optionally, there may be a "X-Swalow-Reason" header which includes a human-readable string which provides more detailed information about the "X-Swalow-Status". If there is no "X-Swalow-Status" header, or it does not contain one of the three strings above, it should be treated as a temporary failure. Example: >>> f = urllib.urlopen('http://modules.python.org:80/swalowpost.cgi') >>> s = f.headers['x-swalow-status'] >>> s = s + ': ' + f.headers.get('x-swalow-reason', '') >>> print s FAILURE: Required field "distribution" missing. Sample Form 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:

Upload file








Platforms The following are valid os names: aix beos debian dos freebsd hpux mac macos mandrake netbsd openbsd qnx redhat solaris suse windows yellowdog The above include a number of different types of distributions of Linux. Because of versioning issues these must be split out, and it is expected that when it makes sense for one system to use distributions made on other similar systems, the download client will make the distinction. Version is the official version string specified by the vendor for the particular release. For example, "2000" and "nt" (Windows), "9.04" (HP-UX), "7.0" (RedHat, Mandrake). The following are valid architectures: alpha hppa ix86 powerpc sparc ultrasparc Status I currently have a proof-of-concept client and server implemented. I plan to have the Distutils patches ready for the 2.1 release. Combined with Andrew's PEP-241 [1] for specifying distribution meta-data, I hope to have a platform which will allow us to gather real-world data for finalizing the catalog system for the 2.2 release. References [1] Metadata for Python Software Package, Kuchling, http://python.sourceforge.net/peps/pep-0241.html [RFC1867] Form-based File Upload in HTML http://www.faqs.org/rfcs/rfc1867.html [RFC2440] OpenPGP Message Format http://www.faqs.org/rfcs/rfc2440.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: -- A smart terminal is not a smart*ass* terminal, but rather a terminal you can educate. -- Rob Pike Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From careye@spamcop.net Sat Mar 24 20:53:01 2001 From: careye@spamcop.net (Carey Evans) Date: Sat Mar 24 20:53:01 2001 Subject: [Distutils] Re: RFC: PEP243: Module Repository Upload Mechanism In-Reply-To: <20010324161735.A19818@tummy.com> References: <20010324161735.A19818@tummy.com> Message-ID: <8766gy7gyk.fsf@psyche.dnsalias.org> Sean Reifschneider writes: [...] > Platforms > > The following are valid os names: > > aix beos debian dos freebsd hpux mac macos mandrake netbsd > openbsd qnx redhat solaris suse windows yellowdog Shouldn't there be separate values for packages for Debian GNU/Linux and Debian GNU/Hurd? What's the difference between "mac" and "macos"? Other operating systems referred to in the README with Python 2.1b2 are: BSDI, DEC Unix, DEC Ultrix, Minix, SCO, SunOS 4, NeXTSTEP, Irix, OS/2, Monterey, Reliant UNIX, Mac OS X. Other OS's for which Python is available, that I know of, are Palm, WinCE and OS/400. [...] > The following are valid architectures: > > alpha hppa ix86 powerpc sparc ultrasparc Other common architectures are arm, ia64, m68k, mips, mipsel, s390 (or whatever IBM are calling it now) and as400 (or whatever IBM are calling _it_ now), although the AS/400 is arguably using the PowerPC architecture. Python should be available for all of these. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Quiet, you'll miss the humorous conclusion." From amos@digicool.com Sat Mar 24 21:37:01 2001 From: amos@digicool.com (Amos Latteier) Date: Sat Mar 24 21:37:01 2001 Subject: [Distutils] RFC: PEP243: Module Repository Upload Mechanism References: <20010324161735.A19818@tummy.com> Message-ID: <3ABD592C.B690A082@digicool.com> Sean Reifschneider wrote: > > Included below is the version of PEP243 after it's initial round of review. > I welcome any feedback. Looks good! I have a just few more comments. > The upload will be made to the host "modules.python.org" on port > 80/tcp (POST http://modules.python.org:80/swalowpost.cgi). The form > will consist of the following fields: > > distmd5sum -- The MD5 hash of the uploaded distribution, > encoded in ASCII representing the hexadecimal representation > of the digest ("for byte in digest: s = s + ('%02x' % > ord(byte))"). How necessary is this? How likely is file corruption over HTTP? > protocol_version -- A string indicating the protocol version that > the client supports. This document describes protocol version "1". Couldn't this be handled by defining new endpoints for new protocols. When we rev this protocol just change the upload URL. > Return Data > > The status of the upload will be reported using HTTP non-standard > ("X-*)" headers. The "X-Swalow-Status" header may have the following > values: > TRYAGAIN -- The server is unable to accept the upload at this > time, but the client should try again at a later time. > Potential causes of this are resource shortages on the server, > administrative down-time, etc... How should the distutils handle this response? My guess is that it would be impractical for the distutils to automatically wait a while and retry. Probably it's better to not try and automate this. Let's keep things simple to start with. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From jafo@tummy.com Sun Mar 25 04:23:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sun Mar 25 04:23:01 2001 Subject: [Distutils] RFC: PEP243: Module Repository Upload Mechanism In-Reply-To: <3ABD592C.B690A082@digicool.com>; from amos@digicool.com on Sat, Mar 24, 2001 at 06:34:20PM -0800 References: <20010324161735.A19818@tummy.com> <3ABD592C.B690A082@digicool.com> Message-ID: <20010325022237.R1466@tummy.com> On Sat, Mar 24, 2001 at 06:34:20PM -0800, Amos Latteier wrote: >How necessary is this? How likely is file corruption over HTTP? It's not that necessary, but it's easy enough to implement, so why not? It can detect corruption and incomplete uploads, the latter being my bigger concern. >Couldn't this be handled by defining new endpoints for new protocols. >When we rev this protocol just change the upload URL. Yeah, but do we want to *HAVE* to change the endpoint? Mostly I'm thinking more of small changes as opposed to a complete re-writing. Sure, some of this may be able to be auto-detected (is the new field there?), but in general I think it's a good thing for the server and client to be sure they're talking the same language. >How should the distutils handle this response? My guess is that it would >be impractical for the distutils to automatically wait a while and The idea is to differentiate between temporary failures (disc space not available, server shut down for maintenance) versus something that will *NEVER* work (say, because of a client code bug). I don't expect that distutils will auto-retry it, because those sorts of failures are likely to require hours to work out. As a user it would be nice to know that no matter how many times I retry this over the next several days, that it will never work... Sean -- Linux: When you need to run like a greased weasel. -- Sean Reifschneider, 1998 Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sun Mar 25 05:42:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sun Mar 25 05:42:01 2001 Subject: [Distutils] Re: RFC: PEP243: Module Repository Upload Mechanism In-Reply-To: <8766gy7gyk.fsf@psyche.dnsalias.org>; from careye@spamcop.net on Sun, Mar 25, 2001 at 01:52:35PM +1200 References: <20010324161735.A19818@tummy.com> <8766gy7gyk.fsf@psyche.dnsalias.org> Message-ID: <20010325034103.A24546@tummy.com> On Sun, Mar 25, 2001 at 01:52:35PM +1200, Carey Evans wrote: >Shouldn't there be separate values for packages for Debian GNU/Linux >and Debian GNU/Hurd? I've added debian_hurd >What's the difference between "mac" and "macos"? Removed "mac". > BSDI, DEC Unix, DEC Ultrix, Minix, SCO, SunOS 4, NeXTSTEP, Irix, > OS/2, Monterey, Reliant UNIX, Mac OS X. Added all these. >Other OS's for which Python is available, that I know of, are Palm, >WinCE and OS/400. Added os400 and palm, wince is OS "Windows" version "CE", isn't it? >Other common architectures are arm, ia64, m68k, mips, mipsel, s390 (or >whatever IBM are calling it now) and as400 (or whatever IBM are >calling _it_ now), although the AS/400 is arguably using the PowerPC >architecture. Python should be available for all of these. Added all these. Thanks, Sean -- Think. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sun Mar 25 05:46:02 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sun Mar 25 05:46:02 2001 Subject: [Distutils] Re: [Catalog-sig] RFC: PEP 243: Module Repository Upload Mechanism In-Reply-To: <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Sat, Mar 24, 2001 at 01:54:04PM +0100 References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <200103241254.f2OCs4400787@mira.informatik.hu-berlin.de> Message-ID: <20010325034536.B24546@tummy.com> On Sat, Mar 24, 2001 at 01:54:04PM +0100, Martin v. Loewis wrote: >mounted, or is missing from the kernel configuration. IMO, the right >behaviour in this case is to produce an exception at run-time (whether Sure, but how do you do that for C extension modules which use OS features you don't have (like LFS)? Sean -- Her eyes were like two brown circles with big black dots in the center. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From careye@spamcop.net Sun Mar 25 06:10:00 2001 From: careye@spamcop.net (Carey Evans) Date: Sun Mar 25 06:10:00 2001 Subject: [Distutils] Re: RFC: PEP243: Module Repository Upload Mechanism In-Reply-To: <20010325034103.A24546@tummy.com> References: <20010324161735.A19818@tummy.com> <8766gy7gyk.fsf@psyche.dnsalias.org> <20010325034103.A24546@tummy.com> Message-ID: <87puf66r5u.fsf@psyche.dnsalias.org> Sean Reifschneider writes: [...] > >Other OS's for which Python is available, that I know of, are Palm, > >WinCE and OS/400. > > Added os400 and palm, wince is OS "Windows" version "CE", isn't it? (BTW, thanks for all the hard work on this.) Yes, I guess WinCE could be considered a version of windows, though it's had it's own versions, too. In that case, wouldn't Debian GNU/Hurd 2.2 be OS "debian", version "hurd_2.2"? In fact, all the different Linux distributions are less different than Windows 98, Windows 2000 and WinCE, so couldn't they all be different versions of OS "linux"? It seems unfair to lump three different Windows code bases together, but give a particular selection of Linux distributions OS status. I'm not saying it should necessarily be different or not, just interested in arguments for and against. > >Other common architectures are arm, ia64, m68k, mips, mipsel, s390 (or > >whatever IBM are calling it now) and as400 (or whatever IBM are > >calling _it_ now), although the AS/400 is arguably using the PowerPC > >architecture. Python should be available for all of these. > > Added all these. Can I be a nuisance and say that after arguing with myself a bit today, I've decided that AS/400 doesn't deserve its own architecture value? Linux running in a logical partition, and AIX binaries running in PASE will both be "powerpc", so it should just use that. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Quiet, you'll miss the humorous conclusion." From mal@lemburg.com Sun Mar 25 09:17:03 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun Mar 25 09:17:03 2001 Subject: [Catalog-sig] Re: [Distutils] RFC: PEP 243: Module Repository Upload Mechanism References: <20010324021321.O4804@tummy.com>, <714DFA46B9BBD0119CD000805FC1F53B01B5AD9D@UKRUX002.rundc.uk.origin-it.com> <3AB8843E.C32FEE74@lemburg.com> <20010324021321.O4804@tummy.com> <20010324034212.I1466@tummy.com> <3ABCA371.A8F73C4F@lemburg.com> <20010324130214.J1466@tummy.com> Message-ID: <3ABDFD9E.B7B2E68B@lemburg.com> Sean Reifschneider wrote: > > On Sat, Mar 24, 2001 at 02:38:57PM +0100, M.-A. Lemburg wrote: > >With the pointer to platform.py I just wanted to let you know > >that there is a Python module for these sort of things out there > > It doesn't detect LFS though, does it? I don't see that it does... > It's definitely useful though. The module is intended to include checks like these if they are important for applications, so if you can provide an API which checks for LFS, then I'd be happy to include it in platform.py. > >BTW, I think that information such as the libc version are more > >important than, say, the patch level of the OS. Again, these > > OS patch level tends to indicate the set of libraries you have. Much > easier than having to list *ALL* the libraries on your system which might > impact a binary module. RPM actually looks at the files to see what > they're linked against, which would be the ultimate... distutils has all the technology to check for these. I'd suggest to have the package download tools use these to verify their existance. Of course, this can only be done *after* downloading the package, but hey, can't have everything ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From amos@digicool.com Sun Mar 25 14:42:01 2001 From: amos@digicool.com (Amos Latteier) Date: Sun Mar 25 14:42:01 2001 Subject: [Distutils] RFC: PEP243: Module Repository Upload Mechanism In-Reply-To: <20010324161735.A19818@tummy.com> Message-ID: On Sat, 24 Mar 2001 16:17:35 -0700 Sean Reifschneider wrote: > Included below is the version of PEP243 after it's > initial round of review. > I welcome any feedback. I've been looking at this PEP more closely, now that I'm thinking about actually implementing it with my prototype catalog server. One question I have is how does the catalog verify who is uploading the package. It seems that the only facility is via a pgp signature. However, this signature seems to verify the author, not the uploaded. Plus it's optional. > signature (optional) -- A OpenPGP-compatible signature [RFC2440] > of the uploaded distribution as signed by the author. This may be > used by the cataloging system to automate acceptance of uploads. This means that the author must have some flavor of pgp and must have signed the package before you upload it. Otherwise the catalog has no way to associate a package with an individual expect the author in the PGK-INFO file. This is problematic from a security point of view. For example, I can put Guido down as the author of my malicious package. In my protype server folks who upload packages are verified by email address. (Actually this is not implemented yet, but will be soon. To get privledges to upload you will have to provide an email address, and a password will be sent to it.) So this way you can know the email address of the person who uploaded the package. Of course, you can also use pgp signatures to verify the author of the package, if there is a signature available. I like this system because it is light weight, and doesn't require much overhead for the author or uploader. It provides the downloader with some measure of information about what they're downloading. And it allows you to provide additional security information (pgp signatures) if you wish. If folks have other ideas about how to handle security I'd love to hear about them. I'm no security expert. In sum, I'd like to see the PEP address the issue of identifying the uploader (who may or may not be the author) of the package. -Amos From jafo@tummy.com Sun Mar 25 18:44:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sun Mar 25 18:44:01 2001 Subject: [Distutils] RFC: PEP243: Module Repository Upload Mechanism In-Reply-To: ; from amos@digicool.com on Sun, Mar 25, 2001 at 02:45:02PM -0500 References: <20010324161735.A19818@tummy.com> Message-ID: <20010325153108.W1466@tummy.com> On Sun, Mar 25, 2001 at 02:45:02PM -0500, Amos Latteier wrote: >One question I have is how does the catalog verify who is >uploading the package. It seems that the only facility is >via a pgp signature. However, this signature seems to verify >the author, not the uploaded. Plus it's optional. Well, the authorization is more of a policy decision, IMHO... For example, one could send e-mail to the maintainer listed in the meta-information requesting that they approve the upload. Or, one could require manual verification if the signature doesn't match an "approved" signer for automatic processing... If you believe that having an e-mail address is enough to discourage tampering and allow automatic posting of the uploaded binaries to the repository, I think you're due for a big suprise... ;-/ >I like this system because it is light weight, and doesn't >require much overhead for the author or uploader. It >provides the downloader with some measure of information Interesting... I dislike it because it provides the downloader with a false sense of security... Just because you have a hotmail account that somone has once logged in to, I don't think that's enough that somone should believe it's not malicious code... Currently, I'm planning on using a manual process for verification, to figure out what really works. It constantly suprises me that people will use packages uploaded to the redhat contrib site (for example), but they do and there are suprisingly few problems with it. Maybe I'll have the uploaded packages come in as "unverified" and once there's been some sort of verification that the author or maintainer knows of it, or something along those lines, it will moved to "verified"? I agree that some sort of verification would be nice. I'm open to suggestions though. Sean -- Having been an entrprenuer, I value being a wage-slave in new ways. I also more fully understand why I hate it. -- Evelyn Mitchell, 1999 Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Sun Mar 25 21:27:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Sun Mar 25 21:27:01 2001 Subject: [Distutils] Re: RFC: PEP243: Module Repository Upload Mechanism In-Reply-To: <87puf66r5u.fsf@psyche.dnsalias.org>; from careye@spamcop.net on Sun, Mar 25, 2001 at 11:09:49PM +1200 References: <20010324161735.A19818@tummy.com> <8766gy7gyk.fsf@psyche.dnsalias.org> <20010325034103.A24546@tummy.com> <87puf66r5u.fsf@psyche.dnsalias.org> Message-ID: <20010325192644.B5240@tummy.com> On Sun, Mar 25, 2001 at 11:09:49PM +1200, Carey Evans wrote: >Yes, I guess WinCE could be considered a version of windows, though >it's had it's own versions, too. Yeah, I was thinking the version would be something like "CE_1.00" or something (I know not the versions of CE, but remember "NT4" and the like). >all be different versions of OS "linux"? It seems unfair to lump >three different Windows code bases together, but give a particular >selection of Linux distributions OS status. Well, the reason I did it that way was because RedHat 7.0 is quite a bit different than, say Mandrake 7.0. So you think OS of "Linux" and the version would be "redhat_7.0"? I could dig that. Good idea. I wasn't really happy with having a butt-load of Linux names as the OS names... >Can I be a nuisance and say that after arguing with myself a bit >today, I've decided that AS/400 doesn't deserve its own architecture >value? Linux running in a logical partition, and AIX binaries running >in PASE will both be "powerpc", so it should just use that. Hmm. Ok. ;-) Sean -- Put out fires during the daytime. Do your real work at night. Sleep is just an addiction. -- Dieter Muller Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Mon Mar 26 03:37:03 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Mon Mar 26 03:37:03 2001 Subject: [Distutils] ANNOUNCE: Distutils upload patch (PEP243) Message-ID: <20010326013558.A9281@tummy.com> 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 ========================================== 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 tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From akuchlin@mems-exchange.org Mon Mar 26 16:37:02 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon Mar 26 16:37:02 2001 Subject: [Distutils] The 'test' command In-Reply-To: <20010324011446.E4804@tummy.com>; from jafo@tummy.com on Sat, Mar 24, 2001 at 01:14:46AM -0700 References: <3AB88E28.4D718C93@lemburg.com> <20010321123141.K15282@ute.cnri.reston.va.us> <20010324011446.E4804@tummy.com> Message-ID: <20010326163649.C21520@ute.cnri.reston.va.us> On Sat, Mar 24, 2001 at 01:14:46AM -0700, Sean Reifschneider wrote: >Along with the name, I think that it'll have to have a default stub which >does an "exit(0)" (the default test succeeds) so that the lack of a test >doesn't show up the same as a test failure. 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. 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). --amk From gstein@lyra.org Mon Mar 26 17:59:01 2001 From: gstein@lyra.org (Greg Stein) Date: Mon Mar 26 17:59:01 2001 Subject: [Distutils] [PEP 243] upload status is bogus Message-ID: <20010326145914.A27539@lyra.org> I just read thru PEP 243 and got to the section "Return Data". That information is bogus. HTTP already provides the upload client with various status codes. Specifically, let's look at the list in the PEP: PEP value HTTP Status SUCCESS 200 (Ok) FAILURE 4xx or 5xx TRYAGAIN 4xx or 5xx The PEP lists "resource shortage" as a possible TRYAGAIN error. That would map to 507 (Insufficent Storage). I'm sure there are other values that would make sense within this area. The PEP goes on to say that a human-readable string should provide further information. That is exactly what the body of the HTTP response is for. So... the answer here is to use the HTTP status codes like they're intended, and to use the HTTP response body as they're intended. This beats added another protocol layer on top of the response. Cheers, -g p.s. I'm not on the Distutils-SIG; I'd appreciate a CC for replies. -- Greg Stein, http://www.lyra.org/ From jamest@math.ksu.edu Mon Mar 26 20:01:01 2001 From: jamest@math.ksu.edu (James Thompson) Date: Mon Mar 26 20:01:01 2001 Subject: [Distutils] Install questions Message-ID: 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.14&content-type=text/x-cvsweb-markup and http://subversions.gnu.org/cgi-bin/cvsweb3/gnue/gnue/python-gnue-base/setup.py?rev=1.3&content-type=text/x-cvsweb-markup 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 ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-< From Paul.Moore@uk.origin-it.com Tue Mar 27 03:37:02 2001 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Tue Mar 27 03:37:02 2001 Subject: [Distutils] The 'test' command Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADB5@ukrux002.rundc.uk.origin-it.com> 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. From jafo@tummy.com Tue Mar 27 06:51:01 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Tue Mar 27 06:51:01 2001 Subject: [Distutils] [PEP 243] upload status is bogus In-Reply-To: <20010326145914.A27539@lyra.org>; from gstein@lyra.org on Mon, Mar 26, 2001 at 02:59:14PM -0800 References: <20010326145914.A27539@lyra.org> Message-ID: <20010327045043.B22549@tummy.com> On Mon, Mar 26, 2001 at 02:59:14PM -0800, Greg Stein wrote: >information is bogus. HTTP already provides the upload client with various >status codes. Specifically, let's look at the list in the PEP: It's bogus to use the transport status to signal an application return status. Any non-200 transport status should (and is, according to my PEP) interpreted as a temporary failure. How would you differentiate between a "400" (bad request) which is the application signaling that the request was invalid and the web server reporting it because of a configuration error or the like? The former being a permanent application failure, and the latter being temporary? As soon as you get the search.python.org web page to return "404" (not found) when it doesn't locate any matches, I'll look at changing it. Sean -- "Self-taught just means that you don't have to get rid of other people's prejudices as well as your own." -- Sean Reifschneider, 1997 Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From gstein@lyra.org Tue Mar 27 07:21:02 2001 From: gstein@lyra.org (Greg Stein) Date: Tue Mar 27 07:21:02 2001 Subject: [Distutils] [PEP 243] upload status is bogus In-Reply-To: <20010327045043.B22549@tummy.com>; from jafo@tummy.com on Tue, Mar 27, 2001 at 04:50:43AM -0700 References: <20010326145914.A27539@lyra.org> <20010327045043.B22549@tummy.com> Message-ID: <20010327042055.A27539@lyra.org> On Tue, Mar 27, 2001 at 04:50:43AM -0700, Sean Reifschneider wrote: > On Mon, Mar 26, 2001 at 02:59:14PM -0800, Greg Stein wrote: > >information is bogus. HTTP already provides the upload client with various > >status codes. Specifically, let's look at the list in the PEP: > > It's bogus to use the transport status to signal an application return > status. Any non-200 transport status should (and is, according to my > PEP) interpreted as a temporary failure. How would you differentiate > between a "400" (bad request) which is the application signaling that the > request was invalid and the web server reporting it because of a > configuration error or the like? The former being a permanent application > failure, and the latter being temporary? 4xx failures mean "you can probably fix it and resubmit." 5xx failures are "just give up, buddy." If a web server reports 4xx because of a config error, then the web server is busted. [ and yes, I'm sure you can find a situation where the config is "fine" and a 4xx is reported, yet the client can do nothing; that is beside the point I'm making here. ] The application in question is shoving data at an HTTP server. The HTTP status code is the appropriate way to report status in this situation. You don't have an "application (-level) return status". The server accepts it, it doesn't, or it suggests that you try again. That maps directly to the HTTP status codes. HTTP is for moving content about. Those status codes are how the web server reports what is done with the content, and what the client can/should do about it. The current description in the PEP is effectively defining another layer of protocol on top of HTTP, when HTTP already incorporates everything needed. We don't need Yet Another Protocol. [ and don't even get me started on how the package is uploaded; I'm playing soft here; those MD5 checksums and the multipart stuff have alternatives that are more in line with HTTP (see the Content-MD5 header); heck, the PUT method may be more appropriate; I'm just not touching those issues because they are small potatoes relative to introducing new error reporting systems. ] At a minimum, the PEP should incorporate this alternate suggestion for reporting status. Cheers, -g -- Greg Stein, http://www.lyra.org/ From careye@spamcop.net Tue Mar 27 07:37:02 2001 From: careye@spamcop.net (Carey Evans) Date: Tue Mar 27 07:37:02 2001 Subject: [Distutils] Re: [PEP 243] upload status is bogus In-Reply-To: <20010326145914.A27539@lyra.org> References: <20010326145914.A27539@lyra.org> Message-ID: <87ae67l76j.fsf@psyche.dnsalias.org> Greg Stein writes: [...] > So... the answer here is to use the HTTP status codes like they're intended, > and to use the HTTP response body as they're intended. This beats added > another protocol layer on top of the response. I'm not sure if I really agree with this. It looks like other protocols on top of HTTP, such as xmlrpc, always return an HTTP status of 200 whatever he result. Relying on a mapping between HTTP statuses and swalow return values seems a bit fragile to me. I would actually prefer the response to be completely in the HTTP body, probably as another set of RFC 822 headers. This properly separates the transport from the swalow protocol. This would make the complete response from the server something like: """\ HTTP/1.0 200 OK Date: Tue, 27 Mar 2001 12:27:10 GMT Server: SomeWebServer Connection: close Content-Length: 84 Content-Type: application/x-swalow-response Swalow-Status: TRYAGAIN This body text is what was described for X-Swalow-Reason. """ Of course, it *is* late at night and I may not know what I'm talking about... -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Quiet, you'll miss the humorous conclusion." From careye@spamcop.net Tue Mar 27 07:43:02 2001 From: careye@spamcop.net (Carey Evans) Date: Tue Mar 27 07:43:02 2001 Subject: [Distutils] Re: RFC: PEP243: Module Repository Upload Mechanism In-Reply-To: <20010325192644.B5240@tummy.com> References: <20010324161735.A19818@tummy.com> <8766gy7gyk.fsf@psyche.dnsalias.org> <20010325034103.A24546@tummy.com> <87puf66r5u.fsf@psyche.dnsalias.org> <20010325192644.B5240@tummy.com> Message-ID: <8766gvl6x5.fsf@psyche.dnsalias.org> Sean Reifschneider writes: [...] > Well, the reason I did it that way was because RedHat 7.0 is quite a bit > different than, say Mandrake 7.0. So you think OS of "Linux" and the > version would be "redhat_7.0"? I could dig that. Good idea. I wasn't > really happy with having a butt-load of Linux names as the OS names... This looks good. New operating systems probably happen a little less often than new Linux distributions... This would also give Hurd a proper place in the operating system field, which should keep the GNU fanatics happy. The only thing I still wonder about, given that, is whether the *BSD operating systems are different enough to get separate entries. I don't even know enough about BSD to offer an _uninformed_ opinion on that. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Quiet, you'll miss the humorous conclusion." From jafo@tummy.com Tue Mar 27 08:14:00 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Tue Mar 27 08:14:00 2001 Subject: [Distutils] [PEP 243] upload status is bogus In-Reply-To: <20010327042055.A27539@lyra.org>; from gstein@lyra.org on Tue, Mar 27, 2001 at 04:20:55AM -0800 References: <20010326145914.A27539@lyra.org> <20010327045043.B22549@tummy.com> <20010327042055.A27539@lyra.org> Message-ID: <20010327061258.J1466@tummy.com> On Tue, Mar 27, 2001 at 04:20:55AM -0800, Greg Stein wrote: >4xx failures mean "you can probably fix it and resubmit." 5xx failures are >"just give up, buddy." If a web server reports 4xx because of a config For this application, a 500 error should be considered a temporary failure. I believe that HTTP should report 200 if it successfully ran the CGI, anything else if it did not. I would hardly call making use of the X- headers "Yet Another Protocol". >[ and don't even get me started on how the package is uploaded; I'm playing > soft here; those MD5 checksums and the multipart stuff have alternatives "playing soft here"? Geeze, this isn't some competition... This whole section in the brackets makes it sound like you were just holding those comments back so you could make me look like an idiot if I didn't respond favorably to your initial message proclaiming my work "bogus". The repository system has repeatedly suffered because of trying to make it perfect. I'm not going to commit the HTTP RFCs to memory just to track down some vague mentions you make about my not conforming to spec. As far as I know, I'm following the standards. The "multipart stuff" is RFC1867, and I'd submit that they defined X- application-specific headers for a reason. Is there an RFC which says that applications running on top of HTTP *MUST* use HTTP response codes in preference to X- headers, Content-MD5, etc? I honestly don't know... If you want to describe more fully your other suggestions, I'd be interested in hearing them. I've already taken note of the Content-MD5 header, that one could be nice... >At a minimum, the PEP should incorporate this alternate suggestion for >reporting status. Meaning that all clients *HAVE* to support both methods? That's what the "protocol_version" field is for -- if I'm convinced it's the right way to go, I'll set up the server so it can handle both methods, change the PEP to use the HTTP codes *ONLY*. Sean -- Brooks's Law of Prototypes: Plan to throw one away, you will anyhow. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From gstein@lyra.org Tue Mar 27 08:52:01 2001 From: gstein@lyra.org (Greg Stein) Date: Tue Mar 27 08:52:01 2001 Subject: [Distutils] [PEP 243] upload status is bogus In-Reply-To: <20010327061258.J1466@tummy.com>; from jafo@tummy.com on Tue, Mar 27, 2001 at 06:12:59AM -0700 References: <20010326145914.A27539@lyra.org> <20010327045043.B22549@tummy.com> <20010327042055.A27539@lyra.org> <20010327061258.J1466@tummy.com> Message-ID: <20010327055148.B27539@lyra.org> On Tue, Mar 27, 2001 at 06:12:59AM -0700, Sean Reifschneider wrote: > On Tue, Mar 27, 2001 at 04:20:55AM -0800, Greg Stein wrote: > >4xx failures mean "you can probably fix it and resubmit." 5xx failures are > >"just give up, buddy." If a web server reports 4xx because of a config > > For this application, a 500 error should be considered a temporary failure. > I believe that HTTP should report 200 if it successfully ran the CGI, > anything else if it did not. I would hardly call making use of the X- > headers "Yet Another Protocol". But 200 implies everything was OK with the transaction, when it really wasn't. Those status codes aren't simply "did you run the script for me" but a response about what the server *did*. > >[ and don't even get me started on how the package is uploaded; I'm playing > > soft here; those MD5 checksums and the multipart stuff have alternatives > > "playing soft here"? Geeze, this isn't some competition... This whole > section in the brackets makes it sound like you were just holding those > comments back so you could make me look like an idiot if I didn't respond > favorably to your initial message proclaiming my work "bogus". Not my intent to be a competition or to hold back or even think of calling you or anyone else and idiot(!). Simply that I saw a number of changes that could be done, but I just don't care to push on. How the data is marshalled over the wire (multipart or some other mechanism) is mostly noise. Many options work, and I think there are other choices, but they simply don't bug me enough to speak up :-). The point is that I think you've selected a fine way to marshal the package. The bracket-comment was saying that I'm not trying to be annoying... if I was, then I could dredge up all kinds of muck to throw about :-) Please excuse the word "bogus" in the initial subject line. I'm not saying your *work* is bogus. That was simply a word choice for how the errors are reported. Maybe it sounds harsh, but that's not the intent. Ask anybody... I'm not the kind the guy to harsh on a person. And the brackets are just my way of marking a side-comment. i.e. not part of the discussion and safely ignored. > The repository system has repeatedly suffered because of trying to make it > perfect. Not suggesting perfection. Just a simple change to error reporting. As above, I'm explicitly avoiding numerous tweaks because in the larger scheme of things, they just don't fuggin matter :-) > I'm not going to commit the HTTP RFCs to memory just to track > down some vague mentions you make about my not conforming to spec. No need for you to memorize them. I've been living and breathing them for several years now. Only one person needs the brain pollution :-) > As far as I know, I'm following the standards. You are; I just think that you can "lower the impedance" with HTTP in this one case. > The "multipart stuff" is RFC1867, > and I'd submit that they defined X- application-specific headers for a > reason. Is there an RFC which says that applications running on top of > HTTP *MUST* use HTTP response codes in preference to X- headers, > Content-MD5, etc? I honestly don't know... There aren't any RFCs that say that. It is essentially more a design gestalt than anything. Long hours, days, weeks, ... hell, the past two years :-) dealing with WebDAV, and its design philosophy for leveraging HTTP plus a lot of queries to Roy Fielding plus implementation... just kinda makes me a bit knee-jerk about how to build apps/systems on top of HTTP. > If you want to describe more fully your other suggestions, I'd be > interested in hearing them. I've already taken note of the Content-MD5 > header, that one could be nice... [ woah. looks like the PEP was updated in the past 12 hours ] Well, it mostly depends on whether the submission will always be done with client software, or whether you want to allow a browser to do it. One point: if a browser will be uploading (via the example
in the PEP), then the X- headers won't help out the browser user (the 200 OK will make everything appear hunky dory to the user). If we assume that is changed, per my suggestion, then you'd be browser-compatible with an upload. However... if you wanted to only use software-driven uploads, then your MD5s would go into the Content-MD5 header in each part. The platform and the new protocol-version would become X-Headers. At this point, if the client doesn't submit a pkginfo (deferring to the contained PKG-INFO file), then you wouldn't even need a multipart file. The distribution itself could be the body of the POST message. Finally, there is a possible consideration to use Content-Encoding for noting a compression for the transfer; this implies the server will decompress the file, but that is actually a potential plus -- the server could then create a .Z, .gz, and .bz2 for the distro. Dunno on the Content-Encoding, but there is a possibility here. There is no signature mechanism in pure HTTP; it is only SSL, and that is a hairball to completely avoid. Using a PGP signature as an attachment is an excellent thought. > >At a minimum, the PEP should incorporate this alternate suggestion for > >reporting status. > > Meaning that all clients *HAVE* to support both methods? Oh, geez no! The PEP is supposed to capture discussion and alternatives for historical record. Thus, two years from now, when somebody goes, "why didn't they use HTTP status codes?", they can see the PEP and the rationale for not using them. Or vice-versa. IOW, the PEP isn't only "this is how it will be done", but also "here are the alternatives that were discussed, and accepted/rejected." It keeps the same arguments from arising all the time :-) With the info in the PEP, you can say, "been there, done that. read the PEP and go away" :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From phrxy@csv.warwick.ac.uk Tue Mar 27 13:38:01 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Tue Mar 27 13:38:01 2001 Subject: [Distutils] Re: RFC: PEP243: Module Repository Upload Mechanism In-Reply-To: <20010325192644.B5240@tummy.com> Message-ID: On Sun, 25 Mar 2001, Sean Reifschneider wrote: [...] > Well, the reason I did it that way was because RedHat 7.0 is quite a bit > different than, say Mandrake 7.0. So you think OS of "Linux" and the > version would be "redhat_7.0"? I could dig that. Good idea. I wasn't > really happy with having a butt-load of Linux names as the OS names... [...] In that case, can I just ask again why you're not using the os.name values? The two sets of categories seem to coincide. If there are missing values from those allowed os.name ATM, why not add them? John From amos@digicool.com Tue Mar 27 21:35:01 2001 From: amos@digicool.com (Amos Latteier) Date: Tue Mar 27 21:35:01 2001 Subject: [Distutils] [ANN] Prototype catalog server updated Message-ID: <3AC14CF6.93BF6029@digicool.com> Hello Pythonistas, I've updated my prototype catalog server http://63.230.174.230:8080/archive It now keeps track of who uploaded what. Plus, the registration process sends email, so you need to provide a valid email address. Also, you can now edit your user account information. It still does not implement pep 243. To contribute packages, get the lastest distutils (1.0.2pre) which implements PEP 241. Create a package. Create a user account on the catalog server, and upload your your package. If you just want to play around, you can manually create a PKG-INFO file for your archive and upload that. I'd love feedback. Does this seem like I'm going in the right direction? What could be done to make it easier for uploaders and/or downloaders. Did you encounter any errors? Does the server not parse your package correctly? Enjoy! -Amos P.S. The source of the catalog server is available on the catalog server. (Though, I cheated, and added a PKG-INFO file manually.) -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From thomas.heller@ion-tof.com Wed Mar 28 01:36:00 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Wed Mar 28 01:36:00 2001 Subject: [Distutils] [ANN] Prototype catalog server updated References: <3AC14CF6.93BF6029@digicool.com> Message-ID: <002d01c0b751$331b3930$e000a8c0@thomasnotebook> Amos, the upload failes for me, this is what I get from IE5.5. Thomas Zope Error Zope has encountered an error while publishing this resource. Error Type: ParseError Error Value: ('Unknown archive format', 'application/x-zip-compressed', None) Troubleshooting Suggestions The URL may be incorrect. The parameters passed to this resource may be incorrect. A resource that this resource relies on may be encountering an error. For more detailed information about the error, please refer to the HTML source for this page. If the error persists please contact the site maintainer. Thank you for your patience. Traceback (innermost last): File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/amos/Trunk/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: RoleManager) File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/amos/Trunk/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: addArchive) File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: addArchive) File /home/amos/Trunk/lib/python/Products/NetDist/ArchiveManager.py, line 409, in addArchive (Object: RoleManager) File /home/amos/Trunk/lib/python/Products/NetDist/Archive.py, line 69, in update (Object: RoleManager) File /home/amos/Trunk/lib/python/Products/NetDist/Parse.py, line 56, in parse_meta_data ParseError: (see above) From martin@loewis.home.cs.tu-berlin.de Wed Mar 28 02:50:01 2001 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed Mar 28 02:50:01 2001 Subject: [Distutils] Re: [Catalog-sig] [ANN] Prototype catalog server updated In-Reply-To: <3AC14CF6.93BF6029@digicool.com> (message from Amos Latteier on Tue, 27 Mar 2001 18:31:18 -0800) References: <3AC14CF6.93BF6029@digicool.com> Message-ID: <200103280740.f2S7eSU01092@mira.informatik.hu-berlin.de> > I'd love feedback. Does this seem like I'm going in the right direction? Unfortunately, it does not look that way to me. I was hoping that support for the PEP 243 protocol has priority - so I'd rather expect to tell the system my PGP public key, instead of telling it my home page. Having a second implementation of the PEP is important, so that we can find out whether it is well-enough specified to allow to survive for the next year or so. Regards, Martin From mal@lemburg.com Wed Mar 28 08:50:02 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Mar 28 08:50:02 2001 Subject: [Distutils] The 'test' command References: <3AB88E28.4D718C93@lemburg.com> <20010321123141.K15282@ute.cnri.reston.va.us> <20010324011446.E4804@tummy.com> <20010326163649.C21520@ute.cnri.reston.va.us> Message-ID: <3AC1EBB7.B67B23DB@lemburg.com> Andrew Kuchling wrote: > > On Sat, Mar 24, 2001 at 01:14:46AM -0700, Sean Reifschneider wrote: > >Along with the name, I think that it'll have to have a default stub which > >does an "exit(0)" (the default test succeeds) so that the lack of a test > >doesn't show up the same as a test failure. > > 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. I would prefer to have an option which then tells distutils which files should be run a regression test, e.g. tests=['a.py','b.py']. > 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). Please don't make any assumptions about the framework behind the test suites -- not everyone is going to use pyunit for this... I'd suggest to simply run the scripts defined in the tests parameter and look at the resulting shell return code (0 - success; everything else: failure). -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From hinsen@cnrs-orleans.fr Wed Mar 28 11:34:01 2001 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Wed Mar 28 11:34:01 2001 Subject: [Distutils] Header installation Message-ID: <200103281633.SAA18020@chinon.cnrs-orleans.fr> I am trying to distutilsify my Python packages, but I am stuck at an almost undocumented point: installation of header files. In fact, the Distutils manual only says that it can be done, but not how, and the only real-life example that does it seems to be NumPy. Here's my situation: I have a distribution called "ScientificPython" which contains a Python package "Scientific", which in turn contains an extension module for which some header files exist. These files are supposed to end up in $prefix/pythonx.y/Scientific, such that they can be included as "Scientific/xxx". However, if I do exactly what NumPy does, they end up in $prefix/pythonx.y/ScientificPython. The only way I found to change the header installation directory is by specifying an option during installation, but I want this defined in setup.py. Any suggestions? Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From robin@alldunn.com Wed Mar 28 11:46:39 2001 From: robin@alldunn.com (Robin Dunn) Date: Wed Mar 28 11:46:39 2001 Subject: [Distutils] The 'test' command References: <3AB88E28.4D718C93@lemburg.com> <20010321123141.K15282@ute.cnri.reston.va.us> <20010324011446.E4804@tummy.com> <20010326163649.C21520@ute.cnri.reston.va.us> <3AC1EBB7.B67B23DB@lemburg.com> Message-ID: <078d01c0b7a6$74e1c0a0$0100a8c0@Rogue> > > I would prefer to have an option which then tells distutils > which files should be run a regression test, e.g. tests=['a.py','b.py']. > How about tests = [('testDir1', ['a.py','b.py']), ('testDir2', ['c.py','d.py', 'e.py']) ] And it would then change into the specified test directory before running the test scripts found there, and more than one group could be specified. > > Please don't make any assumptions about the framework behind the > test suites -- not everyone is going to use pyunit for this... > > I'd suggest to simply run the scripts defined in the tests > parameter and look at the resulting shell return code (0 - success; > everything else: failure). > I agree. -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! From mal@lemburg.com Wed Mar 28 13:40:04 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Mar 28 13:40:04 2001 Subject: [Distutils] Header installation References: <200103281633.SAA18020@chinon.cnrs-orleans.fr> Message-ID: <3AC22FCD.4ABD3920@lemburg.com> Konrad Hinsen wrote: > > I am trying to distutilsify my Python packages, but I am stuck at an > almost undocumented point: installation of header files. In fact, the > Distutils manual only says that it can be done, but not how, and the > only real-life example that does it seems to be NumPy. > > Here's my situation: I have a distribution called "ScientificPython" > which contains a Python package "Scientific", which in turn contains > an extension module for which some header files exist. These files > are supposed to end up in $prefix/pythonx.y/Scientific, such that > they can be included as "Scientific/xxx". However, if I do exactly what > NumPy does, they end up in $prefix/pythonx.y/ScientificPython. The > only way I found to change the header installation directory is by > specifying an option during installation, but I want this defined > in setup.py. Any suggestions? There is a command install_headers which could be what you are looking for. If that doesn't work, you could try to use the data_files directive for this (I had to subclass it though to do anything useful...). -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From hinsen@cnrs-orleans.fr Wed Mar 28 13:59:01 2001 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Wed Mar 28 13:59:01 2001 Subject: [Distutils] Header installation In-Reply-To: <3AC22FCD.4ABD3920@lemburg.com> (mal@lemburg.com) References: <200103281633.SAA18020@chinon.cnrs-orleans.fr> <3AC22FCD.4ABD3920@lemburg.com> Message-ID: <200103281859.UAA11270@chinon.cnrs-orleans.fr> > There is a command install_headers which could be what you are > looking for. If that doesn't work, you could try to use I think this is what I am already using by writing headers = [...] (please correct me if I am wrong). And it works fine, except that I don't know how to tell it *where* I want my header files installed. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From akuchlin@mems-exchange.org Wed Mar 28 14:02:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed Mar 28 14:02:01 2001 Subject: [Distutils] Header installation In-Reply-To: <200103281633.SAA18020@chinon.cnrs-orleans.fr>; from hinsen@cnrs-orleans.fr on Wed, Mar 28, 2001 at 06:33:57PM +0200 References: <200103281633.SAA18020@chinon.cnrs-orleans.fr> Message-ID: <20010328140130.C23812@ute.cnri.reston.va.us> On Wed, Mar 28, 2001 at 06:33:57PM +0200, Konrad Hinsen wrote: >NumPy does, they end up in $prefix/pythonx.y/ScientificPython. The >only way I found to change the header installation directory is by >specifying an option during installation, but I want this defined >in setup.py. Any suggestions? Putting this in a setup.cfg file should do it: [install_headers] install_dir=/wherever I don't think you can define anything in the setup() call to set the directory. --amk From mal@lemburg.com Thu Mar 29 03:32:04 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Mar 29 03:32:04 2001 Subject: [Distutils] Header installation References: <200103281633.SAA18020@chinon.cnrs-orleans.fr> <3AC22FCD.4ABD3920@lemburg.com> <200103281859.UAA11270@chinon.cnrs-orleans.fr> Message-ID: <3AC2F2AF.CD32C718@lemburg.com> Konrad Hinsen wrote: > > > There is a command install_headers which could be what you are > > looking for. If that doesn't work, you could try to use > > I think this is what I am already using by writing headers = [...] > (please correct me if I am wrong). And it works fine, except that I > don't know how to tell it *where* I want my header files installed. >From reading the source for install_headers: user_options = [('install-dir=', 'd', "directory to install header files to"), ('force', 'f', "force installation (overwrite existing files)"), ] --install-dir defaults to the value of --install-headers of the install command: ('install-headers=', None, "installation directory for C/C++ headers"), This again defaults to: 'unix_prefix': # without PYTHONHOME set 'headers': '$base/include/python$py_version_short/$dist_name', 'unix_home': # with PYTHONHOME set 'headers': '$base/include/python/$dist_name', 'nt': 'headers': '$base/Include/$dist_name', 'mac': 'headers': '$base/Include/$dist_name', At least in theory, adding the install_header option to your setup.cfg file should do the trick. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From Paul.Moore@uk.origin-it.com Thu Mar 29 04:09:01 2001 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Thu Mar 29 04:09:01 2001 Subject: [Distutils] Header installation Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADC6@ukrux002.rundc.uk.origin-it.com> From: M.-A. Lemburg [mailto:mal@lemburg.com] > This again defaults to: > > 'unix_prefix': # without PYTHONHOME set > 'headers': '$base/include/python$py_version_short/$dist_name', > > 'unix_home': # with PYTHONHOME set > 'headers': '$base/include/python/$dist_name', > > 'nt': > 'headers': '$base/Include/$dist_name', > > 'mac': > 'headers': '$base/Include/$dist_name', I think the original poster was saying that he wanted to use something other than $dist_name in these. Whether allowing that is a reasonable idea, I can't say. But it's very different from wanting to alter the base install location.... Paul. PS Do the installers butlt by distutils (bdist_wininst and the like) respect setup.cfg? If not, I believe they should. Or at least, the installer should include a way for the end user to specify an alternative install directory... From mal@lemburg.com Thu Mar 29 04:49:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Mar 29 04:49:01 2001 Subject: [Distutils] Header installation References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADC6@ukrux002.rundc.uk.origin-it.com> Message-ID: <3AC304D4.83476802@lemburg.com> "Moore, Paul" wrote: > > From: M.-A. Lemburg [mailto:mal@lemburg.com] > > This again defaults to: > > > > 'unix_prefix': # without PYTHONHOME set > > 'headers': '$base/include/python$py_version_short/$dist_name', > > > > 'unix_home': # with PYTHONHOME set > > 'headers': '$base/include/python/$dist_name', > > > > 'nt': > > 'headers': '$base/Include/$dist_name', > > > > 'mac': > > 'headers': '$base/Include/$dist_name', > > I think the original poster was saying that he wanted to use something other > than $dist_name in these. Whether allowing that is a reasonable idea, I > can't say. But it's very different from wanting to alter the base install > location.... I haven't tried this, but from looking at the code, Martin can use the same escapes in his definition of install_headers, e.g. install_headers = $base/MyIncludes I'm not sure about the collection of variables available for expansion (they are scattered all over distutils), but at most of them follow the naming scheme used in the standard Python Makefile, so their names should be easy to deduce. > Paul. > > PS Do the installers butlt by distutils (bdist_wininst and the like) respect > setup.cfg? If not, I believe they should. Or at least, the installer should > include a way for the end user to specify an alternative install > directory... Hmm, the build commands do respect the settings in the setup.cfg file, but the installer itself doesn't. It would be nice, if the wininst installer would allow even more flexibility, e.g. allow setting the install directory (this would then have to generate a .pth file to properly setup the Python path), optionally generating a "click to accept license" box and an optional "misc notice" box (for arbitrary additional information which wouldn't fit into the standard description box). Thomas Heller has already done a fantastic job here, so these are really only minor nits. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From hinsen@cnrs-orleans.fr Thu Mar 29 05:36:01 2001 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Thu Mar 29 05:36:01 2001 Subject: [Distutils] Header installation In-Reply-To: <3AC2F2AF.CD32C718@lemburg.com> (mal@lemburg.com) References: <200103281633.SAA18020@chinon.cnrs-orleans.fr> <3AC22FCD.4ABD3920@lemburg.com> <200103281859.UAA11270@chinon.cnrs-orleans.fr> <3AC2F2AF.CD32C718@lemburg.com> Message-ID: <200103291036.MAA11982@chinon.cnrs-orleans.fr> > This again defaults to: > > 'unix_prefix': # without PYTHONHOME set > 'headers': '$base/include/python$py_version_short/$dist_name', > > 'unix_home': # with PYTHONHOME set > 'headers': '$base/include/python/$dist_name', > > 'nt': > 'headers': '$base/Include/$dist_name', > > 'mac': > 'headers': '$base/Include/$dist_name', > > At least in theory, adding the install_header option to your > setup.cfg file should do the trick. If I know the precise path name, yes. But I don't. Perhaps I could set install_headers = "$base/include/python$py_version_short/xxx" in setup.cfg and have the variables expanded (I didn't check if this works), but I'd still have to assume a specific installation scheme. What I really want is replace $dist_name with the name of my package, for the rest I fully trust distutils. Anyway, for the moment I am giving up; I'll continue with my own home-grown installation scripts instead of switching to distutils. For my next project, I'd need a subdirectory within the main header file directory, and that seems completely beyond the capabilities of distutils in its current form. I suppose I could do it with extensions to distutils, but at the moment I simply don't have the time to figure this out without any documentation. And here's yet another challenge: I have a package that produces a new Python interpreter (including a module that has to be static), which should be installed to something like /usr/local/bin. Perhaps that could be done via the data file installation, but then again I don't have the time to figure it out at the moment. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From Paul.Moore@uk.origin-it.com Thu Mar 29 05:51:01 2001 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Thu Mar 29 05:51:01 2001 Subject: [Distutils] Header installation Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADC8@ukrux002.rundc.uk.origin-it.com> From: M.-A. Lemburg [mailto:mal@lemburg.com] > > PS Do the installers butlt by distutils (bdist_wininst and > > the like) respect setup.cfg? If not, I believe they should. > > Or at least, the installer should include a way for the end > > user to specify an alternative install directory... > > Hmm, the build commands do respect the settings in the setup.cfg file, > but the installer itself doesn't. > > It would be nice, if the wininst installer would allow even more > flexibility, e.g. allow setting the install directory (this would > then have to generate a .pth file to properly setup the Python path), Not necessarily. All I care about is that I absolutely will not accept the default of putting modules in the Python executable directory. I feel that this is completely wrong, and needs change. There is a perfectly respectable Lib/site-packages directory, but Python ignores it (on Windows). The fix is a 1-line change to site.py, which I understand is not done because of some form of policy issue, rather than for any technical reason (ie, Guido doesn't like it...) I have hacked site.py to override this. I want to override the default location where modules are installed, as well. I simply will not use an installer which dumps arbitrary modules in the Python executable directory. The wininst installer is hackable, as it is basically an exe prepended onto a zip file, so I can unzip the distribution wherever I like. But I wish I didn't need to do this. OTOH, I don't want my Windows "add/remove programs" applet cluttered with loads of Python modules, either (which I believe is also something the wininst installer does). So personally, I would prefer to just have a zip which I could install myself... Two questions - is the bdist_zip option functional (no time to try it just now)? And how can we persuade package authors to provide a bdist_zip version of their packages as well as an installer version? (Sorry - I HATE installers, and particularly so when I have no way of controlling or limiting what they do...) Paul. From thomas.heller@ion-tof.com Thu Mar 29 06:28:00 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 29 06:28:00 2001 Subject: [Distutils] Header installation References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADC8@ukrux002.rundc.uk.origin-it.com> Message-ID: <02d601c0b843$234ef2b0$e000a8c0@thomasnotebook> > The wininst installer is hackable, as it is basically an exe prepended onto > a zip file, so I can unzip the distribution wherever I like. But I wish I > didn't need to do this. OTOH, I don't want my Windows "add/remove programs" > applet cluttered with loads of Python modules, either (which I believe is > also something the wininst installer does). Only in the newest version (1.0.2pre, as in python2.1b2) the module is added to the add/remove programs list. Of course I could include a flag into the installer to let the user decide whether to record deinstall information, but normally this is not decided by the poor user. IMO most Windows installers are already asking questions where no one can provide the correct answer (You have already installed xxx.dll in anther language and in another version. Would you like it to be replaced?) > So personally, I would prefer to > just have a zip which I could install myself... Since the installer is an exe prepended onto a zip file (as you noted), Winzip is happy to open and extract it as a zip file. Maybe if this fact would be documented better, it could come to rescue for the 'expert' user who has his own opinions about the install location, uninstall, and so on. > > Two questions - is the bdist_zip option functional (no time to try it just > now)? And how can we persuade package authors to provide a bdist_zip version > of their packages as well as an installer version? Last time I checked, 'bdist --formats=zip' creates a zip-file with pathnames relative to the root directory 'python20/package/module.py' or even worse 'Program Files/python/package/module.py' or 'Programme/python/package/module.py' depending on where your python is installed. > > (Sorry - I HATE installers, and particularly so when I have no way of > controlling or limiting what they do...) This is (mostly) true for any installers I know. (OK, the install location is normally changeable...) Thomas From Paul.Moore@uk.origin-it.com Thu Mar 29 07:47:01 2001 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Thu Mar 29 07:47:01 2001 Subject: [Distutils] Header installation Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADCA@ukrux002.rundc.uk.origin-it.com> From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > > The wininst installer is hackable, as it is basically > > an exe prepended onto a zip file, so I can unzip the > > distribution wherever I like. But I wish I didn't need > > to do this. OTOH, I don't want my Windows "add/remove > > programs" applet cluttered with loads of Python modules, > > either (which I believe is also something the wininst > > installer does). > > Only in the newest version (1.0.2pre, as in python2.1b2) > the module is added to the add/remove programs list. Of > course I could include a flag into the installer to let > the user decide whether to record deinstall information, > but normally this is not decided by the poor user. IMO > most Windows installers are already asking questions where > no one can provide the correct answer (You have already > installed xxx.dll in anther language and in another > version. Would you like it to be replaced?) Agreed, I know of no other installer which offers the option to not set up uninstall info. On the other hand, I know of no other case of "parts" of a system having separate installers, so there's not much precedent. I have 17 or so modules - which would be half as many again entries in my add/remove programs... In the absence of a Python-specific "installed modules" repository (which I actually think would be a better approach), I don't see much reason to change from the Windows uninstall facility. But maybe having the description *always* start with "Python -" (for example "Python - Numeric", "Python - wxPython") would at least keep them together. > > So personally, I would prefer to just have a zip which > > I could install myself... > > Since the installer is an exe prepended onto a zip file > (as you noted), Winzip is happy to open and extract it as > a zip file. Maybe if this fact would be documented better, > it could come to rescue for the 'expert' user who has his > own opinions about the install location, uninstall, and so > on. If that is guaranteed to remain the case, then yes it should be documented. > > Two questions - is the bdist_zip option functional > > (no time to try it just now)? And how can we persuade > > package authors to provide a bdist_zip version of their > > packages as well as an installer version? > > Last time I checked, 'bdist --formats=zip' creates > a zip-file with pathnames relative to the root > directory 'python20/package/module.py' or even > worse 'Program Files/python/package/module.py' or > 'Programme/python/package/module.py' depending on where > your python is installed. That's roughly what I remembered - and in my opinion that counts as "broken" :-( If format=zip remains broken, while format=bdist_wininst is working, zip format will fall into disuse, to the extent that developers will not even think of it - and so the only binary distributions available will be installer-based :-( (Note: I don't have a problem with installers being available, just with them being the only thing available). > > (Sorry - I HATE installers, and particularly so when I > > have no way of controlling or limiting what they do...) > > This is (mostly) true for any installers I know. (OK, the > install location is normally changeable...) True. Actually, what I hate with a vengeance is installers which don't tell you what they *do*. Do they just install files in the application directory? Do they add entries to the registry? Install files in the Windows directory? What? Can I ask that somewhere, the full details of exactly what the wininst installer does and does not do, be documented. What it doesn't do is at least as important as what it does. No hidden magic! (And yes, I know there's always the source. But sources can change - documentation is a contract, which doesn't get violated.) Paul. From thomas.heller@ion-tof.com Thu Mar 29 08:16:56 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 29 08:16:56 2001 Subject: [Distutils] Header installation References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADCA@ukrux002.rundc.uk.origin-it.com> Message-ID: <03a701c0b852$4deb01d0$e000a8c0@thomasnotebook> > Agreed, I know of no other installer which offers the option to not set up > uninstall info. On the other hand, I know of no other case of "parts" of a > system having separate installers, so there's not much precedent. I have 17 > or so modules - which would be half as many again entries in my add/remove > programs... > > In the absence of a Python-specific "installed modules" repository (which I > actually think would be a better approach), This would probably be best. Paul Prescod already suggested this, and it seems it has also been discussed on the python conference (see AMK's post about 'tasks arising from IPC9). > I don't see much reason to > change from the Windows uninstall facility. But maybe having the description > *always* start with "Python -" (for example "Python - Numeric", "Python - > wxPython") would at least keep them together. They _are_ kept together, this is an excerpt of my list: Python 1.5 Distutils-1.0.2pre Python 1.5 py2exe-0.2.4 Python 1.5.2 (final) Python 2.0 Python 2.0 conbined Win32 extensions Python 2.0 Distutils-1.0.2pre Python 2.0 py2exe-0.2.4 Python 2.1 beta 2 > > > > So personally, I would prefer to just have a zip which > > > I could install myself... > > > > Since the installer is an exe prepended onto a zip file > > (as you noted), Winzip is happy to open and extract it as > > a zip file. Maybe if this fact would be documented better, > > it could come to rescue for the 'expert' user who has his > > own opinions about the install location, uninstall, and so > > on. > > If that is guaranteed to remain the case, then yes it should be documented. It should be documented near the download link (most windows users are known not to read anything - they just download and run ;-) > > > (Sorry - I HATE installers, and particularly so when I > > > have no way of controlling or limiting what they do...) > > > > This is (mostly) true for any installers I know. (OK, the > > install location is normally changeable...) > > True. Actually, what I hate with a vengeance is installers which don't tell > you what they *do*. Do they just install files in the application directory? > Do they add entries to the registry? Install files in the Windows directory? > What? The advantage of 'human readable' install log files (as in bdist_wininst, or WISE, not in InstallShield) is that you at least can see what they _have done_. > > Can I ask that somewhere, the full details of exactly what the wininst > installer does and does not do, be documented. What it doesn't do is at > least as important as what it does. No hidden magic! (And yes, I know > there's always the source. But sources can change - documentation is a > contract, which doesn't get violated.) Yes, I will provide this docs, but it will probably go into the 'Installing python modules' manual. For the user: Should the installer display a summary of what it will do in the dialog box? (This would not be very detailed - perhaps summarizing the selections the user did make). Should there be an option to run it in dry-mode (like setup install --dry-run) and display the actions? Thomas From hinsen@cnrs-orleans.fr Thu Mar 29 09:48:01 2001 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Thu Mar 29 09:48:01 2001 Subject: [Distutils] Header installation In-Reply-To: <200103291036.MAA11982@chinon.cnrs-orleans.fr> (message from Konrad Hinsen on Thu, 29 Mar 2001 12:36:16 +0200) References: <200103281633.SAA18020@chinon.cnrs-orleans.fr> <3AC22FCD.4ABD3920@lemburg.com> <200103281859.UAA11270@chinon.cnrs-orleans.fr> <3AC2F2AF.CD32C718@lemburg.com> <200103291036.MAA11982@chinon.cnrs-orleans.fr> Message-ID: <200103291448.QAA15107@chinon.cnrs-orleans.fr> > What I really want is replace $dist_name with the name of my package, > for the rest I fully trust distutils. You just have to give up in order to realize that this can be done rather easily: from distutils.command.install_headers import install_headers class modified_install_headers(install_headers): def finalize_options(self): install_headers.finalize_options(self) self.install_dir = \ os.path.join(os.path.split(self.install_dir)[0], 'Scientific') setup( ... , cmdclass = {'install_headers': modified_install_headers}) Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From akuchlin@mems-exchange.org Thu Mar 29 10:39:00 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Mar 29 10:39:00 2001 Subject: [Distutils] The 'test' command In-Reply-To: <078d01c0b7a6$74e1c0a0$0100a8c0@Rogue>; from robin@alldunn.com on Wed, Mar 28, 2001 at 08:45:11AM -0800 References: <3AB88E28.4D718C93@lemburg.com> <20010321123141.K15282@ute.cnri.reston.va.us> <20010324011446.E4804@tummy.com> <20010326163649.C21520@ute.cnri.reston.va.us> <3AC1EBB7.B67B23DB@lemburg.com> <078d01c0b7a6$74e1c0a0$0100a8c0@Rogue> Message-ID: <20010329103838.A26431@ute.cnri.reston.va.us> On Wed, Mar 28, 2001 at 08:45:11AM -0800, Robin Dunn wrote: > tests = [('testDir1', ['a.py','b.py']), > ('testDir2', ['c.py','d.py', 'e.py']) ] I like having the computer do things so that I don't have to. How about allowing glob patterns in the above, so it could be ('testDir1', ['test_*.py']). >> I'd suggest to simply run the scripts defined in the tests >> parameter and look at the resulting shell return code (0 - success; >> everything else: failure). > >I agree. Another reason to do this: running everything in one interpreter instance could conceal weird bugs where data structures aren't being initialized properly in a single test, but because previous modules did the initialization, the code works. So forking is clearly the right thing to do. Should I begin writing a PEP on this for 2.2? --amk From thomas.heller@ion-tof.com Thu Mar 29 11:17:00 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 29 11:17:00 2001 Subject: [Distutils] The 'test' command References: <3AB88E28.4D718C93@lemburg.com> <20010321123141.K15282@ute.cnri.reston.va.us> <20010324011446.E4804@tummy.com> <20010326163649.C21520@ute.cnri.reston.va.us> <3AC1EBB7.B67B23DB@lemburg.com> <078d01c0b7a6$74e1c0a0$0100a8c0@Rogue> <20010329103838.A26431@ute.cnri.reston.va.us> Message-ID: <04ae01c0b86b$95715d60$e000a8c0@thomasnotebook> > Should I begin writing a PEP on this for 2.2? > What do you mean: Jump from 1.0.2pre to 2.2 ;-) ? Seriously: Won't there be separate distutils releases any more? Will distutils completely accept python's development practices? PEPs and all? In this case it seems I would also have to write a PEP for uninstallation (wininst and distutils in general). Thomas From akuchlin@mems-exchange.org Thu Mar 29 12:20:00 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Mar 29 12:20:00 2001 Subject: [Distutils] The 'test' command In-Reply-To: <04ae01c0b86b$95715d60$e000a8c0@thomasnotebook>; from thomas.heller@ion-tof.com on Thu, Mar 29, 2001 at 06:16:16PM +0200 References: <3AB88E28.4D718C93@lemburg.com> <20010321123141.K15282@ute.cnri.reston.va.us> <20010324011446.E4804@tummy.com> <20010326163649.C21520@ute.cnri.reston.va.us> <3AC1EBB7.B67B23DB@lemburg.com> <078d01c0b7a6$74e1c0a0$0100a8c0@Rogue> <20010329103838.A26431@ute.cnri.reston.va.us> <04ae01c0b86b$95715d60$e000a8c0@thomasnotebook> Message-ID: <20010329121955.B26431@ute.cnri.reston.va.us> On Thu, Mar 29, 2001 at 06:16:16PM +0200, Thomas Heller wrote: >> Should I begin writing a PEP on this for 2.2? >> >What do you mean: Jump from 1.0.2pre to 2.2 ;-) ? >Won't there be separate distutils releases any more? I mean so that it gets into Python 2.2; Distutils releases will continue, at least until Python 1.5.2 is dead and gone, which seems to be about 2 years away. >Will distutils completely accept python's development >practices? PEPs and all? >In this case it seems I would also have to write a PEP >for uninstallation (wininst and distutils in general). That's actually a good question. The 'test' command will raise some issues, but it shouldn't be too complicated, and a PEP may be overkill. I'm actually happy just discussing things, doing a first implementation, and then poking at the code, but would like to know what the rest of the SIG's readers think. For example, I'm not sure what a bdist_wininst PEP would have accomplished, and don't see the need to write one now. --amk From robin@alldunn.com Thu Mar 29 12:53:01 2001 From: robin@alldunn.com (Robin Dunn) Date: Thu Mar 29 12:53:01 2001 Subject: [Distutils] The 'test' command References: <3AB88E28.4D718C93@lemburg.com> <20010321123141.K15282@ute.cnri.reston.va.us> <20010324011446.E4804@tummy.com> <20010326163649.C21520@ute.cnri.reston.va.us> <3AC1EBB7.B67B23DB@lemburg.com> <078d01c0b7a <20010329103838.A26431@ute.cnri.reston.va.us> Message-ID: <0c4d01c0b878$f85748b0$0100a8c0@Rogue> > On Wed, Mar 28, 2001 at 08:45:11AM -0800, Robin Dunn wrote: > > tests = [('testDir1', ['a.py','b.py']), > > ('testDir2', ['c.py','d.py', 'e.py']) ] > > I like having the computer do things so that I don't have to. > How about allowing glob patterns in the above, so it could be > ('testDir1', ['test_*.py']). > Yes. -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! From amos@digicool.com Thu Mar 29 13:22:03 2001 From: amos@digicool.com (Amos Latteier) Date: Thu Mar 29 13:22:03 2001 Subject: [Distutils] [ANN] Prototype catalog server updated References: <3AC14CF6.93BF6029@digicool.com> <002d01c0b751$331b3930$e000a8c0@thomasnotebook> Message-ID: <3AC37C5D.A2B546EA@digicool.com> Thomas Heller wrote: > the upload failes for me, this is what I get from IE5.5. > > Zope Error > Zope has encountered an error while publishing this resource. > Error Type: ParseError > Error Value: ('Unknown archive format', 'application/x-zip-compressed', None) This should be fixed now. Thanks for the bug report! -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From amos@digicool.com Thu Mar 29 13:28:28 2001 From: amos@digicool.com (Amos Latteier) Date: Thu Mar 29 13:28:28 2001 Subject: [Distutils] Re: [Catalog-sig] [ANN] Prototype catalog server updated References: <3AC14CF6.93BF6029@digicool.com> <200103280740.f2S7eSU01092@mira.informatik.hu-berlin.de> Message-ID: <3AC37DBA.2CE2D5AD@digicool.com> "Martin v. Loewis" wrote: > > > I'd love feedback. Does this seem like I'm going in the right direction? > > Unfortunately, it does not look that way to me. I was hoping that > support for the PEP 243 protocol has priority - so I'd rather expect > to tell the system my PGP public key, instead of telling it my home > page. Supporting PEP 243 is a priority of mine. As is allowing authors to upload their public keys, and OpenPGP signature files when they upload packages. I just haven't gotten there yet. So hopefully I'm heading in the right direction, but too slowly for you to perceive it ;-) > Having a second implementation of the PEP is important, so that we can > find out whether it is well-enough specified to allow to survive for > the next year or so. I agree. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From thomas.heller@ion-tof.com Thu Mar 29 13:52:02 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 29 13:52:02 2001 Subject: [Distutils] Playing with meta-info Message-ID: <051801c0b880$ce1cc310$e000a8c0@thomasnotebook> Playing with the new meta info, I noticed that the license specified in this way: setup(..., license="MIT/X11", ...) isn't recognized, while it works if one uses: setup(..., licence="MIT/X11", ...) Thomas From thomas.heller@ion-tof.com Thu Mar 29 13:57:02 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 29 13:57:02 2001 Subject: [Catalog-sig] Re: [Distutils] [ANN] Prototype catalog server updated References: <3AC14CF6.93BF6029@digicool.com> <002d01c0b751$331b3930$e000a8c0@thomasnotebook> <3AC37C5D.A2B546EA@digicool.com> Message-ID: <053b01c0b881$f8196640$e000a8c0@thomasnotebook> > > the upload failes for me, this is what I get from IE5.5. > > > > Zope Error > > Zope has encountered an error while publishing this resource. > > Error Type: ParseError > > Error Value: ('Unknown archive format', 'application/x-zip-compressed', None) > > This should be fixed now. Still it doesn't work, now I get (my package HAS a PKG-INFO file, see listing at the bottom): Zope Error Zope has encountered an error while publishing this resource. Error Type: ParseError Error Value: Archive does not contain a PKG-INFO file Troubleshooting Suggestions The URL may be incorrect. The parameters passed to this resource may be incorrect. A resource that this resource relies on may be encountering an error. For more detailed information about the error, please refer to the HTML source for this page. If the error persists please contact the site maintainer. Thank you for your patience. Traceback (innermost last): File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/amos/Trunk/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: RoleManager) File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/amos/Trunk/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: addArchive) File /home/amos/Trunk/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: addArchive) File /home/amos/Trunk/lib/python/Products/NetDist/ArchiveManager.py, line 409, in addArchive (Object: RoleManager) File /home/amos/Trunk/lib/python/Products/NetDist/Archive.py, line 69, in update (Object: RoleManager) File /home/amos/Trunk/lib/python/Products/NetDist/Parse.py, line 66, in parse_meta_data ParseError: (see above) ------------ Here is the contents of the file I tried to upload: C:\sf\py2exe\dist>unzip -l py2exe-0.2.4pre.zip Archive: py2exe-0.2.4pre.zip Length Date Time Name -------- ---- ---- ---- 0 03-29-01 20:51 py2exe-0.2.4pre/ 0 03-29-01 20:51 py2exe-0.2.4pre/docs/ 15041 03-23-01 12:01 py2exe-0.2.4pre/docs/index.html 782 03-02-01 22:48 py2exe-0.2.4pre/docs/py2exe.css 4197 02-17-01 23:00 py2exe-0.2.4pre/docs/py2exe.jpg 1087 02-28-01 09:40 py2exe-0.2.4pre/LICENSE.txt 604 03-29-01 20:50 py2exe-0.2.4pre/MANIFEST 243 03-07-01 14:16 py2exe-0.2.4pre/MANIFEST.in 410 03-29-01 20:51 py2exe-0.2.4pre/PKG-INFO 0 03-29-01 20:51 py2exe-0.2.4pre/py2exe/ 31880 03-08-01 21:46 py2exe-0.2.4pre/py2exe/py2exe-0.2.4.py 32781 03-26-01 21:34 py2exe-0.2.4pre/py2exe/py2exe.py 7411 03-21-01 17:13 py2exe-0.2.4pre/py2exe/support.py 1353 03-21-01 17:12 py2exe-0.2.4pre/py2exe/__init__.py 407 02-02-01 20:06 py2exe-0.2.4pre/README.txt 12913 03-29-01 20:49 py2exe-0.2.4pre/setup.py 0 03-29-01 20:51 py2exe-0.2.4pre/source/ 2249 03-21-01 17:10 py2exe-0.2.4pre/source/archive.h 1710 03-23-01 11:03 py2exe-0.2.4pre/source/icon.rc 766 02-08-01 10:32 py2exe-0.2.4pre/source/icon1.ico 2199 03-26-01 09:28 py2exe-0.2.4pre/source/py.c 11305 03-21-01 17:10 py2exe-0.2.4pre/source/py2exe_util.c 282 03-20-01 22:18 py2exe-0.2.4pre/source/python_run.c 453 03-20-01 22:22 py2exe-0.2.4pre/source/resource.h 2827 03-26-01 21:02 py2exe-0.2.4pre/source/run.c 1975 03-21-01 17:11 py2exe-0.2.4pre/source/run_w.c 11925 03-23-01 11:04 py2exe-0.2.4pre/source/start.c 0 03-29-01 20:51 py2exe-0.2.4pre/source/zlib/ 0 03-29-01 20:51 py2exe-0.2.4pre/source/zlib/static32/ 113416 08-18-00 21:33 py2exe-0.2.4pre/source/zlib/static32/zlibstat.lib 8140 01-16-01 16:12 py2exe-0.2.4pre/source/zlib/zconf.h 41791 01-16-01 16:12 py2exe-0.2.4pre/source/zlib/zlib.h 0 03-29-01 20:51 py2exe-0.2.4pre/tools1.5/ 25237 02-19-01 20:44 py2exe-0.2.4pre/tools1.5/imputil.py 14685 02-19-01 20:44 py2exe-0.2.4pre/tools1.5/modulefinder.py 0 02-19-01 20:44 py2exe-0.2.4pre/tools1.5/__init__.py 0 03-29-01 20:51 py2exe-0.2.4pre/tools2.0/ 15106 02-15-01 23:16 py2exe-0.2.4pre/tools2.0/modulefinder.py 0 01-16-01 16:12 py2exe-0.2.4pre/tools2.0/__init__.py 0 03-29-01 20:51 py2exe-0.2.4pre/tools2.1/ 14702 11-06-00 04:49 py2exe-0.2.4pre/tools2.1/modulefinder.py 0 01-16-01 16:12 py2exe-0.2.4pre/tools2.1/__init__.py -------- ------- 377877 42 files C:\sf\py2exe\dist> Thomas From thomas.heller@ion-tof.com Thu Mar 29 14:02:21 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 29 14:02:21 2001 Subject: [Distutils] PEP241 References: <051801c0b880$ce1cc310$e000a8c0@thomasnotebook> Message-ID: <056001c0b882$75e2a1e0$e000a8c0@thomasnotebook> BTW; according to www.opensource.org the MIT license seems to be spelled MIT license nowadays, no longer MIT/X11 lincense. Thomas From mal@lemburg.com Fri Mar 30 02:42:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Mar 30 02:42:01 2001 Subject: [Distutils] Binaries for Windows (Header installation) References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADC8@ukrux002.rundc.uk.origin-it.com> Message-ID: <3AC438BA.3360E43F@lemburg.com> "Moore, Paul" wrote: > > > It would be nice, if the wininst installer would allow even more > > flexibility, e.g. allow setting the install directory (this would > > then have to generate a .pth file to properly setup the Python path), > > Not necessarily. All I care about is that I absolutely will not accept the > default of putting modules in the Python executable directory. I feel that > this is completely wrong, and needs change. There is a perfectly respectable > Lib/site-packages directory, but Python ignores it (on Windows). The fix is > a 1-line change to site.py, which I understand is not done because of some > form of policy issue, rather than for any technical reason (ie, Guido > doesn't like it...) I don't know why distutils installs in Python\Lib\ instead of e.g. Lib\site-packages\, but I do know that you override this option using setup.cfg, so that your particular installer installs in a different destination directory. The problem of course is that distutils default setting will become a standard and changing the location would only cause more confusion... > I have hacked site.py to override this. I want to override the default > location where modules are installed, as well. I simply will not use an > installer which dumps arbitrary modules in the Python executable directory. > > The wininst installer is hackable, as it is basically an exe prepended onto > a zip file, so I can unzip the distribution wherever I like. But I wish I > didn't need to do this. OTOH, I don't want my Windows "add/remove programs" > applet cluttered with loads of Python modules, either (which I believe is > also something the wininst installer does). So personally, I would prefer to > just have a zip which I could install myself... > > Two questions - is the bdist_zip option functional (no time to try it just > now)? And how can we persuade package authors to provide a bdist_zip version > of their packages as well as an installer version? There is no such thing as bdist_zip; bdist_dumb is probably what you meant and yes, it works the way you describe. > (Sorry - I HATE installers, and particularly so when I have no way of > controlling or limiting what they do...) > > Paul. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From Paul.Moore@uk.origin-it.com Fri Mar 30 03:08:02 2001 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Fri Mar 30 03:08:02 2001 Subject: [Distutils] Binaries for Windows (Header installation) Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADCE@ukrux002.rundc.uk.origin-it.com> From: M.-A. Lemburg [mailto:mal@lemburg.com] > I don't know why distutils installs in Python\Lib\ instead of > e.g. Lib\site-packages\, but I do know that you override this > option using setup.cfg, so that your particular installer > installs in a different destination directory. But that only works if you're using distutils to install. As was pointed out, the installer doesn't (currently?) respect this setting. For modules with complex dependencies (OpenGL, Numeric, wxWindows are examples) building from scratch is often not a realistic option. > The problem of course is that distutils default setting will > become a standard and changing the location would only cause more > confusion... Exactly my point. Is the current distutils default the best standard? If not, we should change it NOW, before the user base is too large to even contemplate a change. If the distributed site.py doesn't support the "obvious" place (site-packages), surely now is the time to lobby for the change? > There is no such thing as bdist_zip; bdist_dumb is probably what > you meant and yes, it works the way you describe. Thanks - sorry for the confusion. Thomas said that it currently uses absolute paths rather than relative, which means it needs fixing. But assuming it is fixed, would it get used? Would you distribute the mx utils as a bdist_dumb file as well as the bdist_wininst one you currently supply? Would others? The package repository proposal may make this happen, by distributing the job of building binary distributions. I don't know... Paul. From mal@lemburg.com Fri Mar 30 03:36:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Mar 30 03:36:01 2001 Subject: [Distutils] Binaries for Windows (Header installation) References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADCE@ukrux002.rundc.uk.origin-it.com> Message-ID: <3AC44540.23535C59@lemburg.com> "Moore, Paul" wrote: > > From: M.-A. Lemburg [mailto:mal@lemburg.com] > > I don't know why distutils installs in Python\Lib\ instead of > > e.g. Lib\site-packages\, but I do know that you override this > > option using setup.cfg, so that your particular installer > > installs in a different destination directory. > > But that only works if you're using distutils to install. As was pointed > out, the installer doesn't (currently?) respect this setting. For modules > with complex dependencies (OpenGL, Numeric, wxWindows are examples) building > from scratch is often not a realistic option. True. > > The problem of course is that distutils default setting will > > become a standard and changing the location would only cause more > > confusion... > > Exactly my point. Is the current distutils default the best standard? If > not, we should change it NOW, before the user base is too large to even > contemplate a change. If the distributed site.py doesn't support the > "obvious" place (site-packages), surely now is the time to lobby for the > change? The right way to do this is by writing up a PEP and submitting it for approval. I would certainly vote for moving to site-packages on Windows too, since it makes support easier (same setup on Windows and Unix). I'm not sure how the situation is on other platforms such as Mac or OpenVMS... but that's what PEPs are for :) > > There is no such thing as bdist_zip; bdist_dumb is probably what > > you meant and yes, it works the way you describe. > > Thanks - sorry for the confusion. Thomas said that it currently uses > absolute paths rather than relative, which means it needs fixing. But > assuming it is fixed, would it get used? Would you distribute the mx utils > as a bdist_dumb file as well as the bdist_wininst one you currently supply? > Would others? If there's demand I would add that option to the download page as well -- fortunately, distutils makes creating additional shipping formats easy. > The package repository proposal may make this happen, by distributing the > job of building binary distributions. I don't know... ActiveState is pushing for their new PPM format and will also setup a repository to make installing Python binaries easier. Don't know when this will acutally happen, though. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From jack@oratrix.nl Fri Mar 30 04:38:27 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri Mar 30 04:38:27 2001 Subject: [Distutils] Header installation In-Reply-To: Message by Konrad Hinsen , Thu, 29 Mar 2001 16:48:31 +0200 , <200103291448.QAA15107@chinon.cnrs-orleans.fr> Message-ID: <20010330093733.A10883D1E55@snelboot.oratrix.nl> > You just have to give up in order to realize that this can be done > rather easily: > > from distutils.command.install_headers import install_headers > > class modified_install_headers(install_headers): > > def finalize_options(self): > install_headers.finalize_options(self) > self.install_dir = \ > os.path.join(os.path.split(self.install_dir)[0], > 'Scientific') > > setup( ... , cmdclass = {'install_headers': modified_install_headers}) Ah, brilliant! This is the sort of thing that should go into the documentation. Seeing one example of this overriding will help the intelligent reader a lot with distutils customization. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From Paul.Moore@uk.origin-it.com Fri Mar 30 07:33:01 2001 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Fri Mar 30 07:33:01 2001 Subject: [Distutils] PEP: Use site-packages on all platforms Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5ADD2@ukrux002.rundc.uk.origin-it.com> Attached is a first draft of a proposal to use the "site-packages" directory for locally installed modules, on all platforms instead of just on Unix. If the consensus is that this is a worthwhile proposal, I'll submit it as a formal PEP. Any advice or suggestions welcomed - I've never written a PEP before - I hope I've got the procedure right... Paul Moore PEP: TBA Title: Install local packages in site-packages on all platforms Version $Revision$ Author: Paul Moore Status: Draft Type: Standards Track Python-Version: 2.2 Created: 2001-03-30 Post-History: TBA Abstract The standard Python distribution includes a directory Lib/site-packages, which is used on Unix platforms to hold locally-installed modules and packages. The site.py module distributed with Python includes support for locating modules in this directory. This PEP proposes that the site-packages directory should be used uniformly across all platforms for locally installed modules. Motivation On Windows platforms, the default setting for sys.path does not include a directory suitable for users to install locally-developed modules. The "expected" location appears to be the directory containing the Python executable itself. Including locally developed code in the same directory as installed executables is not good practice. Clearly, users can manipulate sys.path, either in a locally modified site.py, or in a suitable sitecustomize.py, or even via .pth files. However, there should be a standard location for such files, rather than relying on every individual site having to set their own policy. In addition, with distutils becoming more prevalent as a means of distributing modules, the need for a standard install location for distributed modules will become more common. It would be better to define such a standard now, rather than later when more distutils-based packages exist which will need rebuilding. It is relevant to note that prior to Python 2.1, the site-packages directory was not included in sys.path for Macintosh platforms. This has been changed in 2.1, and Macintosh includes sys.path now, leaving Windows as the only major platform with no site-specific modules directory. Implementation The implementation of this feature is fairly trivial. All that would be required is a change to site.py, to change the section setting sitedirs. The Python 2.1 version has if os.sep == '/': sitedirs = [makepath(prefix, "lib", "python" + sys.version[:3], "site-packages"), makepath(prefix, "lib", "site-python")] elif os.sep == ':': sitedirs = [makepath(prefix, "lib", "site-packages")] else: sitedirs = [prefix] A suitable change would be to simply replace the last 4 lines with else: sitedirs = [makepath(prefix, "lib", "site-packages")] Changes would also be required to distutils, in the sysconfig.py file. It is worth noting that this file does not seem to have been updated in line with the change of policy on the Macintosh, as of this writing. Notes 1. It would be better if this change could be included in Python 2.1, as changing something of this nature is better done sooner, rather than later, to reduce the backward-compatibility burden. This is extremely unlikely to happen at this late stage in the release cycle, however. 2. This change does not preclude packages using the current location - the change only adds a directory to sys.path, it does not remove anything. 3. In the Windows distribution of Python 2.1 (beta 1), the Lib\site-packages directory has been removed. It would need to be reinstated. Copyright This document has been placed in the public domain. From thomas.heller@ion-tof.com Fri Mar 30 10:22:41 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Mar 30 10:22:41 2001 Subject: [Distutils] PEP: Use site-packages on all platforms References: <714DFA46B9BBD0119CD000805FC1F53B01B5ADD2@ukrux002.rundc.uk.origin-it.com> Message-ID: <0a0c01c0b92d$078e7f60$e000a8c0@thomasnotebook> It looks good to me. Probably you should also post this to python-dev, since most python core developers don't read c.l.p nor distutils-sig. Thomas From mal@lemburg.com Fri Mar 30 18:08:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Mar 30 18:08:01 2001 Subject: [Distutils] RPMs should include Python version in filename Message-ID: <3AC51188.8F73683B@lemburg.com> The subject says it all... I think that it would be a good idea to add the Python version in the RPM filename much like bdist_wininst does this for Windows, e.g. my-package-1.2.3-1-py1.5.i386.rpm my-package-1.2.3-1-py2.0.i386.rpm my-package-1.2.3-1-py2.1.i386.rpm The reason is simple: the Python API has changed between versions and also the path used by the files inside the packages use the major.minor version number. The same problem most probably also occurrs for bdist_dumb archives and most other binary distribution formats. Thoughts ? -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From robin@alldunn.com Fri Mar 30 18:33:01 2001 From: robin@alldunn.com (Robin Dunn) Date: Fri Mar 30 18:33:01 2001 Subject: [Distutils] RPMs should include Python version in filename References: <3AC51188.8F73683B@lemburg.com> Message-ID: <026001c0b971$90d057f0$0100a8c0@Rogue> > my-package-1.2.3-1-py1.5.i386.rpm > my-package-1.2.3-1-py2.0.i386.rpm > my-package-1.2.3-1-py2.1.i386.rpm > > The reason is simple: the Python API has changed between > versions and also the path used by the files inside the > packages use the major.minor version number. > > The same problem most probably also occurrs for bdist_dumb > archives and most other binary distribution formats. > > Thoughts ? > I agree. I always change the names manually (and can never remember if I used a dot or a dash the last time...) -- Robin Dunn Software Architect Sliceware, Inc. Robin.Dunn@Sliceware.com From s-thapa-11@alumni.uchicago.edu Sat Mar 31 01:13:01 2001 From: s-thapa-11@alumni.uchicago.edu (s-thapa-11@alumni.uchicago.edu) Date: Sat Mar 31 01:13:01 2001 Subject: [Distutils] RPMs should include Python version in filename Message-ID: <20010331002410.B815@hepcat.telocity.com> --5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 31, 2001 at 01:06:48AM +0200, M.-A. Lemburg wrote: > The reason is simple: the Python API has changed between > versions and also the path used by the files inside the > packages use the major.minor version number. >=20 > The same problem most probably also occurrs for bdist_dumb > archives and most other binary distribution formats. >=20 With rpm and probably other package formats like deb, you can have a requires that indicates the version of python needed=20 for installation. E.g. if you place Requires: BeOpen-Python =3D 2.0=20 in the spec file, the resulting rpm won't install on systems=20 without python 2.0 user intervention. Similarly a BuildRequires=20 tag allows for specifying dependencies in the build process although I don't think it is very applicable to bdist. --=20 ------------------------------------------------------------------ Suchandra S. Thapa=20 s-thapa-11@alumni.uchicago.edu ------------------------------------------------------------------ --5/uDoXvLw7AC5HRs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6xXgK0hoo1RInvaIRAkJJAKDJYDgXv2zJplnTT8kk/OaauHlQagCgubQq rPJEEqXBZO8g62HcyxfW4+U= =NXu1 -----END PGP SIGNATURE----- --5/uDoXvLw7AC5HRs-- From robin@jessikat.fsnet.co.uk Sat Mar 31 01:30:00 2001 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Sat Mar 31 01:30:00 2001 Subject: [Distutils] RPMs should include Python version in filename In-Reply-To: <20010331002410.B815@hepcat.telocity.com> References: <20010331002410.B815@hepcat.telocity.com> Message-ID: In article <20010331002410.B815@hepcat.telocity.com>, s-thapa- 11@alumni.uchicago.edu writes ... > With rpm and probably other package formats like deb, you can >have a requires that indicates the version of python needed >for installation. E.g. if you place Requires: BeOpen-Python = 2.0 >in the spec file, the resulting rpm won't install on systems >without python 2.0 user intervention. Similarly a BuildRequires >tag allows for specifying dependencies in the build process although >I don't think it is very applicable to bdist. > I thought a desirable feature of distutils was to break away from the specialised distributions and create an automatic build system. Why do I need an rpm if I can down load and build from source? Is it the manager people who need these labelled lumps? -- Robin Becker From mal@lemburg.com Sat Mar 31 03:48:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat Mar 31 03:48:00 2001 Subject: [Distutils] RPMs should include Python version in filename References: <20010331002410.B815@hepcat.telocity.com> Message-ID: <3AC5998E.371CD53C@lemburg.com> Robin Becker wrote: > > In article <20010331002410.B815@hepcat.telocity.com>, s-thapa- > 11@alumni.uchicago.edu writes > ... > > With rpm and probably other package formats like deb, you can > >have a requires that indicates the version of python needed > >for installation. E.g. if you place Requires: BeOpen-Python = 2.0 > >in the spec file, the resulting rpm won't install on systems > >without python 2.0 user intervention. Similarly a BuildRequires > >tag allows for specifying dependencies in the build process although > >I don't think it is very applicable to bdist. > > > I thought a desirable feature of distutils was to break away from the > specialised distributions and create an automatic build system. Why do I > need an rpm if I can down load and build from source? Is it the manager > people who need these labelled lumps? Today, there are probably more Linux users out there who cannot compile their own code, than ones which do know how this works, either way, we'll have to make binaries available for the sake of customer support. BTW, most downloads go for the binary versions, either the Windows installers or the Linux RPMs. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Mar 31 03:48:04 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat Mar 31 03:48:04 2001 Subject: [Distutils] RPMs should include Python version in filename References: <3AC51188.8F73683B@lemburg.com> <20010331001459.A815@hepcat.telocity.com> <3AC598C7.58DD7470@lemburg.com> Message-ID: <3AC599B6.2F9CC7FC@lemburg.com> s-thapa-11@alumni.uchicago.edu wrote: > > On Sat, Mar 31, 2001 at 01:06:48AM +0200, M.-A. Lemburg wrote: > > The reason is simple: the Python API has changed between > > versions and also the path used by the files inside the > > packages use the major.minor version number. > > > > The same problem most probably also occurrs for bdist_dumb > > archives and most other binary distribution formats. > > > > With rpm and probably other package formats like deb, you can > have a requires that indicates the version of python needed > for installation. E.g. if you place Requires: BeOpen-Python = 2.0 > in the spec file, the resulting rpm won't install on systems > without python 2.0 user intervention. Similarly a BuildRequires > tag allows for specifying dependencies in the build process although > I don't think it is very applicable to bdist. Thanks for the infos. My main certain about the filename is different though: I want people to download the correct version for their system and also need to provide separate files for different Python versions. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From s-thapa-11@alumni.uchicago.edu Sat Mar 31 13:14:01 2001 From: s-thapa-11@alumni.uchicago.edu (s-thapa-11@alumni.uchicago.edu) Date: Sat Mar 31 13:14:01 2001 Subject: [Distutils] RPMs should include Python version in filename In-Reply-To: ; from robin@jessikat.fsnet.co.uk on Sat, Mar 31, 2001 at 07:28:35AM +0100 References: <20010331002410.B815@hepcat.telocity.com> Message-ID: <20010331122458.A1824@hepcat.telocity.com> --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 31, 2001 at 07:28:35AM +0100, Robin Becker wrote: > I thought a desirable feature of distutils was to break away from the > specialised distributions and create an automatic build system. Why do I > need an rpm if I can down load and build from source? Is it the manager > people who need these labelled lumps? Even ignoring those people who don't want to install gcc and development tools, some modules may need new software to be built. For example,=20 I believe PyQT needs SIP. If you already have SWIG installed, I'm not sure whether you want to download and install SIP just to compile PyQT. Similar= ly, people may not want to install bison, yacc, assorted development packages, etc. just to compile a module especially if they won't use them again. --=20 ------------------------------------------------------------------ Suchandra S. Thapa=20 s-thapa-11@alumni.uchicago.edu ------------------------------------------------------------------ --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6xiD50hoo1RInvaIRAoG8AJ4ieHlXAvAIEDgA2ERRiDB3Uo2K9ACeIKwG vVpxYoncVdgMKD7eaE/HVsw= =DgTg -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S--