From david@hotjobs2000.com Tue Nov 9 02:53:52 1999 From: david@hotjobs2000.com (David Winsen) Date: Mon, 8 Nov 1999 18:53:52 -0800 Subject: [Distutils] WEB DATABASE PROGRAMMER POSITION AVAILABLE Message-ID: <000801bf2a5d$aa309920$2a2565d8@pacbell.net> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF2A1A.99CB0A40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 WEB DATABASE PROGRAMMER POSITION AVAILABLE =20 URGENT MESSAGE! =20 From: David Winsen - Senior Consultant - High Technology Executive = Search=20 =20 We have an out-dated copy of your resume in our database or have viewed = your credentials on the internet. HTES is an established national = Executive Search and Consulting Firm who has been serving the High Tech = Industries for over 25 years. =20 =20 We have been confidentially retained by a Los Angeles, Ca. based Adult = Internet Fulfillment/Billing Company. Salary is $50k-$100k DOE.=20 We are confidentially pre-screening top candidates for the following = position: Web Database Programmer Description =20 =20 Candidates will need to be extremely detail oriented and have a = solid work ethic. Will be developing cutting edge software and = e-commerce applications. They are an established and ever growing = Internet Fulfillment/Billing Company. They offer a casual & unique work = environment unlike any other, full benefits, & room for growth and = advancement. =20 =20 =20 =20 Requirements =20 =20 Candidates will need experience in Perl, Python, PHP, Javascript, = UNIX, Linux or FreeBSD, MySQL a plus. BS Computer Science or equivalent. = At least 3 years of Web experience is a plus. =20 =20 If you are interested, please E-mail me in MS Word 95-98 a recent copy = of your resume and a cover letter with your specific information, = including your recent compensation package to Position-for: Web Database = Programmer =20 My personal E-mail is david@hotjobs2000.com or fax your resume to (310) = 855-0840. If you have any questions about the position(s), please call = me at (310) 855-0406 and I will discuss them in detail. =20 We also have developed an interactive Website that you can view over = 6000 national openings www.hotjobs2000.com. This system is effective, = easy to use and new positions are posted daily. We encourage you to use = it and nominate yourself for other positions you feel you are qualified = for. We are looking forward to working with you now and in the future. ------=_NextPart_000_0005_01BF2A1A.99CB0A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

WEB DATABASE PROGRAMMER POSITION AVAILABLE

 

URGENT=20 MESSAGE!

 

From:  David Winsen - Senior = Consultant - High=20 Technology Executive Search

 

We=20 have an out-dated copy of your resume in our database or have viewed = your=20 credentials on the internet.  = HTES=20 is an established national Executive Search and Consulting Firm who has = been=20 serving the High Tech Industries for over 25 years. 

 

We=20 have been confidentially retained by a Los Angeles, Ca. based Adult = Internet=20 Fulfillment/Billing Company. Salary is $50k-$100k DOE. =

We=20 are confidentially pre-screening top candidates for the following = position: Web Database = Programmer

 

 

Description

Candidates=20 will need to be extremely detail oriented and have a solid work = ethic.=20 Will be developing cutting edge software and e-commerce = applications. They=20 are an established and ever growing Internet Fulfillment/Billing = Company.=20 They offer a casual & unique work environment unlike any = other, full=20 benefits, & room for growth and advancement.

Requirements

Candidates=20 will need experience in Perl, Python, PHP, Javascript, UNIX, Linux = or=20 FreeBSD, MySQL a plus. BS Computer Science or equivalent. At least = 3 years=20 of Web experience is a plus.

 

If=20 you are interested, please E-mail me in MS Word 95-98 a recent copy of = your=20 resume and a cover letter with your specific information, including your = recent=20 compensation package to Position-for:=20 Web Database Programmer

 

My=20 personal E-mail is david@hotjobs2000.com=20 or fax your resume to (310) 855-0840. If you have any questions about = the=20 position(s), please call me at (310) 855-0406 and I will discuss them in = detail.

 

We=20 also have developed an interactive Website that you can view over 6000 = national=20 openings www.hotjobs2000.com.  This system is effective, easy = to use=20 and new positions are posted daily. =20 We encourage you to use it and nominate yourself for other = positions you=20 feel you are qualified for.  = We are=20 looking forward to working with you now and in the future.

------=_NextPart_000_0005_01BF2A1A.99CB0A40-- From as544@freenet.toronto.on.ca Sat Nov 27 07:02:18 1999 From: as544@freenet.toronto.on.ca (T-Mithy Myddletin) Date: Sat, 27 Nov 1999 02:02:18 -0500 Subject: [Distutils] Distutils integration Message-ID: <6H4P4gHAAcqH092yn@vex.net> Just to add a second spam to the list for this month, I thought I might drop a (hopefully pertinent) note to let anyone in this SIG who might be interested know that I have tonight added a bunch of new fields to the Vaults of Parnassus database... ( http://www.vex.net/~x/parnassus/ ). One of these is a 'direct download' link. Another is a numberical flag... potentially a "distutil" flag of some sort. I don't know if this is motivation or not, but Vaults of Parnassus is ready (and even eagre) to attempt some sort of integration with Distutils distributions whenever Distutils is ready to be adopted. In time we might even be able to work up a little client of some sort, like Perl has, for easy searching, downloading, and install. I have looked briefly at the distutils package. Pretty complicated stuff. I understand it is intended to be simplified some eventually, when the lower level stuff is sorted out. I hope so. All the complicated stuff is good, but you have to have a REALLY SIMPLE option for people like me with only simple needs to understand too. (-: Anyhow, keep plugging away! -- _____________________________________________________________________ Tim Middleten =-=-with cries among angelic orders-=-= x @ veX . net ~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~"~ * Nov 27th * International Day of Spreads From akuchlin@mems-exchange.org Sat Nov 27 19:07:25 1999 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Sat, 27 Nov 1999 14:07:25 -0500 Subject: [Distutils] Random bits Message-ID: <199911271907.OAA01218@mira.erols.com> Some things I came across while adding distutils support to some code: * From a docstring in distutils/versions.py: 0.4 0.4.0 (these two are equivalent) 0.4.1 Does this mean that 0.4.1 is equivalent to 0.41 in the strict versioning class? I'd suggest adding that, just to make it crystal clear. * The name option in setup.py: It's not clear if it can/should contain spaces; given that you mention underscores, I assume they're as space substitutes. * Building a distribution: it creates hard links to files. This means that if you delete a file and rebuild the dist without erasing the hard-link-filled subdir, the deleted file is still present in the distribution. It's probably easiest to blow away the whole - directory, rather than attempting to scan its contents and update it. -- A.M. Kuchling http://starship.python.net/crew/amk/ "I don't think we should interfere." "Interfere? Of course we should interfere! Always do what you're best at, that's what I say." -- Romana and the Doctor, in "Nightmare of Eden" From mwh21@cam.ac.uk Sun Nov 28 11:01:55 1999 From: mwh21@cam.ac.uk (Michael Hudson) Date: Sun, 28 Nov 1999 11:01:55 +0000 (GMT) Subject: [Distutils] Random bits In-Reply-To: <199911271907.OAA01218@mira.erols.com> Message-ID: Some other thoughts... On Sat, 27 Nov 1999, A.M. Kuchling wrote: [schnipp] > * Building a distribution: it creates hard links to files. > This means that if you delete a file and rebuild the dist without > erasing the hard-link-filled subdir, the deleted file is still present > in the distribution. It's probably easiest to blow away the whole > - directory, rather than attempting to scan its > contents and update it. Yes! I spent a frustrating few minutes trying to work out why files I was trying to exclude from the distribution were turning up in the tarball... Also, excluding files from the dist in general is a pain. I have bytecodehacks in CVS; I don't want to distribute the CVS folders. I found no way to do this except building the MANIFEST file using a shell script (which kind of defeats the point of the manifest, I'd have thought). Also excluding a single file doesn't work. If I want to distribute all files in a directory `bar' except one called, say, `foo', I'd expect to be able to write in the MANIFEST bar !foo but this doesn't work. It doesn't complain, foo is just included in the archive. I'd be happy to beat on these if someone could give me advice where to start. Would a .cvsignore style approach be suitable? Other than these wrinkles distutils is a pleasure to use. Good work! Cheers, Michael From arcege@shore.net Sun Nov 28 14:12:30 1999 From: arcege@shore.net (Michael P. Reilly) Date: Sun, 28 Nov 1999 09:12:30 -0500 (EST) Subject: [Distutils] Random bits In-Reply-To: from Michael Hudson at "Nov 28, 99 11:01:55 am" Message-ID: <199911281412.JAA20195@northshore.shore.net> > On Sat, 27 Nov 1999, A.M. Kuchling wrote: > [schnipp] > > * Building a distribution: it creates hard links to files. > > This means that if you delete a file and rebuild the dist without > > erasing the hard-link-filled subdir, the deleted file is still present > > in the distribution. It's probably easiest to blow away the whole > > - directory, rather than attempting to scan its > > contents and update it. > > Yes! I spent a frustrating few minutes trying to work out why files I was > trying to exclude from the distribution were turning up in the tarball... > > Also, excluding files from the dist in general is a pain. > > I have bytecodehacks in CVS; I don't want to distribute the CVS folders. I > found no way to do this except building the MANIFEST file using a shell > script (which kind of defeats the point of the manifest, I'd have > thought). Try using cvs export (requires a tag, but you should be tagging your code for release anyway). Only the files with the tag will be exported; it is far easier to "remove" files from the release. You can still use the manifest to restrict the files as needed. Also, from a release management point-of-view, you shouldn't be releasing code from your work area. -Arcege -- ------------------------------------------------------------------------ | Michael P. Reilly, Release Engineer | Email: arcege@shore.net | | Salem, Mass. USA 01970 | | ------------------------------------------------------------------------ From gward@cnri.reston.va.us Mon Nov 29 13:57:02 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Mon, 29 Nov 1999 08:57:02 -0500 Subject: [Distutils] Distutils integration In-Reply-To: <6H4P4gHAAcqH092yn@vex.net>; from as544@freenet.toronto.on.ca on Sat, Nov 27, 1999 at 02:02:18AM -0500 References: <6H4P4gHAAcqH092yn@vex.net> Message-ID: <19991129085701.A7807@cnri.reston.va.us> On 27 November 1999, T-Mithy Myddletin said: > I don't know if this is motivation or not, but Vaults of Parnassus is > ready (and even eagre) to attempt some sort of integration with > Distutils distributions whenever Distutils is ready to be adopted. Cool... BUT I worry that having multiple Python archives or meta-archives might be as bad as having none at all. Oh well, that's the mess the Perl world was in five years ago before Jarkko Hietaniemi came along and cooked up CPAN. > I have looked briefly at the distutils package. Pretty complicated > stuff. I understand it is intended to be simplified some eventually, > when the lower level stuff is sorted out. I think this is probably a documentation problem. Yes, the code is fairly complex, but that's because I wanted it to be fairly easy for developers and distributors to use, utterly dead simple for installers to use, and still be extensible. (Plus I have a dangerous tendency towards complex designs... oh well.) Currently, the "documentation" -- that big ugly USAGE file -- is almost as complex as the code, because it was a two-night braindump that I spewed before releasing Distutils 0.1. > I hope so. All the > complicated stuff is good, but you have to have a REALLY SIMPLE option > for people like me with only simple needs to understand too. (-: > > Anyhow, keep plugging away! Sounds like I should start plugging away on the nice documentation that I've been meaning to write for a while. Ummm, bugs first though. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From gward@cnri.reston.va.us Mon Nov 29 14:03:09 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Mon, 29 Nov 1999 09:03:09 -0500 Subject: [Distutils] Random bits In-Reply-To: <199911271907.OAA01218@mira.erols.com>; from amk1@erols.com on Sat, Nov 27, 1999 at 02:07:25PM -0500 References: <199911271907.OAA01218@mira.erols.com> Message-ID: <19991129090309.B7807@cnri.reston.va.us> On 27 November 1999, A.M. Kuchling said: > Some things I came across while adding distutils support to some code: > > * From a docstring in distutils/versions.py: > 0.4 0.4.0 (these two are equivalent) > 0.4.1 > > Does this mean that 0.4.1 is equivalent to 0.41 in the strict > versioning class? I'd suggest adding that, just to make it crystal > clear. That is not currently the case, and I think the "strict" version regex -- as well as the semantics attached to its bits and pieces -- would need some work for that to happen. It seems attractive at first blush, but I'm not entirely sure that it's a good idea. "0.4.1 == 0.41" sort-of implies "1.11 == 1.1.1", which is definitely *not* attractive. ESR's "Software Release Practices HOWTO" argues in favour of major.minor.patch version numbering, and I agree with that. See http://www.linuxdoc.org/HOWTO/Software-Release-Practice-HOWTO-2.html#ss2.1 > * The name option in setup.py: It's not clear if it can/should > contain spaces; given that you mention underscores, I assume they're > as space substitutes. From the USAGE file, line 947 or so: name version: the name and version number of the module distribution. The name should be brief, descriptive, and unique across all Python module distributions. It is used to build filenames and directory names (and, someday, database records, web pages, etc.), so should not contain any punctuation except *possibly* underscores. The version number should be a reasonably normal-looking version number; there are no strict requirements for what a version number should be, but there will someday be guidelines: see distutils/version.py for details. Both of these are required by the 'dist' command. ...which probably just means I need to work on the documentation. > * Building a distribution: it creates hard links to files. > This means that if you delete a file and rebuild the dist without > erasing the hard-link-filled subdir, the deleted file is still present > in the distribution. It's probably easiest to blow away the whole > - directory, rather than attempting to scan its > contents and update it. Yeah, good point. The "dist" command is broken in a number of other stupid ways -- it was a very quick and dirty hack cobbled together so I could say "setup.py dist" to make the Distutils 0.1 release. It works for putting together the Distutils release, but isn't much good for anything else. ;-( See my next post... Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From gward@cnri.reston.va.us Mon Nov 29 14:13:40 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Mon, 29 Nov 1999 09:13:40 -0500 Subject: [Distutils] Random bits In-Reply-To: ; from mwh21@cam.ac.uk on Sun, Nov 28, 1999 at 11:01:55AM +0000 References: <199911271907.OAA01218@mira.erols.com> Message-ID: <19991129091339.C7807@cnri.reston.va.us> On 28 November 1999, Michael Hudson said: > Yes! I spent a frustrating few minutes trying to work out why files I was > trying to exclude from the distribution were turning up in the tarball... Oops, sorry. > Also, excluding files from the dist in general is a pain. > > I have bytecodehacks in CVS; I don't want to distribute the CVS folders. I > found no way to do this except building the MANIFEST file using a shell > script (which kind of defeats the point of the manifest, I'd have > thought). > > Also excluding a single file doesn't work. [...more ranting about what doesn't work in the Distutils MANIFEST file...] Yeah, I've been bitten by a couple of these things myself; others, I haven't seen. As I said in my last post, this was a cobbled-together hack and not-at-all well thought-out. Guess it's time to fix that. What I'm moving towards now is some of the ideas that MAL, Gordan MacMillan, and Fred Drake (anyone else?) were tossing around back in September when I first brought up the MANIFEST thing. In particular: * two-phase manifest; developer writes a MANIFEST.in that is short and simple, something like this (for Distutils itself): USAGE TODO MANIFEST CHANGES examples README *.py (although possibly with a more verbose syntax). Then, at some point the Distutils will process this and output MANIFEST, which is used a) to put together the distribution, b) to allow the developer to peek into the explicit list of files generated, and c) to allow the developer to meddle with the explicit list of files generated. However, this gets complicated when you start thinking about the interactions between MANIFEST.in and MANIFEST. I think there are cases where the module developer will just want to use his own MANIFEST and ignore my MANIFEST.in thing, and there are cases where he'll just want to clobber MANIFEST from MANIFEST.in every time. I started scribbling down some thoughts on this a few weekends ago, but got distracted. * more explicit, clearer syntax Anyways, I'm open to ideas on how best to handle the MANIFEST.in/MANIFEST thing (and syntax for the former). Tell me what features you want, whether you even like the idea of going from a short, simple list of exclude/include patterns to an explicit list of every file, how you would like to use such a system, etc. (My main concern is that we *not* just have a simple MANIFEST file that the developer has to create and maintain; that's how Perl's MakeMaker expects you to work, and it's a PITA. It provides a module to help you generate the MANIFEST the first time, but after that you're pretty much on your own.) Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From akuchlin@mems-exchange.org Mon Nov 29 18:00:01 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Mon, 29 Nov 1999 13:00:01 -0500 (EST) Subject: [Distutils] Random bits In-Reply-To: <19991129090309.B7807@cnri.reston.va.us> References: <199911271907.OAA01218@mira.erols.com> <19991129090309.B7807@cnri.reston.va.us> Message-ID: <14402.48929.684198.689070@amarok.cnri.reston.va.us> Greg Ward writes: >On 27 November 1999, A.M. Kuchling said: >> Does this mean that 0.4.1 is equivalent to 0.41 in the strict >> versioning class? I'd suggest adding that, just to make it crystal >> clear. Sorry, I miswrote; I meant, "if that is the case, the example should be added to the docstring to make it clear." If that's not the case, though, I wasn't suggesting adding it, and agree that the 1.11 == 1.1.1 consequence is unpleasant. >...which probably just means I need to work on the documentation. It would be a good idea to have a brief page or two up top which covers the basics extremely quickly, letting you get started quickly. The Python distrib's README sets a good precedent: If you don't read instructions ------------------------------ Congratulations on getting this far. :-) To start building right away (on UNIX): type "./configure" in the current directory and when it finishes, type "make". The section Build Instructions below is still recommended reading. :-) ... >could say "setup.py dist" to make the Distutils 0.1 release. It works >for putting together the Distutils release, but isn't much good for >anything else. ;-( See my next post... Actually, I thought it worked fine, once I figured out the hard-link thing, and I really liked the ability to write patterns in the MANIFEST. Another thing I thought of: Tools/versioncheck from the Python distrib should be supported in some way. While versioncheck is for checking the versions of installed packages (so it's not obsoleted by the Distutils), it's still worth adding a 'checkversion' command that would simply print out whether a more recent version of the code is available. -- A.M. Kuchling http://starship.python.net/crew/amk/ The age of chivalry is gone. That of sophisters, economists and calculators has succeeded: and the glory of Europe is extinguished for ever. -- Edmund Burke, _Reflections on The Revolution in France_ From akuchlin@mems-exchange.org Mon Nov 29 18:18:07 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Mon, 29 Nov 1999 13:18:07 -0500 (EST) Subject: [Distutils] Distutils integration In-Reply-To: <6H4P4gHAAcqH092yn@vex.net> References: <6H4P4gHAAcqH092yn@vex.net> Message-ID: <14402.50015.140365.985927@amarok.cnri.reston.va.us> T-Mithy Myddletin writes: >might be interested know that I have tonight added a bunch of new >fields to the Vaults of Parnassus database... One field that might be interesting is, for lack of a better name, a 'status' field that said whether a project is maintained or unmaintained. (Maybe Maintained: yes|no ...) Sometimes it's useful to find any code that's helpful, even if no one is keeping it up-to-date; it's a starting point, anyway. >I don't know if this is motivation or not, but Vaults of Parnassus is >ready (and even eagre) to attempt some sort of integration with >Distutils distributions whenever Distutils is ready to be adopted. In >time we might even be able to work up a little client of some sort, >like Perl has, for easy searching, downloading, and install. I think that would be possible without too much difficulty; the major issue, besides user interface, is where to find the latest tarball containing the actual code; Parnassus points to human-readable Web pages, not directly to the .tgz file, and it probably shouldn't have a pointer to it. How does CPAN handle this? Does it list foo-*.tgz and take the one where * is the highest version number? -- A.M. Kuchling http://starship.python.net/crew/amk/ I confidently expect it to be a fairly resounding failure. -- John Cleese, on the Monty Python reunion planned for 1999 From as544@freenet.toronto.on.ca Mon Nov 29 20:14:28 1999 From: as544@freenet.toronto.on.ca (T-Mathy Meddleton) Date: Mon, 29 Nov 1999 15:14:28 -0500 Subject: [Distutils] Distutils integration In-Reply-To: <19991129091339.C7807@cnri.reston.va.us> References: <6H4P4gHAAcqH092yn@vex.net> <14402.50015.140365.985927@amarok.cnri.reston.va.us> Message-ID: On Mon, 29 Nov 1999 at 1:18pm, Andrew M. Kuchling wrote: > One field that might be interesting is, for lack of a better name, a > 'status' field that said whether a project is maintained or > unmaintained. In fact (i'm happy to say) i have exactly such a field. And for lack of a better name, it is called exactly that. (-: It is non-obvious. My approach (though perhaps wrong-headed in some places) has been to omit any unnecessary information from display (a bit of an interface pet peave of mine is "too much cluttering useless information"---so i may err too much in the other direction). Since the status is set by default to "Alive and Well" on nearly all the items in the database i consider the info redundant and it is not printed. However, as soon as the status changes from Alive and Well, it shows up. I should explicitly document this behavior somewhere (at least), and make a display showing all possible fields. You can see this in the "Lost/Broken" category where i've dumped items with broken links... they have a status flag to that respect... on the details for each of them you'll see the "status" item appear... in bright red letters even... (hopefully to attract someone's attention who can fix the link --- have fixed many already --- many that remain broken sadly on python.org --- i should be keeping track and inform them... but it's hard to keep track... i think now though of Lyntin, and X Extensions --- two recent ones that come to mind --- it is heartening at least to see people actively making the effort to use the "report dead link" function on my detail pages.) In fact the flag is an integer and there's about 6 statuses possible at the moment (though i'm wanting to refine this and have modified it a few times already).... (excuse my even worse dictionary name than field name )... generally they go from best to worst condition... statuses = { 0: 'Alive and Well', 1: 'In transition/Will be back', 2: 'No Longer Supported', 3: 'Unknown/Author Disappeared', 5: 'Now in Standard Distribution', 8: 'Unknown/Dead Link', 9: 'Dead and Gone', } The only flag used so far is the "8" ... oh, and the "5" in the single case of the old cPickle module. (And i think i may have accidentally given a 9 flag where i meant 8 in a few cases... as i say, it's in flux and a bit confusing. The above statuses (as now programmed) only show up on the details page when it is non-zero. Not sure how and where to use the rest... but i have created them in the event that one day i get a flash of insight in this direction. The *real* problem is figuring out when the heck something becomes "unmaintained". Not a lot of authors announce that sort of thing. Perhaps there should be a time limit. It could even happen automatically. If there is no update in x months the flag automatically gets bumped to "unmaintained". But then this is probably not accurate either, as sometimes people "maintain" old work for quite a while... just don't actively develop it anymore, so perhaps there should be a distinction there. Of course there is always then just the "last updated" date in my database. I had intended to impleemnt some filters at some point. For example, so epople can, if they want, filter out everything more than a year old, etc. Or more than a week old, if they insist. Heh. I have been thinking about these issues especially lately as I've been working through the /pub/python/contrib directories. I've added (maintaining the file dates as 'last modified') already everything from Database/ and DataStructures/ (which i later noticed was also symlinked to Math/). There is a lot of really, really old junk in there. Though there's also some really, really old nifty neato stuff too. (-: (Some little obscure gems i had not noticed before---just because it's old doesn't necessarily mean it's bad!) But what to do about the old stuff which is obsolete. And i'm especially bothered by the thought of old stuff which is so old that it will not even work with python 1.5x ... i wish i had some way of flagging that... to warn unsuspecting people. On the other hand, there's not *that* much of the old stuff, so perhaps it's not worth worrying about that much at this time. If you know of any Abandoned/Unsupported code, let me know. I'll update the flags ASAP!! (-: > containing the actual code; Parnassus points to human-readable Web > pages, not directly to the .tgz file, and it probably shouldn't have a This has changed. I have added a second field. Now each item has "URL" (intended to point always and only to human readable page---or ftp directory), and also now a "download" field, which is intended to point whenever possible to binary (or raw script) (though only a few dozen items have this so far). So already i have moved, at least a little, in this direction. Again, this is a bit non-obvious to viewers... in that i only print on the details page what is available. If there is no "download" link defined then it simply does not show up, rather than saying "Not Available", or whatever. But if there is a direct download link, it shows up. If you do an URL search for "gz" for example, you'll notice most if not all of them items will have "download" links now. Also the submission form has the added field. > pointer to it. How does CPAN handle this? Does it list foo-*.tgz and > take the one where * is the highest version number? CPAN lists everything last i checked (which was a long time ago!). It's up to the user to decide what version they want (as if anyone doesn't want the latest )... but i'm far from expert (or even slightly knowledgable) on the workings of CPAN. ... From fdrake@acm.org Mon Nov 29 22:20:16 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 29 Nov 1999 17:20:16 -0500 (EST) Subject: [Distutils] Random bits In-Reply-To: <199911281412.JAA20195@northshore.shore.net> References: <199911281412.JAA20195@northshore.shore.net> Message-ID: <14402.64544.975576.792717@weyr.cnri.reston.va.us> Michael P. Reilly writes: > Try using cvs export (requires a tag, but you should be tagging your > code for release anyway). Only the files with the tag will be > exported; it is far easier to "remove" files from the release. You can > still use the manifest to restrict the files as needed. > > Also, from a release management point-of-view, you shouldn't be > releasing code from your work area. Yes, yes, yes! Truer words have never been spoken! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From da@ski.org Mon Nov 29 22:21:48 1999 From: da@ski.org (David Ascher) Date: Mon, 29 Nov 1999 14:21:48 -0800 (Pacific Standard Time) Subject: [Distutils] Random bits In-Reply-To: <14402.64544.975576.792717@weyr.cnri.reston.va.us> Message-ID: On Mon, 29 Nov 1999, Fred L. Drake, Jr. wrote: > Michael P. Reilly writes: > > Try using cvs export (requires a tag, but you should be tagging your > > code for release anyway). Only the files with the tag will be > > exported; it is far easier to "remove" files from the release. You can > > still use the manifest to restrict the files as needed. > > > > Also, from a release management point-of-view, you shouldn't be > > releasing code from your work area. > > Yes, yes, yes! Truer words have never been spoken! Does anyone feel like doing a CVS tutorial BOF at IPC8? I think a lot of us could use some of this wisdom... --david From fdrake@acm.org Mon Nov 29 22:29:01 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 29 Nov 1999 17:29:01 -0500 (EST) Subject: [Distutils] Random bits In-Reply-To: References: <14402.64544.975576.792717@weyr.cnri.reston.va.us> Message-ID: <14402.65069.391958.660211@weyr.cnri.reston.va.us> David Ascher writes: > Does anyone feel like doing a CVS tutorial BOF at IPC8? I think a lot of > us could use some of this wisdom... Er, Barry Warsaw is the CVS guru around here. Barry? ;-) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From as544@freenet.toronto.on.ca Tue Nov 30 03:39:45 1999 From: as544@freenet.toronto.on.ca (T-Methy Moddletin) Date: Mon, 29 Nov 1999 22:39:45 -0500 Subject: [Distutils] Distutils integration In-Reply-To: <19991129085701.A7807@cnri.reston.va.us> References: <6H4P4gHAAcqH092yn@vex.net> <19991129085701.A7807@cnri.reston.va.us> Message-ID: Mon, 29 Nov 1999 08:57:02 -0500, Greg Ward wrote: >Cool... BUT I worry that having multiple Python archives or >meta-archives might be as bad as having none at all. Ouch. (-: Ah well, since this is the state of things, at least we may as well have a way to more conveniently search for what's out there. And of course the thing about "meta-archives" is that the "meta" can represent just about anything. Therefore, if one day someone wants to suddenly start archiving everything on a central server, i can just as easily change all the pointers to there ---- or add extra pointers to there as well as the ones that exist. (Not that necessarily anyone would want me to ). >Oh well, that's the mess the Perl world was in five years ago before >Jarkko Hietaniemi came along and cooked up CPAN. Hmmm, i'm not familiar with pre-CPAN Perl. Perhaps you could enlighten me? What exactly was the nature of the "mess"? Perhaps there are other ways than CPAN to address some of the problems? Non standard packages? (You're taking care of that problem, i hope!) But perhaps non-standard naming as well. Hideously ugly, eyeball splitting web page colours and designs? (even more eyeball splitting than perl code itself?! ). Broken links? (This last thing I have found already to be a perpetual problem. Even though I have tested most of the links I have added to my database, which is mostly less than two months old... already broken link reports stream in! It has me thinking of cooking up a link checker to periodicially go and automatically check links (python sure makes things like this easy to do!)... and perhaps (oh what devil put this idea in my fevered brain!) even after a certain period of brokenness generate an automated SPAM message informing the resource owner of my consternation! No mercy for people who leave broken links! Or at least sweap the database and segregate and flag broken links to make things less frustrating for hapless browsers who wander by. At least if the database became more known and used, authors may be more contientious about keeping their links up to date---this does not mention the pool of helpful users who may be able to assist in tracking down the lost gems... already in one case, at least, a helpful visitor has fixed one of the links in the 'lost/broken' directory.) No, in my opinion (which may not be worth much) there is one thing at least worse than having a meta-archive... and that's having ftp.python.org/pub/python/contrib/ ! No offense ment to anyone! But that place has become a terrible mess. And i hate README files! We might also recognise our potential different focuses. I presume your thinking resolves from your project of "packaging" and "distributing" (a.k.a. Social Engineering, as you say!)---where naturally a more controlled central archive would be the ideal. My perspective is generated less from caring what the actual resource is, or how to access it, acquire it, build it, and install it, but simply to find the damned thing in the first place! (-: Of course if there was a central archive, that takes care of finding things as well (assuming everyone wants to bother with going to the trouble of getting archived there). Still I must dissent. In retrospect, I am not fond of CPAN. I do not miss it. I do not consider it a model for emulation. It had perhaps some useful attributes----but I am (and hopefully I don't just say this because it is the nature of my-project-which-i-must-protect) genuinely in favour of decentralised resources. I think it's more encouraging to people to directly and easily control and release their stuff (and for those who want to upload somewhere there is still ftp.python.org!) While there are certain weaknesses and logistic complications (and yeah, perhaps "mess" also!) it seems a much freer environment to me. Less stuffy, as it were. Less official! Perhaps my biases are showing a little too strongly. I find the rigidity of CPAN just a little too intimidating, in fact. Let me put it another way which may ultimately damn me (if i haven't been damned already): CPAN to me FEELS a little too much like EMACs. (-: Yes, EMACs is a fine tool, and i've often wished i could figure the damned thing out! Many people use it to good (yeah, i concede perhaps even superior) advantage. But for many of us, we just find it continually baffling, bogglingly complicated, requiring too much. Nay, i fly back to VIM which is as far as i go. Likewise i fly from CPAN to a Vaults of Parnassus like place with pleasure. Others may disagree. It must be admitted also that I am not a professional (or even schooled in any way) programmer---there may be elements to these things I do not understand. I should be more ashamed of my ignorance than I am, except if nothing else perhaps I can represent the "unwashed masses" of pythong programers... under the banner of Guido's wonderful (even if a little grandiose) "Programming for Everyone" essay! As long as Guido clings to this crazy utopian ideal, you'll have to put up with amateurs like myself. (-: I have never used as CSV in my live-long life. And it probably shows. (-: I see all the strange $ codes in people's source and i think: wow, that looks impressively obscure and archane, someday i'll have to figure that out! However, i'm open to all these ideas. I have nothing intrinsically against a central archive, and would certainly welcome it (and happily index it---for myself, if no one else) --- let me know when you open one. (-: Already i note these quibles in the last few messages about version number parsing. When creating the Vaults of Parnassus database I had considered whether to have a seperate version field. I finally decided against it. It seemed to me a needless complication. Also i feared any benefits from it would be lost by non-standard version numbering systems.... and betas, and alphas, and everything else. So i just kept a plain title field, where the version number is tacked on the end of the string, as one sees printed. Now reading the discussion here I am thinking perhaps a seperate version field is useful after all.... i had not thought of it from the perspective of standardisted distributions and specific version querying. Perhaps if I used CSVs i'd be more aware of these issues. (-: But still for my purpose I think i can get away with no seperate version field. If it comes down to it, if necessary, I could always do a search for the software name, and parse out the version from the end of the title. But it's interesting to think about. >I think this is probably a documentation problem. Yes, the code is >fairly complex, but that's because I wanted it to be fairly easy for Yes, as mentioned above, you have many concerns that probably go far beyond my wildest needs or imaginations. I in no way mean to bash the complexity; but only also to weakly plead for a little more attention to the simplicity side as well. Thanks for your thoughts. We shall see what happens. Sorry to ramble so much! -- .._,.,._.,.,.,_,._,,,.,_,.,_,..,..,_..,.,.,_,,.,.,_._.,_.,.._,.,_..,. Tim Middleton =-=-= not all who wander are lost =-=-= x @ veX . net ~`~`~'~`~`~'~`~`~'~`~`~'~`~`~'~`~`~'~`~'~'~`~'~'~`~'~'~`~'~'~`~'~'~`~ From gstein@lyra.org Tue Nov 30 07:46:22 1999 From: gstein@lyra.org (Greg Stein) Date: Mon, 29 Nov 1999 23:46:22 -0800 (PST) Subject: [Distutils] Distutils integration In-Reply-To: Message-ID: On Mon, 29 Nov 1999, T-Methy Moddletin wrote: > Mon, 29 Nov 1999 08:57:02 -0500, Greg Ward wrote: > >Cool... BUT I worry that having multiple Python archives or > >meta-archives might be as bad as having none at all. > > Ouch. (-: Ah well, since this is the state of things, at least we > may as well have a way to more conveniently search for what's out > there. Don't let Greg dissuade you. In almost all cases, something is better than nothing. The current state of a Python archive (or index) is pretty abysmal. Keep doing what you're doing! Don't stop! :-) >... > No, in my opinion (which may not be worth much) there is one thing at > least worse than having a meta-archive... and that's having > ftp.python.org/pub/python/contrib/ ! No offense ment to anyone! But > that place has become a terrible mess. And i hate README files! I'll second your opinion. It has been a LONG time since I bothered to look in there. I go to the web now for Python code. >... > Of course if there was a central archive, that takes care of finding > things as well (assuming everyone wants to bother with going to the > trouble of getting archived there). Still I must dissent. In > retrospect, I am not fond of CPAN. I do not miss it. I do not consider > it a model for emulation. It had perhaps some useful attributes----but > I am (and hopefully I don't just say this because it is the nature of > my-project-which-i-must-protect) genuinely in favour of > decentralised resources. I think it's more encouraging to people to > directly and easily control and release their stuff (and for those > who want to upload somewhere there is still ftp.python.org!) While > there are certain weaknesses and logistic complications (and yeah, > perhaps "mess" also!) it seems a much freer environment to me. Less > stuffy, as it were. Less official! Perhaps my biases are showing a > little too strongly. I find the rigidity of CPAN just a little too > intimidating, in fact. I argued the same topic (different approach, tho) on the trove-dev mailing list (archives at www.python.org/pipermail/trove-dev). Basically, I believe the current Internet user is looking for a Freshmeat-style index, rather than a sunsite-style repository. Repositories are passe, indexes are The Right And Just Way. :-) Anybody can get a web page and some disk space. Therefore, anybody can publish their code themselves -- there is no need for central repositories except to help out lazy people that won't publish thru a web page. (alright, maybe that's too strong, but I'm making a point here :-) The problem, of course, is finding all this stuff. IMO, you ought to look harder at the Freshmeat style of index. More of the work is pushed onto the author, rather than the site maintainer. The editors review each announcement or edit, but I don't think they personally clean up the database. (yes, I realize some of your efforts are due to "startup" rather than a plan to do ongoing maintenance) >... > Already i note these quibles in the last few messages about version > number parsing. When creating the Vaults of Parnassus database I had I posted a little version number parser about a year ago, I think. It handles most forms of version numbers, returning a tuple that can be properly ordered (among the software's other releases using that version number pattern). If you need to parse version numbers, that's the function to use. Cheers, -g -- Greg Stein, http://www.lyra.org/ From arcege@shore.net Tue Nov 30 14:01:49 1999 From: arcege@shore.net (Michael P. Reilly) Date: Tue, 30 Nov 1999 09:01:49 -0500 (EST) Subject: [Distutils] Random bits In-Reply-To: from David Ascher at "Nov 29, 99 02:21:48 pm" Message-ID: <199911301401.JAA01751@northshore.shore.net> > Does anyone feel like doing a CVS tutorial BOF at IPC8? I think a lot of > us could use some of this wisdom... > > --david A number of us were talking with publishers in Monterrey about them putting out a CVS book. I've had a number of ppl asking me if there was anything more than the texinfo files. Beyond that, a CVS BOF would probably be useful. I'm still trying to make it to IPC8. -Arcege PS: This discussion _might_ be a little off-topic. ;) -- ------------------------------------------------------------------------ | Michael P. Reilly, Release Engineer | Email: arcege@shore.net | | Salem, Mass. USA 01970 | | ------------------------------------------------------------------------ From m.faassen@vet.uu.nl Tue Nov 30 14:26:50 1999 From: m.faassen@vet.uu.nl (Martijn Faassen) Date: Tue, 30 Nov 1999 15:26:50 +0100 Subject: [Distutils] Distutils integration References: <6H4P4gHAAcqH092yn@vex.net> <19991129085701.A7807@cnri.reston.va.us> Message-ID: <3843DEAA.D39CB91A@vet.uu.nl> Greg Ward wrote: > > On 27 November 1999, T-Mithy Myddletin said: > > I don't know if this is motivation or not, but Vaults of Parnassus is > > ready (and even eagre) to attempt some sort of integration with > > Distutils distributions whenever Distutils is ready to be adopted. > > Cool... BUT I worry that having multiple Python archives or > meta-archives might be as bad as having none at all. Oh well, that's > the mess the Perl world was in five years ago before Jarkko Hietaniemi > came along and cooked up CPAN. The Vaults have been received quite happily by the Python community; I think there's a good chance they *will* be the standard archives for Python, from what I've seen so far. Cooperation of Distutils with the Vaults therefore seems like a good idea to me. This is why I suggested it in the first place.. :) Regards, Martijn From ians@amc.com Tue Nov 30 15:23:33 1999 From: ians@amc.com (Ian Searle) Date: Tue, 30 Nov 1999 07:23:33 -0800 Subject: [Distutils] Questions about distutils strategy References: <19991129222517.2670B1CE42@dinsdale.python.org> Message-ID: <3843EBF5.8FD2169B@amc.com> We are developing a cross platform debug tool for embedded systems that uses Python as the central foundation. We distribute our product on both solaris and windows nt. Thus, distutils looked attractive for building our python extensions, which are mostly C++. This last weekend, I was working on an extension, and ended up punting distutils for two reasons: 1) the documentation is not adequate for a moron like me. I needed to add a vendor supplied object file to the link command, and struck out on every attempt. The doc gave me some clues, but was not specific enough to really help. I realize that this is version 0.1. 2) the main/compelling reason is that I have to debug the python extensions. The extension implementation is normally tested, and debugged prior to integration into Python. But the extension layer often needs some debugging as we are interfacing C++ with STL containers to Python data types. I can debug just fine using distutils on Solaris/Linux, but cannot do the same on Windows. As far as I can tell, you _have_ to have a DevStudio project setup to debug anything under windows. Since our product will be delivered as a standalone tool, including python, I do not need the distribution facilities of distutils, only the development. But, once I have developed a DevStudio project/workspace for an extension, there is little motivation to use distutils. I am hopeful that distutils will evolve into a useful development and distribution tool for python. Though, I wonder how the "debugging extensions on Windows" problem will be approached. Cheers, -Ian Searle From fdrake@acm.org Tue Nov 30 17:40:19 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 30 Nov 1999 12:40:19 -0500 (EST) Subject: [Distutils] Random bits In-Reply-To: <199911301401.JAA01751@northshore.shore.net> References: <199911301401.JAA01751@northshore.shore.net> Message-ID: <14404.3075.158121.848378@weyr.cnri.reston.va.us> Michael P. Reilly writes: > A number of us were talking with publishers in Monterrey about them > putting out a CVS book. I've had a number of ppl asking me if there > was anything more than the texinfo files. Actually, there is a CVS book now. Search for "CVS" at amazon.com in the computer section, or at your favorite bookseller. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives