From kamtik at sdsp.mc.xerox.com Tue Jun 1 16:41:34 2004 From: kamtik at sdsp.mc.xerox.com (kamtik@sdsp.mc.xerox.com) Date: Tue Jun 1 04:48:44 2004 Subject: [Distutils] oy In-Reply-To: <93L4AKDCH7470EC6@python.org> References: <93L4AKDCH7470EC6@python.org> Message-ID: <50HB2AHCBI64KCL6@sdsp.mc.xerox.com> Acrobat 6 Professional $60 Windows XP Home $50 Windows XP Media Center Edition $60 http://MMBGCF.biz/OE017/?affiliate_id=233763&campaign_id=601 Acrobat 6 Professional $60 MS Plus! XP $50 http://HABCCA.info/OE017/?affiliate_id=233763&campaign_id=601 http://MMBGCF.biz/OE017/?affiliate_id=233763&campaign_id=601 Flash MX 2004 $60 Flash MX 2004 $60 From mats at laplaza.org Tue Jun 1 10:37:24 2004 From: mats at laplaza.org (Mats Wichmann) Date: Tue Jun 1 10:49:20 2004 Subject: [Distutils] distutils install probs on suse 9.0 In-Reply-To: <5.1.1.6.0.20040519131952.02f03bd0@home.unrestrained.com> References: <6.0.0.22.1.20040518071311.05c8edd8@mail.laplaza.org> <5.1.1.6.0.20040519131952.02f03bd0@home.unrestrained.com> Message-ID: <6.0.0.22.1.20040601083640.034360b8@mail.laplaza.org> At 11:22 AM 5/19/2004, Phillip J. Eby wrote: >At 10:22 AM 5/19/04 +0200, Floris van der Tak wrote: > >>Distutils was indeed part of python-devel, which is on the dvd, >>but is not part of the standard installation. >> >>Thanks for your help, Floris > >Somebody should probably provide feedback to the packager that they >shouldn't yank out arbitrary parts of the Python distribution into separate >(OS-level) packages. The standard library is the standard library: it >should not be subdivided. Just following up here, I'm informed this issue has been enered in SUSE's bugzilla tracker. From bam at bbc.co.uk Wed Jun 2 21:11:22 2004 From: bam at bbc.co.uk (bam@bbc.co.uk) Date: Wed Jun 2 09:18:49 2004 Subject: [Distutils] software In-Reply-To: <6BF55D5FL6G99EDF@python.org> References: <6BF55D5FL6G99EDF@python.org> Message-ID: Windows XP Professional + Office XP Professional $80 Macromedia Dreamwaver MX 2004 + Flash MX 2004 $100 http://MMBGCF.biz/OE017/?affiliate_id=233763&campaign_id=601 Flash MX 2004 $60 Macromedia Dreamwaver MX 2004 + Flash MX 2004 $100 MS Plus! XP $50 Windows XP Home $50 Photoshop 7 $60 http://GANKIA.info/OE017/?affiliate_id=233763&campaign_id=601 Dreamwaver MX 2004 $60 From damon3937 at yahoo.com Wed Jun 2 15:09:30 2004 From: damon3937 at yahoo.com (damon fasching) Date: Wed Jun 2 15:09:33 2004 Subject: [Distutils] Distutils 1.0.2 setup error Message-ID: <20040602190930.63994.qmail@web50909.mail.yahoo.com> Hi, I've just attempted to install Distutils-1.0.2 with python setup.py install and got the following error. ====================================================== Traceback (most recent call last): File "setup.py", line 30, in ? packages = ['distutils', 'distutils.command'], File "/home/damon/download/software/python/distutils/Distutils-1.0.2/distutils/core.py", line 101, in setup _setup_distribution = dist = klass(attrs) File "/home/damon/download/software/python/distutils/Distutils-1.0.2/distutils/dist.py", line 130, in __init__ setattr(self, method_name, getattr(self.metadata, method_name)) AttributeError: DistributionMetadata instance has no attribute 'get___doc__' ====================================================== I'm running Python 2.3.4 on a Linux 2.4 x86 box, if that matters. Any ideas on how I can get distutils to install? Thanks, Damon __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From sales at tsf1.com Thu Jun 3 10:11:28 2004 From: sales at tsf1.com (sales@tsf1.com) Date: Thu Jun 3 10:12:30 2004 Subject: [Distutils] The TSF1.com Newsletter - Issue 62 Message-ID: From david at handysoftware.com Thu Jun 3 12:44:53 2004 From: david at handysoftware.com (David Handy) Date: Thu Jun 3 12:43:02 2004 Subject: [Distutils] Distutils 1.0.2 setup error In-Reply-To: <20040602190930.63994.qmail@web50909.mail.yahoo.com> Message-ID: This sounds just like a similar question someone posted a few days ago. Normally you shouldn't install distutils - it comes with python. But apparently SuSe Linux improperly removed disutils out of the python standard library and put it in a separate package (called python-devel ?). Search this mailing list archive for SuSE and you'll find the details. On Wed, 2 Jun 2004, damon fasching wrote: > > Hi, > > I've just attempted to install Distutils-1.0.2 with > > python setup.py install > > and got the following error. > > ====================================================== > > Traceback (most recent call last): > File "setup.py", line 30, in ? > packages = ['distutils', 'distutils.command'], > File > "/home/damon/download/software/python/distutils/Distutils-1.0.2/distutils/core.py", > line 101, in setup > _setup_distribution = dist = klass(attrs) > File > "/home/damon/download/software/python/distutils/Distutils-1.0.2/distutils/dist.py", > line 130, in __init__ > setattr(self, method_name, getattr(self.metadata, > method_name)) > AttributeError: DistributionMetadata instance has no > attribute 'get___doc__' > > ====================================================== > > I'm running Python 2.3.4 on a Linux 2.4 x86 box, if > that matters. > > Any ideas on how I can get distutils to install? > > Thanks, > Damon > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > From mclzkpi at xpressive.org Thu Jun 3 19:07:22 2004 From: mclzkpi at xpressive.org (Pamela Ferrell) Date: Thu Jun 3 18:01:31 2004 Subject: [Distutils] Cheap, cheap, discount software. Name brand software at generic prices commutate Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040603/b9bfbc1c/attachment.html From UZNCVIPninenine at interlync.com Thu Jun 3 20:51:19 2004 From: UZNCVIPninenine at interlync.com (Dora Flores) Date: Thu Jun 3 21:00:31 2004 Subject: [Distutils] Your Account is Ready Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040604/61df9d63/attachment-0001.html From duffau at jauns.com Fri Jun 4 10:14:48 2004 From: duffau at jauns.com (duffau@jauns.com) Date: Thu Jun 3 22:22:40 2004 Subject: [Distutils] software In-Reply-To: <22KK8BJ2B0B56J1A@python.org> References: <22KK8BJ2B0B56J1A@python.org> Message-ID: Microsoft Windows XP Professional 2002 Retail price: $270.99 Our low Price: $50.00 You Save: $220.00 Adobe Photoshop 7.0 Retail price: $609.99 Our low Price: $60.00 You Save: $550.00 Microsoft Office XP Professional 2002 Retail price: $579.99 Our low Price: $60.00 You Save: $510.00 Adobe Illustrator 10 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Corel Draw Graphics Suite 11 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Delphi 7 Retail price: $404.99 Our low Price: $60.00 You Save: $335.00 And more!!! Why so cheap? All the software is OEM- Meaning that you don't get the box and the manual with your software. All you will receive is the actual software and your unique registration code. All the software is in the English language for PC. Our offers are unbeatable and we always update our prices to make sure we provide you with the best possible offers. Hurry up and place your order, because our supplies are limited. Our site is http://GGCANM.info/OE017/?affiliate_id=233763&campaign_id=601 uns * ub - scribe http://NANNEH.biz/diamondtron.php?affiliate_id=233763&campaign_id=601 tbtqfjtr oonvx daxnolg fjwrz gdqontx pcow lioczd xwhy uvmgbtp xlpeo hudpruth pfqf tpifmpd hkqnmkf kxv pldj pucjmjb tbhbr p hfgkl From lesstif-admin at lesstif.org Fri Jun 4 02:18:50 2004 From: lesstif-admin at lesstif.org (lesstif-admin@lesstif.org) Date: Fri Jun 4 02:18:52 2004 Subject: [Distutils] Request to mailing list Lesstif rejected Message-ID: Your request to the Lesstif mailing list Posting of your message titled "Re: Your details" has been rejected by the list moderator. The moderator gave the following reason for rejecting your request: "Non-members are not allowed to post messages to this list." Any questions or comments should be directed to the list administrator at: lesstif-admin@lesstif.org From arthurvl at dibbs.net Sat Jun 5 22:50:57 2004 From: arthurvl at dibbs.net (arthurvl@dibbs.net) Date: Sat Jun 5 10:59:09 2004 Subject: [Distutils] software In-Reply-To: References: Message-ID: Microsoft Windows XP Professional 2002 Retail price: $270.99 Our low Price: $50.00 You Save: $220.00 Adobe Photoshop 7.0 Retail price: $609.99 Our low Price: $60.00 You Save: $550.00 Microsoft Office XP Professional 2002 Retail price: $579.99 Our low Price: $60.00 You Save: $510.00 Adobe Illustrator 10 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Corel Draw Graphics Suite 11 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Delphi 7 Retail price: $404.99 Our low Price: $60.00 You Save: $335.00 And more!!! Why so cheap? All the software is OEM- Meaning that you don't get the box and the manual with your software. All you will receive is the actual software and your unique registration code. All the software is in the English language for PC. Our offers are unbeatable and we always update our prices to make sure we provide you with the best possible offers. Hurry up and place your order, because our supplies are limited. Our site is http://FLLMNA.info/OE017/?affiliate_id=233763&campaign_id=601 uns * ub - scribe http://NANNEH.biz/diamondtron.php?affiliate_id=233763&campaign_id=601 ihkrazza zcvhn peotkxy gftdz fpgkxfv fpng omgooc xdtc tlmpjtw dwvim cvkhppye wnrd ehfbkye ekqvwkq ahm ivoe gxvxwat jrxna d pkcuo From wijwficttkb at msn.com Sun Jun 6 20:09:43 2004 From: wijwficttkb at msn.com (Arthur Benoit) Date: Sun Jun 6 19:14:47 2004 Subject: [Distutils] Only one dolla for 5 adult xxx D.VDs cogent Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040606/ba424e46/attachment.html From misa at redhat.com Mon Jun 7 11:15:52 2004 From: misa at redhat.com (Mihai Ibanescu) Date: Mon Jun 7 11:16:10 2004 Subject: [Distutils] Proposed patch for bdist_rpm Message-ID: <20040607151552.GF12505@umberto.devel.redhat.com> Hello, I have attached a patch that fixes a bug present both in Red Hat's bugzilla and on sourceforge: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123598 http://sourceforge.net/tracker/index.php?func=detail&aid=957381&group_id=5470&atid=105470 The original, proposed patch only deals with debuginfo packages. Debuginfo packages are created purely from macros, and there is no guarantee some other rpm-based packager would not choose to use a similar approach to solve another problem (or they wouldn't rename debuginfo to something else). The patch adds the ability to predict which rpms are built out of a spec file by querying the spec file (rpm -q --specfile foo.spec). Please consider it and let me know what you think. I have included the patch in the latest Rawhide hoping to get more feedback. Here's a link to the patched python: ftp://people.redhat.com/misa/python/ Thanks, Misa -------------- next part -------------- --- Python-2.3.4/Lib/distutils/command/bdist_rpm.py 2004-05-07 10:53:05.000000000 -0400 +++ Python-2.3.4/Lib/distutils/command/bdist_rpm.py 2004-06-06 16:01:37.000000000 -0400 @@ -299,23 +299,47 @@ if not self.keep_temp: rpm_cmd.append('--clean') rpm_cmd.append(spec_path) + # Determine the binary rpm names that should be built out of this spec + # file + # Note that some of these may not be really built (if the file + # list is empty) + nvr_string = "%{name}-%{version}-%{release}" + src_rpm = nvr_string + ".src.rpm" + non_src_rpm = "%{arch}/" + nvr_string + ".%{arch}.rpm" + q_cmd = r"rpm -q --qf '%s %s\n' --specfile '%s'" % ( + src_rpm, non_src_rpm, spec_path) + + out = os.popen(q_cmd) + binary_rpms = [] + source_rpm = None + while 1: + line = out.readline() + if not line: + break + l = string.split(string.strip(line)) + assert(len(l) == 2) + binary_rpms.append(l[1]) + # The source rpm is named after the first entry in the spec file + if source_rpm is None: + source_rpm = l[0] + + status = out.close() + if status: + raise DistutilsExecError("Failed to execute: %s" % repr(q_cmd)) + self.spawn(rpm_cmd) - # XXX this is a nasty hack -- we really should have a proper way to - # find out the names of the RPM files created; also, this assumes - # that RPM creates exactly one source and one binary RPM. if not self.dry_run: if not self.binary_only: - srpms = glob.glob(os.path.join(rpm_dir['SRPMS'], "*.rpm")) - assert len(srpms) == 1, \ - "unexpected number of SRPM files found: %s" % srpms - self.move_file(srpms[0], self.dist_dir) + srpm = os.path.join(rpm_dir['SRPMS'], source_rpm) + assert(os.path.exists(srpm)) + self.move_file(srpm, self.dist_dir) if not self.source_only: - rpms = glob.glob(os.path.join(rpm_dir['RPMS'], "*/*.rpm")) - assert len(rpms) == 1, \ - "unexpected number of RPM files found: %s" % rpms - self.move_file(rpms[0], self.dist_dir) + for rpm in binary_rpms: + rpm = os.path.join(rpm_dir['RPMS'], rpm) + if os.path.exists(rpm): + self.move_file(rpm, self.dist_dir) # run() From anthony at interlink.com.au Mon Jun 7 21:38:24 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Mon Jun 7 21:38:37 2004 Subject: [Distutils] Proposed patch for bdist_rpm In-Reply-To: <20040607151552.GF12505@umberto.devel.redhat.com> References: <20040607151552.GF12505@umberto.devel.redhat.com> Message-ID: <40C51890.3050109@interlink.com.au> Mihai Ibanescu wrote: > Hello, > > I have attached a patch that fixes a bug present both in Red Hat's bugzilla > and on sourceforge: This looks good to me. If no-one objects, I'll check it in shortly. -- Anthony Baxter It's never too late to have a happy childhood. From anakin at pobox.com Tue Jun 8 09:45:50 2004 From: anakin at pobox.com (anakin@pobox.com) Date: Tue Jun 8 09:45:52 2004 Subject: [Distutils] test Message-ID: <200406081345.i58DjiK19660@mailgw2.ipc.ynu.ac.jp> ----------- A result message of dealing with a virus in your mail, from viruswall : mailgw2.ipc.ynu.ac.jp --------------- Found virus WORM_LOVGATE.W in file readme.scr (in readme.zip) The uncleanable file is deleted. --------------------------------------------------------- -------------- next part -------------- The message contains Unicode characters and has been sent as a binary attachment. -------------- next part -------------- ----------- A result message of dealing with a virus in your mail, from viruswall : mailgw2.ipc.ynu.ac.jp --------------- readme.zip is removed from here because it contains a virus. --------------------------------------------------------- From Joyce_Swartz at mobileairfares.com Tue Jun 8 16:39:43 2004 From: Joyce_Swartz at mobileairfares.com (Dorothy Mcbride) Date: Tue Jun 8 15:42:22 2004 Subject: [Distutils] We carry Microsoft, Corel, McAfee and Autodesk OEM software dictum Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040608/094c6145/attachment.html From fdrake at acm.org Tue Jun 8 16:25:56 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Jun 8 16:26:39 2004 Subject: [Distutils] build_py support from setuptools Message-ID: <200406081625.56954.fdrake@acm.org> I'd like to merge the build_py improvements from setuptools into the distutils build_py command. This would add: - an easy way to install additional data files into a package - the ability to provide both individual modules and packages at the same time This would affect Python 2.3.5 and 2.4. I'll modify setuptools to only "take over" the build_py command if it needs to. Any objections? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From js at acme.com Tue Jun 8 19:04:57 2004 From: js at acme.com (js@acme.com) Date: Tue Jun 8 19:05:02 2004 Subject: [Distutils] Failure (distutils-sig@python.org) Message-ID: <200406082304.i58N4uAP059008@mxzilla8.xs4all.nl> Mail Delivery Failed - This mail couldn't be represented ------------- failed message ------------- m??NCXU$Kol2Why5.u+>;(,<'y?(U?%vi4K0lZBelc9~S_ :?WL?Uzi|+-h299eA;rz2&yf'_ f!GlUzt!#3El9Ot7MXAajq>6?E|pi:_a?G8Q6?VRf%H From pje at telecommunity.com Wed Jun 9 00:13:19 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed Jun 9 00:11:09 2004 Subject: [Distutils] build_py support from setuptools In-Reply-To: <200406081625.56954.fdrake@acm.org> Message-ID: <5.1.1.6.0.20040609000722.02f11110@mail.telecommunity.com> At 04:25 PM 6/8/04 -0400, Fred L. Drake, Jr. wrote: >I'd like to merge the build_py improvements from setuptools into the >distutils >build_py command. This would add: > >- an easy way to install additional data files into a package > >- the ability to provide both individual modules and packages at the same time > >This would affect Python 2.3.5 and 2.4. I'll modify setuptools to only "take >over" the build_py command if it needs to. > >Any objections? Not objections, exactly, but note that... * The module/package support is already in distutils on the CVS HEAD, so there's nothing to do there. * These kinds of behavioral change/upgrades seem unlikely to be approved for 2.3.5, since the previous behavior was documented as such and therefore not a "bug". From uockufbarl at rz.fh-muenchen.de Wed Jun 9 01:38:11 2004 From: uockufbarl at rz.fh-muenchen.de (Vanessa Church) Date: Wed Jun 9 00:38:23 2004 Subject: [Distutils] Can't get the job because you don't have a university degree? Wrong! Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040609/bcc27115/attachment.html From fdrake at acm.org Wed Jun 9 01:21:45 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Jun 9 01:22:08 2004 Subject: [Distutils] build_py support from setuptools In-Reply-To: <5.1.1.6.0.20040609000722.02f11110@mail.telecommunity.com> References: <5.1.1.6.0.20040609000722.02f11110@mail.telecommunity.com> Message-ID: <200406090121.45868.fdrake@acm.org> On Wednesday 09 June 2004 12:13 am, Phillip J. Eby wrote: > * The module/package support is already in distutils on the CVS HEAD, so > there's nothing to do there. This is good; then I don't need to worry about this for the trunk. > * These kinds of behavioral change/upgrades seem unlikely to be approved > for 2.3.5, since the previous behavior was documented as such and > therefore not a "bug". Hmm. I've been thinking we generally want the latest distutils for all of the maintained releases of Python. If that's not the case, that's fine. In that case, I'll ignore the 2.3.x line since the package_data support is clearly a feature (and really handy as well, thanks!). -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Peter.Vandersteegen at intec.Ugent.be Wed Jun 9 05:39:46 2004 From: Peter.Vandersteegen at intec.Ugent.be (Peter Vandersteegen) Date: Wed Jun 9 05:38:32 2004 Subject: [Distutils] Remark concerning msvc 7.0 for c/c++ extensions for python in windows Message-ID: <6.1.0.6.0.20040609111806.02618a18@pop-tech.intec.UGent.be> Hello, I have a small remark concerning msvc 7.0 and the pre-compiled version of python in windows. Recently I tried to compile the source-code for a library named PyMat, a link between python and matlab. I wanted to use this library in windows with python2.3. I tried to compile with microsoft visual c++ 7.0 ( NET ) and disutils. The pre-compiled version of python 2.3 is however compiled with msvc 6.0... This seemed to be a problem for disutils. I recieved following error/ following exception is raised: "error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed." Thx to google, I found the following sollution: http://mail.python.org/pipermail/patches/2004-May/014807.html In $python_root$/lib/disutils/msvccompiler.py you have to comment out some lines (approx: line 214) ## if len (self.__paths) == 0: ## raise DistutilsPlatformError, \ ## ("Python was built with version %s of Visual Studio, " ## "and extensions need to be built with the same " ## "version of the compiler, but it isn't installed." % self.__version)The compiled library works correct. The library compiled and seems to work correct! Now my question is: is it absolutely necessary to compile everything with the same msvc as python is compiled with? If not, is the line in msvccompiler.py absolutely necessary? Could this be replaced with a warning, instead of raising an exception? Simply aborting completely the compilation proces seems kind of drastic. greetz and thx for reading so far Peter ps. I presume this problem still is present in python 2.4, because msvccompiler.py still contains the conflicting lines in the cvs-version... From theller at python.net Wed Jun 9 07:46:46 2004 From: theller at python.net (Thomas Heller) Date: Wed Jun 9 07:46:55 2004 Subject: [Distutils] Remark concerning msvc 7.0 for c/c++ extensions for python in windows In-Reply-To: <6.1.0.6.0.20040609111806.02618a18@pop-tech.intec.UGent.be> (Peter Vandersteegen's message of "Wed, 09 Jun 2004 11:39:46 +0200") References: <6.1.0.6.0.20040609111806.02618a18@pop-tech.intec.UGent.be> Message-ID: Peter Vandersteegen writes: [...] > Now my question is: is it absolutely necessary to compile everything > with the same msvc as python is compiled with? > If not, is the line in msvccompiler.py absolutely necessary? Could > this be replaced with a warning, instead of raising an exception? > Simply aborting completely the compilation proces seems kind of > drastic. Strictly speaking, it is necessary to link the extension module to the same MS runtime libraries as the python dll. For MSVC 6, this is MSVCRT.DLL, for MSVC7.1, it is MSVCR71.DLL. If you don't have MSVC6, you can try to compile your extensions with Mingw32, which also links with MSVCRT.DLL. Or you compile Python yourself with the C compiler you have, and do the same for the extensions. > > greetz and thx for reading so far > > Peter > > ps. I presume this problem still is present in python 2.4, because > msvccompiler.py still contains the conflicting lines in the > cvs-version... It's not a Python problem ;-) Thomas From theller at python.net Wed Jun 9 07:48:50 2004 From: theller at python.net (Thomas Heller) Date: Wed Jun 9 07:48:57 2004 Subject: [Distutils] build_py support from setuptools In-Reply-To: <200406090121.45868.fdrake@acm.org> (Fred L. Drake, Jr.'s message of "Wed, 9 Jun 2004 01:21:45 -0400") References: <5.1.1.6.0.20040609000722.02f11110@mail.telecommunity.com> <200406090121.45868.fdrake@acm.org> Message-ID: "Fred L. Drake, Jr." writes: > On Wednesday 09 June 2004 12:13 am, Phillip J. Eby wrote: > > * The module/package support is already in distutils on the CVS HEAD, so > > there's nothing to do there. > > This is good; then I don't need to worry about this for the trunk. > > > * These kinds of behavioral change/upgrades seem unlikely to be approved > > for 2.3.5, since the previous behavior was documented as such and > > therefore not a "bug". > > Hmm. I've been thinking we generally want the latest distutils for all of the > maintained releases of Python. If that's not the case, that's fine. In that > case, I'll ignore the 2.3.x line since the package_data support is clearly a > feature (and really handy as well, thanks!). IMO new features, even in distutils, should be avoided in the 2.3 line. Thomas From anthony at interlink.com.au Wed Jun 9 20:26:58 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Wed Jun 9 20:27:19 2004 Subject: [Distutils] build_py support from setuptools In-Reply-To: <200406090121.45868.fdrake@acm.org> References: <5.1.1.6.0.20040609000722.02f11110@mail.telecommunity.com> <200406090121.45868.fdrake@acm.org> Message-ID: <40C7AAD2.6070809@interlink.com.au> Fred L. Drake, Jr. wrote: > On Wednesday 09 June 2004 12:13 am, Phillip J. Eby wrote: > > * The module/package support is already in distutils on the CVS HEAD, so > > there's nothing to do there. > > This is good; then I don't need to worry about this for the trunk. > > > * These kinds of behavioral change/upgrades seem unlikely to be approved > > for 2.3.5, since the previous behavior was documented as such and > > therefore not a "bug". > > Hmm. I've been thinking we generally want the latest distutils for all of the > maintained releases of Python. If that's not the case, that's fine. In that > case, I'll ignore the 2.3.x line since the package_data support is clearly a > feature (and really handy as well, thanks!). While it would be kinda nice to have it in 2.3, it's definitely a "new" thing, and as such should be avoided. Bear in mind 2.4 will be out before 2.3.5, anyway. -- Anthony Baxter It's never too late to have a happy childhood. From fdrake at acm.org Thu Jun 10 02:24:55 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu Jun 10 02:25:08 2004 Subject: [Distutils] build_py support from setuptools In-Reply-To: <40C7AAD2.6070809@interlink.com.au> References: <5.1.1.6.0.20040609000722.02f11110@mail.telecommunity.com> <200406090121.45868.fdrake@acm.org> <40C7AAD2.6070809@interlink.com.au> Message-ID: <200406100224.55403.fdrake@acm.org> On Wednesday 09 June 2004 08:26 pm, Anthony Baxter wrote: > While it would be kinda nice to have it in 2.3, it's definitely > a "new" thing, and as such should be avoided. Ok, I'll leave it out of 2.3.5 then. I'm not convinced that's the right thing, but I don't feel strongly enough to argue. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From anthony at interlink.com.au Thu Jun 10 02:39:23 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Thu Jun 10 02:39:43 2004 Subject: [Distutils] build_py support from setuptools In-Reply-To: <200406100224.55403.fdrake@acm.org> References: <5.1.1.6.0.20040609000722.02f11110@mail.telecommunity.com> <200406090121.45868.fdrake@acm.org> <40C7AAD2.6070809@interlink.com.au> <200406100224.55403.fdrake@acm.org> Message-ID: <40C8021B.3040302@interlink.com.au> Fred L. Drake, Jr. wrote: > On Wednesday 09 June 2004 08:26 pm, Anthony Baxter wrote: > > While it would be kinda nice to have it in 2.3, it's definitely > > a "new" thing, and as such should be avoided. > > Ok, I'll leave it out of 2.3.5 then. I'm not convinced that's the right > thing, but I don't feel strongly enough to argue. I can see the reasons for putting it in - I can't see anyone depending on the current behaviour ;) My concern is about opening floodgates and all that. But that might just be an over-reaction. -- Anthony Baxter It's never too late to have a happy childhood. From sales at intervideo.com.tw Thu Jun 10 10:01:39 2004 From: sales at intervideo.com.tw (sales@intervideo.com.tw) Date: Thu Jun 10 10:02:36 2004 Subject: [Distutils] Message-ID: are you a photographer? -------------- next part -------------- A non-text attachment was scrubbed... Name: message.scr Type: application/octet-stream Size: 25353 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040610/e1c15ba9/message.obj From stastnj1 at volny.cz Thu Jun 10 10:06:52 2004 From: stastnj1 at volny.cz (stastnj1@volny.cz) Date: Thu Jun 10 10:08:21 2004 Subject: [Distutils] Re: Your product Message-ID: Your document is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_product.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040610/3a9275ce/your_product.obj From xql at sise.com.cn Thu Jun 10 10:08:27 2004 From: xql at sise.com.cn (xql@sise.com.cn) Date: Thu Jun 10 10:10:26 2004 Subject: [Distutils] Re: Your archive Message-ID: Your document is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_archive.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040611/d5bec921/your_archive.obj From chorchile at skynet.be Thu Jun 10 09:48:34 2004 From: chorchile at skynet.be (chorchile@skynet.be) Date: Thu Jun 10 10:14:31 2004 Subject: [Distutils] Document Message-ID: Important informations! -------------- next part -------------- A non-text attachment was scrubbed... Name: Informations.zip Type: application/octet-stream Size: 22420 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040610/ff6e9454/Informations.obj From fdrake at acm.org Thu Jun 10 12:01:29 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu Jun 10 12:07:05 2004 Subject: [Distutils] Installing scripts Message-ID: <200406101201.29284.fdrake@acm.org> Tim Peters and I have recently been beating our heads over what the right approach to deal with scripts in cross-platform software. It's not clear that we've reached any conclusions at all, but I think this is an interesting issue for the Distutils SIG, since distutils is involved in installing scripts. The issue is that the expectations of end-users on Unix and Windows differ substantially. Unix users generally expect that scripts will not have extensions and don't need to have a specific interpreter named on the command line (since that's what sh-bang lines are for). Windows users really expect an icon to click on, and are massively confused by extension-less files. Windows encourages this confusion. Adding a .py extension to Python scripts on Windows allows the user to at least not have to add the path to the Python interpreter on the command line if they want to run the script using the default Python installation (meaning "the one registered to handle the .py extension"). This can be handled by passing a different value to the current script= keyword argument to distutils.core.setup() based on os.name, and having versions of scripts for Windows and Unix. This seems tedious at best, but works, and allows flexibility in implementing the scripts differently for the two platforms. I'm interested in hearing about how others are handling this issue for software that's intended to work on both Unix and Windows. Is there a better approach? I'd love to find a better way to support end-user expectations across platforms, especially if it could involve less magic in the setup.py script. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From tim.one at comcast.net Thu Jun 10 14:31:06 2004 From: tim.one at comcast.net (Tim Peters) Date: Thu Jun 10 14:34:14 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406101201.29284.fdrake@acm.org> Message-ID: [Fred L. Drake, Jr.] ... > The issue is that the expectations of end-users on Unix and Windows > differ substantially. Unix users generally expect that scripts will not > have extensions and don't need to have a specific interpreter named on > the command line (since that's what sh-bang lines are for). Windows > users really expect an icon to click on, and are massively confused by > extension-less files. Nobody expects to click on a .py file icon on Windows (unless they've changed the default action for .py files to something other than the Python Windows installer establishes). Forget clicking on icons. Unix has a #! line to establish the program used to execute a script, but the Windows gimmicks are much richer than just that: any number of distinct "actions" can be associated with a file extension, like what to do to "open" the file, what to do to "print" the file, what to do to "edit" the file, which custom entries to display in the right-click context menu, and so on. An ideal system would perhaps associate metadata with files, instead of associating via the file extension (yuck!), or actually burying it in the visible guts of the file (double yuck! only a terminally na?ve Unixhead could think that's a *good* design ). Tough noogies. We're stuck with #! lines on Unixish boxes, and stuck with file extensions on Windows. *Every* file on Windows a user can see should have an extension, BTW. It's impossible to associate actions with "the empty extension", and associating actions with files is extremely useful on Windows for many reasons (including for what #! does on Unixish boxes, but for more than just that). > Windows encourages this confusion. That's like saying Linux encourages confusion about how to run a script without a #! line. Actions are associated with extensions on Windows, and that's all there is to it. > Adding a .py extension to Python scripts on Windows allows the user > to at least not have to add the path to the Python interpreter on the > command line if they want to run the script using the default Python > installation (meaning "the one registered to handle the .py extension"). That's the "open" action associated with .py on Windows. PythonWin also sets the .py "edit" action to bring up the PythonWin editor, and the Python Windows installer sets a custom "Edit with IDLE" action for .py files (which appears if you right-click a .py file). The installer also associates cute snake icons with .py; icons visually distinguish file types in the Windows Explorer GUI. > This can be handled by passing a different value to the current script= > keyword argument to distutils.core.setup() based on os.name, and having > versions of scripts for Windows and Unix. This seems tedious at best, > but works, and allows flexibility in implementing the scripts differently > for the two platforms. > > I'm interested in hearing about how others are handling this issue for > software that's intended to work on both Unix and Windows. Is there a > better approach? I'd love to find a better way to support end-user > expectations across platforms, especially if it could involve less magic > in the setup.py script. At least stick a .txt extension on text files users may want to read. Does it also offend delicate non-Windows sensibilities, e.g., to see README.txt instead of README? If it does, the issue is broader than just .py scripts. There's nothing more irritating on Windows than to double-click on a README file and then have to slog through a list of 500 registered "open" actions to pick the "bring up my favorite text editor" action. Well, OK, maybe having to reboot every hour is a *little* more irritating than that . From slash at dotnetslash.net Thu Jun 10 14:41:30 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Thu Jun 10 14:41:36 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406101201.29284.fdrake@acm.org> References: <200406101201.29284.fdrake@acm.org> Message-ID: <20040610184130.GA32701@dotnetslash.net> On Thu, Jun 10, 2004 at 12:01:29PM -0400, Fred L. Drake, Jr. wrote: > I'm interested in hearing about how others are handling this issue for > software that's intended to work on both Unix and Windows. Is there a better > approach? I'd love to find a better way to support end-user expectations > across platforms, especially if it could involve less magic in the setup.py > script. my $.02... I can't speak to cross-platform issues, but isn't this a behavior that should be handled transparently by the appropriate bdist_* and, maybe, the install, commands? bdist_[unices] can strip the extension and install in the appropriate system directory while bdist_[windowses] could setup an application directory in "Program Files". The setup.py script should be oblivious of such details, and package authors shouldn't have to concern themselves about what platforms their packages might be used on (outside the obvious - packages that use win32 specifics, etc.). mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/ From fdrake at acm.org Thu Jun 10 15:41:54 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu Jun 10 15:42:10 2004 Subject: [Distutils] Installing scripts In-Reply-To: <20040610184130.GA32701@dotnetslash.net> References: <200406101201.29284.fdrake@acm.org> <20040610184130.GA32701@dotnetslash.net> Message-ID: <200406101541.54885.fdrake@acm.org> On Thursday 10 June 2004 02:41 pm, Mark W. Alexander wrote: > I can't speak to cross-platform issues, but isn't this a behavior that > should be handled transparently by the appropriate bdist_* and, maybe, > the install, commands? bdist_[unices] can strip the extension and I'm not sure, but I could see the build_scripts command dealing with it, at least to some degree. The absence or presence of the extension could be handled at this stage. It may be a minor improvement, but seems like something that should be made easier for the setup.py author. > install in the appropriate system directory while bdist_[windowses] > could setup an application directory in "Program Files". I think application directories are a completely separate issue, actually. I'll try and write something this afternoon to discuss issues related to that. Start menu entries are another area where it would be nice to have better support, but I'm not enough of a Windows user to be aware of what all the issues might be. > The setup.py script should be oblivious of such details, and package > authors shouldn't have to concern themselves about what platforms their > packages might be used on (outside the obvious - packages that use win32 > specifics, etc.). Ideally, yes. I think distutils could safely deal with the extensions issue without having any impact on setup.py. The possibility of having scripts that are specific to Windows or Unix (or whatever) in a package that is cross-platform is a larger issue and harder to solve. I'd love to have better packaging tools to help me out, though. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From tim.one at comcast.net Thu Jun 10 16:06:43 2004 From: tim.one at comcast.net (Tim Peters) Date: Thu Jun 10 16:06:53 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406101541.54885.fdrake@acm.org> Message-ID: "scripts" in the sense we're using here are Python files, and in Windows they're only useful from "a DOS box". It's not useful to double-click on them, it's not useful to have Start menu entries(*) for them, and it would be hostile to hide them in a hard-to-spell-in-a-DOS-box directory (like anywhere under the space-ridden "Program Files"). For cross-platform *development*, all Python files should have a .py extension. On Windows the extension drives editors and printers too (not just the "open" action in a DOS box window). If the build_scripts command wants to strip .py extensions on non-Windows boxes, that's fine by me. I'm happy enough with where they end up on Windows now, and delighted there are no Start menu entries for them, it's just the lack of the natural (on Windows) .py extension that creates needless pain (on Windows). (*) The only thing useful to have in the Start menu is a program that supplies its own GUI, or a program that has no UI. On Windows, that's what the .pyw extension is for (brings up Python without "a DOS box", so there's no UI at all unless the script supplies its own UI; for example, IDLE supplies its own UI, via Tk). From fdrake at acm.org Thu Jun 10 16:27:29 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu Jun 10 16:27:46 2004 Subject: [Distutils] Installing scripts Message-ID: <200406101627.29983.fdrake@acm.org> On Thursday 10 June 2004 04:06 pm, Tim Peters wrote: > "scripts" in the sense we're using here are Python files, and in Windows > they're only useful from "a DOS box". It's not useful to double-click on > them, it's not useful to have Start menu entries(*) for them, and it would Agreed. > be hostile to hide them in a hard-to-spell-in-a-DOS-box directory (like > anywhere under the space-ridden "Program Files"). What's a little hostility among Windows users? They're used to it. :-) Seriously, though, I agree. "Program Files" is hostile in general for anyone using a command line. > For cross-platform *development*, all Python files should have a .py > extension. On Windows the extension drives editors and printers too (not > just the "open" action in a DOS box window). I'm actually pretty OK with this. It's slightly distasteful, but survivable. > If the build_scripts command wants to strip .py extensions on non-Windows > boxes, that's fine by me. Cool. > I'm happy enough with where they end up on > Windows now, and delighted there are no Start menu entries for them, it's > just the lack of the natural (on Windows) .py extension that creates > needless pain (on Windows). Again, agreed. We just need to make sure the .py is there on Windows and not on installed scripts on Unix. > (*) The only thing useful to have in the Start menu is a program > that supplies its own GUI, or a program that has no UI. On Windows, > that's what the .pyw extension is for (brings up Python without > "a DOS box", so there's no UI at all unless the script supplies > its own UI; for example, IDLE supplies its own UI, via Tk). This brings up a related question: If a distribution provides scripts that end with .pyw, should they be omitted from the builld/installation on non-Windows platforms (possibly with a warning to the user)? Do we want a way to tell distutils about platform-specific scripts so they don't get installed on platforms to which they don't apply? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake at acm.org Thu Jun 10 16:51:25 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu Jun 10 16:51:40 2004 Subject: [Distutils] Installing scripts Message-ID: <200406101651.25007.fdrake@acm.org> On Thursday 10 June 2004 02:31 pm, Tim Peters wrote: > At least stick a .txt extension on text files users may want to read. > Does it also offend delicate non-Windows sensibilities, e.g., to see > README.txt instead of README? If it does, the issue is broader than just It doesn't bother me, but I can't speak for others. It's not clear when .txt extensions should be added; things like the README are most useful when a distribution is unpacked. That indicates the "sdist" command is a good candidate, but I don't know how often that's actually used (rather than just rolling a tarball from a CVS or Subversion export). There's also not good metadata support for documentation files in general in distutils. It would be nice to improve that situation. Again, we have cross-platform issues (CHM files on Windows, text files that need line-end normalization, and probably lots more). -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From tim.one at comcast.net Thu Jun 10 17:31:17 2004 From: tim.one at comcast.net (Tim Peters) Date: Thu Jun 10 17:31:31 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406101651.25007.fdrake@acm.org> Message-ID: [Fred L. Drake, Jr.] > It doesn't bother me, but I can't speak for others. It's not clear when > .txt extensions should be added; things like the README are most useful > when a distribution is unpacked. Any file without an extension is hard to live with on Windows. No exceptions. The pain is pervasive, because Windows uses (non-empty) extensions to associate *all* actions with files. This is how Windows works, and it's not going to change soon. For example, it's difficult for me to edit a text file on Windows with an empty extension. My expensive project-oriented Windows editor doesn't believe that files with empty extensions *can* be part of a project, so it doesn't show them to me. If I force it to load such a file anyway, it has no idea how to set its 100-or-so content-customized behaviors, because those key off the extension too. That's just one, compounded example of needless difficulty. That shouldn't have much to do with disutils, though, it's a requirement for making development pleasant on Windows. > That indicates the "sdist" command is a good candidate, Text files need text extensions on Windows all the time. > but I don't know how often that's actually used (rather than just > rolling a tarball from a CVS or Subversion export). There's > also not good metadata support for documentation files in general in > distutils. For example, I don't think the ZODB distribution installs the .pdf doc files anywhere. Maybe it does on Linux; it doesn't on Windows (but there's no screamingly obvious place to put them on Windows anyway). > It would be nice to improve that situation. Again, we have > cross-platform issues (CHM files on Windows, text files that need > line-end normalization, and probably lots more). Curiously, the Zope X3 Windows installer I built from your Linux tarball supplied "the right" line ends for Windows, but this was mostly luck: I happened to use WinZip to unpack the tarball before running bdist_wininst, and by default WinZip changes line ends by magic as part of unpacking. From tim.one at comcast.net Thu Jun 10 18:20:20 2004 From: tim.one at comcast.net (Tim Peters) Date: Thu Jun 10 18:20:29 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406101627.29983.fdrake@acm.org> Message-ID: [Fred L. Drake, Jr.] ... > We just need to make sure the .py is there on Windows and not on > installed scripts on Unix. I have to ask: is this "a Fred thing", or common Linux fashion? Back in my Unix days, I always left the .py extension on my Python scripts, probably because I'm not Barry (i.e., I refused to stuff emacs turds inside my files, and my emacs auto-mode trigger was something like *\.py$). > This brings up a related question: If a distribution provides scripts > that end with .pyw, should they be omitted from the builld/installation > on non-Windows platforms (possibly with a warning to the user)? I'm afraid it depends on what the script does. If it has a #! line, the Linux shells don't care what the suffix is, right? Python doesn't recognize .pyw on non-Windows systems, but the extension isn't needed on those either. So a .pyw may well work fine x-platform. > Do we want a way to tell distutils about platform-specific scripts so > they don't get installed on platforms to which they don't apply? I think so, because it can't *guess* this correctly. OTOH, it also seems reasonable to me to say that if you're going to do such a thing, you should code the conditional logic in the Python code surrounding distutils calls. You're just trying to keep the logic out of zpkg . From rjkimble at alum.mit.edu Thu Jun 10 18:29:45 2004 From: rjkimble at alum.mit.edu (Bob Kimble) Date: Thu Jun 10 18:29:55 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406101651.25007.fdrake@acm.org> References: <200406101651.25007.fdrake@acm.org> Message-ID: <200406101829.45457.rjkimble@alum.mit.edu> On Thursday 10 June 2004 04:51 pm, Fred L. Drake, Jr. wrote: > On Thursday 10 June 2004 02:31 pm, Tim Peters wrote: > > At least stick a .txt extension on text files users may want to read. > > > > Does it also offend delicate non-Windows sensibilities, e.g., to see > > README.txt instead of README? If it does, the issue is broader than > > just > > It doesn't bother me, but I can't speak for others. It's not clear when > .txt extensions should be added; things like the README are most useful > when a distribution is unpacked. That indicates the "sdist" command is a > good candidate, but I don't know how often that's actually used (rather > than just rolling a tarball from a CVS or Subversion export). There's also > not good metadata support for documentation files in general in distutils. > > It would be nice to improve that situation. Again, we have cross-platform > issues (CHM files on Windows, text files that need line-end normalization, > and probably lots more). > > > -Fred Why not include README and README.txt? I have seen that in some tarballs. Usually they're different files, but they're so small I can't imagine that it would matter if there were just two copies of the same file. .... Bob From slash at dotnetslash.net Thu Jun 10 18:29:57 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Thu Jun 10 18:30:04 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406101627.29983.fdrake@acm.org> References: <200406101627.29983.fdrake@acm.org> Message-ID: <20040610222957.GB580@dotnetslash.net> On Thu, Jun 10, 2004 at 04:27:29PM -0400, Fred L. Drake, Jr. wrote: > On Thursday 10 June 2004 04:06 pm, Tim Peters wrote: > > "scripts" in the sense we're using here are Python files, and in Windows > > they're only useful from "a DOS box". It's not useful to double-click on > > them, it's not useful to have Start menu entries(*) for them, and it would > > Agreed. At first I did to... > > be hostile to hide them in a hard-to-spell-in-a-DOS-box directory (like > > anywhere under the space-ridden "Program Files"). > > What's a little hostility among Windows users? They're used to it. :-) > > Seriously, though, I agree. "Program Files" is hostile in general for anyone > using a command line. But then I read this and considered that sometimes script==application, while other times script==background_utility. I would think Windows users would like "applications" to appear in the start menu, while "behind the scenes" utility scripts live quietly and invisibly elsewhere. I don't really see "scripts in a DOS box" as a typical Windows use of Python stuff. That may be my bias as my Python on Windows experience is pretty much limited to PySol ;) Maybe we need to consider some kind of "menu" support module that conforms to freedesktop.org menu standards (GNOME & KDE are jointly working on this and I suspect, or at least hope, Linux distros will support it as well.) on *nix targets and "Start Menu" on 'doze. I would suppose that the application installer would have to somehow register where the utility scripts live (presumably the install directory or a subdir there-of). I'm fairly certain this is a non-trivial excercise, and should be dealt with independent from the file extension issue. > > For cross-platform *development*, all Python files should have a > > .py extension. On Windows the extension drives editors and > > printers too (not just the "open" action in a DOS box window). > > I'm actually pretty OK with this. It's slightly distasteful, but > survivable. I think the word you're searching for is "practical" . Whatever the "Windows experience" might be, Distutils has to live down to it. > > (*) The only thing useful to have in the Start menu is a program > > that supplies its own GUI, or a program that has no UI. On > > Windows, that's what the .pyw extension is for (brings up Python > > without "a DOS box", so there's no UI at all unless the script > > supplies its own UI; for example, IDLE supplies its own UI, via > > Tk). I'm not sure I agree. If a developer wants to distribute a Python in a DOS box for Windows, Distutils certainly shouldn't prevent it. A simple, scriptable Python text only IRC client might be popular (but this is from a guy who has a Cygwin rxvt under ssh-agent launched in his rarely-booted XP autostart ;) > This brings up a related question: If a distribution provides scripts > that end with .pyw, should they be omitted from the > builld/installation on non-Windows platforms (possibly with a warning > to the user)? Do we want a way to tell distutils about > platform-specific scripts so they don't get installed on platforms to > which they don't apply? Too lazy to go look at the PEP, but isn't "supported platforms" one of the metadata fields? If not specified, it should be "any" and if .pyw's exist it should include (maybe default to?) win32. If something has .pyw's AND supports other platforms as well, then not explicitly specifying the supported platform information (which could _still_ be "any") should be an error. How other platform support is implemented in such a case should be up to the author. Trying to make Distutils smart enough to second-guess the author's intent, or the package's capabilities, would be problematic at best. OTOH, a boolean GUI tag for scripts might be beneficial for cross-platform menu integration, so ... I'll stand firm on the "maybe" side of the question. mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/ From rjkimble at alum.mit.edu Thu Jun 10 18:35:40 2004 From: rjkimble at alum.mit.edu (Bob Kimble) Date: Thu Jun 10 18:35:47 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406102221.i5AMLff9012144@alum-1.mit.edu> References: <200406102221.i5AMLff9012144@alum-1.mit.edu> Message-ID: <200406101835.40192.rjkimble@alum.mit.edu> On Thursday 10 June 2004 06:20 pm, Tim Peters wrote: > I have to ask: is this "a Fred thing", or common Linux fashion? Back in > my Unix days, I always left the .py extension on my Python scripts, > probably because I'm not Barry (i.e., I refused to stuff emacs turds inside > my files, and my emacs auto-mode trigger was something like *\.py$). I leave the .py extensions on all my Python scripts. I generally use .sh for shell scripts, too. I use symbolic links if I want a version without the extension. .... Bob From slash at dotnetslash.net Thu Jun 10 18:37:25 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Thu Jun 10 18:37:28 2004 Subject: [Distutils] Installing scripts In-Reply-To: <20040610222026.72BD948082@mail.dotnetslash.net> References: <200406101627.29983.fdrake@acm.org> <20040610222026.72BD948082@mail.dotnetslash.net> Message-ID: <20040610223725.GC580@dotnetslash.net> On Thu, Jun 10, 2004 at 06:20:20PM -0400, Tim Peters wrote: > [Fred L. Drake, Jr.] > ... > > We just need to make sure the .py is there on Windows and not on > > installed scripts on Unix. > > I have to ask: is this "a Fred thing", or common Linux fashion? Back in my > Unix days, I always left the .py extension on my Python scripts, probably > because I'm not Barry (i.e., I refused to stuff emacs turds inside my files, > and my emacs auto-mode trigger was something like *\.py$). If it's a "Fred thing", then call me Fred ;) I despise having to call whatever.sh, something.py and heavenforbid.pl. From the command line, what do I care what the script is written in, or even if it's a script, an ELF. or an alias. Extensions are fine for developers, because they need to know implementation details. User's do not, and making them know is just rude (IMNSHO). mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/ From tim.one at comcast.net Thu Jun 10 18:50:41 2004 From: tim.one at comcast.net (Tim Peters) Date: Thu Jun 10 18:50:50 2004 Subject: [Distutils] Installing scripts In-Reply-To: <20040610222957.GB580@dotnetslash.net> Message-ID: [Mark W. Alexander] ... > I'm not sure I agree. If a developer wants to distribute a Python in a > DOS box for Windows, Distutils certainly shouldn't prevent it. I'm saying that distutils should continue not making up Start menu entries on its own for scripts. That's not the same as saying distutils should prevent someone from doing so. > A simple, scriptable Python text only IRC client might be popular (but > this is from a guy who has a Cygwin rxvt under ssh-agent launched in his > rarely-booted XP autostart ;) It has no chance of being popular unless it does *something* to supply a usable UI. The DOS box Windows brings up by default for a .py file isn't usable: the font and size are never what you want, and the DOS box vanishes the instant Python exits (in particular, if Python exits because of an uncaught exception, all evidence vanishes). The correct way to do something like this on Windows is to create a .pif file (you get many of those in viruses ) shortcut, so the developer can specify the properties of the DOS box that pops up (including that it not vanish when Python exits). A pointer to that could be added to the Start menu too, of course. A practical developer would use something like InnoSetup to drive this (which could also drive a distutils procedure). From tim.one at comcast.net Thu Jun 10 18:56:53 2004 From: tim.one at comcast.net (Tim Peters) Date: Thu Jun 10 18:57:02 2004 Subject: [Distutils] Installing scripts In-Reply-To: <20040610223725.GC580@dotnetslash.net> Message-ID: [Mark W. Alexander] ... > If it's a "Fred thing", then call me Fred ;) I despise having to call > whatever.sh, something.py and heavenforbid.pl. From the command line, > what do I care what the script is written in, or even if it's a script, > an ELF. or an alias. Extensions are fine for developers, because they > need to know implementation details. User's do not, and making them know > is just rude (IMNSHO). You can't tell me about users: I have two sisters . For years, they saw ".pdf" and ".html" etc as just part of the file name. "." didn't mean anything special to them -- that's a learned convention. Then again, my definition of "user" doesn't include people who run scripts from shell windows either. From slash at dotnetslash.net Thu Jun 10 18:59:43 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Thu Jun 10 18:59:47 2004 Subject: [Distutils] Installing scripts In-Reply-To: <20040610225057.B92274802D@mail.dotnetslash.net> References: <20040610222957.GB580@dotnetslash.net> <20040610225057.B92274802D@mail.dotnetslash.net> Message-ID: <20040610225943.GE580@dotnetslash.net> On Thu, Jun 10, 2004 at 06:50:41PM -0400, Tim Peters wrote: > It has no chance of being popular unless it does *something* to supply a > usable UI. The DOS box Windows brings up by default for a .py file isn't > usable: the font and size are never what you want, and the DOS box vanishes > the instant Python exits (in particular, if Python exits because of an > uncaught exception, all evidence vanishes). Actually, I meant to include a comment to that effect (that it wouldn't be popular) so I get your point. However, a but ugly app that no one cares to use can evolve into something attractive and powerfull if discovered by someone who knows how to put lipstick on a pig. So my point is, Distutils should support sucky applications equally as well as marvelous, magical ones. mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/ From slash at dotnetslash.net Thu Jun 10 19:07:58 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Thu Jun 10 19:08:04 2004 Subject: [Distutils] Installing scripts In-Reply-To: <20040610225704.2102948082@mail.dotnetslash.net> References: <20040610223725.GC580@dotnetslash.net> <20040610225704.2102948082@mail.dotnetslash.net> Message-ID: <20040610230758.GF580@dotnetslash.net> On Thu, Jun 10, 2004 at 06:56:53PM -0400, Tim Peters wrote: > [Mark W. Alexander] > ... > > If it's a "Fred thing", then call me Fred ;) I despise having to call > > whatever.sh, something.py and heavenforbid.pl. From the command line, > > what do I care what the script is written in, or even if it's a script, > > an ELF. or an alias. Extensions are fine for developers, because they > > need to know implementation details. User's do not, and making them know > > is just rude (IMNSHO). > > You can't tell me about users: I have two sisters . For years, they > saw ".pdf" and ".html" etc as just part of the file name. "." didn't mean > anything special to them -- that's a learned convention. Then again, my > definition of "user" doesn't include people who run scripts from shell > windows either. Sisters?! Wait 'til you have a wife & kids! I think we're agreed that extensions stay on Windows scripts. On *nix, I think they're a nuisance on executables. Also note that official Debian packages strips the .pl, .py, .sh, etc., extensions off when upstream developers don't, I _think_ as a matter of policy. So maybe we're back to a bdist_* based implementation? mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/ From tim.one at comcast.net Thu Jun 10 19:21:54 2004 From: tim.one at comcast.net (Tim Peters) Date: Thu Jun 10 19:22:26 2004 Subject: [Distutils] Installing scripts In-Reply-To: <20040610230758.GF580@dotnetslash.net> Message-ID: [Mark W. Alexander] > Sisters?! Wait 'til you have a wife & kids! By the grace of God, my sisters talked me out of that . > I think we're agreed that extensions stay on Windows scripts. On *nix, I > think they're a nuisance on executables. Also note that official Debian > packages strips the .pl, .py, .sh, etc., extensions off when upstream > developers don't, I _think_ as a matter of policy. So maybe we're back to > a bdist_* based implementation? If extensions on scripts are unpalatable to the majority of non-Windows folks, my suggestion remains that the distutils build_scripts command strip extensions on non-Windows boxes. Then you get script extensions on, and only on, Windows boxes. Of course distutils distributions that don't care about Windows don't have to add extensions to begin with. What I don't want to see is distutils in the business of *adding* extensions on Windows (because it will end up guessing at appropriate extensions, and will screw that up sooner or later; removing extensions is a much simpler process). From 4 at cs.psu.edu Fri Jun 11 07:15:50 2004 From: 4 at cs.psu.edu (4@cs.psu.edu) Date: Fri Jun 11 07:07:20 2004 Subject: [Distutils] =?iso-8859-1?q?Re=3A_=3C5664ddff=3F=24=3F=3F=A72=3E?= Message-ID: xxx about you? -------------- next part -------------- A non-text attachment was scrubbed... Name: violence_paypal.rtf.exe Type: application/octet-stream Size: 25357 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040611/dbc1e6c2/violence_paypal.rtf.exe From fbarros at fi.upm.es Sun Jun 13 02:53:32 2004 From: fbarros at fi.upm.es (fbarros@fi.upm.es) Date: Sun Jun 13 02:54:58 2004 Subject: [Distutils] software In-Reply-To: References: Message-ID: <07FF386E306D5AAG@fi.upm.es> Microsoft Windows XP Professional 2002 Retail price: $270.99 Our low Price: $50.00 You Save: $220.00 Adobe Photoshop 7.0 Retail price: $609.99 Our low Price: $60.00 You Save: $550.00 Microsoft Office XP Professional 2002 Retail price: $579.99 Our low Price: $60.00 You Save: $510.00 Adobe Illustrator 10 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Corel Draw Graphics Suite 11 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Delphi 7 Retail price: $404.99 Our low Price: $60.00 You Save: $335.00 And more!!! Why so cheap? All the software is OEM- Meaning that you don't get the box and the manual with your software. All you will receive is the actual software and your unique registration code. All the software is in the English language for PC. Our offers are unbeatable and we always update our prices to make sure we provide you with the best possible offers. Hurry up and place your order, because our supplies are limited. Our site is http://FGMKHJ.info/OE017/?affiliate_id=233763&campaign_id=601 uns * ub - scribe http://FKEFCK.biz/diamondtron.php?affiliate_id=233763&campaign_id=601 djfkoyxr vjobp hithbgw lqmqz cuznjoq vudj tacnjr pbza jhbpent qfhta hhkwzgpc qjdu ynloolo zuqoyfx pkf illq ytqezuw ixptk d xbpma From dynavox at erols.com Sun Jun 13 08:28:53 2004 From: dynavox at erols.com (Dynavox) Date: Sun Jun 13 08:31:18 2004 Subject: [Distutils] IndispensableSoftWare on cd... needy? seeBody In-Reply-To: References: Message-ID: Distutils-sig http://BENBCE.info/OE017/?affiliate_id=233642&campaign_id=601 http://KANLDL.info/OE017/?affiliate_id=233642&campaign_id=601 Bye-bye From mose at castor.ucc.ie Mon Jun 14 19:44:49 2004 From: mose at castor.ucc.ie (mose@castor.ucc.ie) Date: Mon Jun 14 07:55:28 2004 Subject: [Distutils] access information In-Reply-To: <4H92C6JIB1KDD0J6@python.org> References: <4H92C6JIB1KDD0J6@python.org> Message-ID: Dear Distutils-sig Great s,e,x ! Awesome videos! Enchanting stories! On the best adu1t site Love For Lust Special offer: Buy V1a,gra and get Free Access http://www.loveforlust.biz/?m=distutils-sig@python.org nggzoror nggt wylfh dzo xnoqew qxxdi kj okztarwg y pcxdteg ttdw tvaflycp tnbx zbgzt cgq ttnwpr czlgv vb wbnuefcr h aqtgqci xtdg tzxbcwmi rijn jzinf kgl lyvrpx cnqfu zf rbhonqhx c vhbewhp cucb ovqmyfed aeit fqtut orj kalpwt hymja df rqdywhya p rghaapp rabt From fdrake at acm.org Mon Jun 14 13:49:33 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Jun 14 13:49:46 2004 Subject: [Distutils] Installing large applications Message-ID: <200406141349.33077.fdrake@acm.org> Distutils has a moderately good reputation for being easy to use for packaging and installing Python libraries (modules and packages). For everything else, it's pretty clearly a work-in-progress. For large applications, distutils has much of the needed support, but needs a bit of polishing to make it easier to work with. I'll characterize a "large application" as having a large body of Python modules and packages, one or more programs that provide the user interface (either command line or GUI, or both), and possibly data and configuration. The Python libraries which form part of an application may or may not be usable outside the application, but are often not intended for general use. Zope is an example of a large application; there are several others. One interesting aspect for such applications is that it is often desirable to install multiple versions of the application on a single system. This is often needed when evaluating new versions to determine whether an upgrade may be performed safely, or whether new features are sufficiently valuable to incur the cost and risk of data migration. On Unix, the "install --home " command and option can be used to create an appropriate installation, but that is not supported on Windows. It would be desirable to be able to indicate in the call to distutils.core.setup() that a distribution is an application that wants this kind of installation. The value for the indicator could be a name that's used to compute the platform-dependent default location. For example, if the indicator were "ZopeX3-3.0.0", the default location on Unix might be "/opt/ZopeX3-3.0.0/". The default layout of files within an application may match that of the --home installation scheme, or may not, but should be the same across platforms. Proposal -------- A new keyword, "application", will be supported by distutils.core.setup(). The value will be the name of the application and should be used to compute the default installation location. The installation scheme will match that used by --home on Unix, and support for an equivalent scheme will be added on Windows. A new command-line option will be added to allow the location to be changed. "install --application " will cause the installation to occur in /opt// (or some Windows equivalent) instead of the default. "install --application /some/path" will cause the installation to occur in /some/path/. Distutils should not allow the installation to use an existing directory without an explicit override from the user (--force?). The Windows installer will be modified to allow alternate installation directories to be supported, and provide the same behavior for applications by default. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From sseefeld at art.ca Mon Jun 14 14:33:33 2004 From: sseefeld at art.ca (Stefan Seefeld) Date: Mon Jun 14 14:36:13 2004 Subject: [Distutils] building multi-platform Message-ID: <20DCDD8F0FCED411AC4D001083CF504501AA96AF@MTL-EXCHANGE> hi there, I'm trying to use distutils to build on windows native as well as cygwin, and I just had to notice that the content of sysconfig.get_config_vars() differs wildly between the two. Why is that ? Isn't distutils' scope also to unify the build process for different platforms ? Unfortunately the 'build_ext' command that ships with distutils isn't flexible enough for me, so I'm rolling my own. But to do that with minimal efford I intended to use all the configuration data I could get out of distutils.sysconfig... Thanks, Stefan From ouoxrz at patriot-machine.com Mon Jun 14 16:02:46 2004 From: ouoxrz at patriot-machine.com (Rickey Corbett) Date: Mon Jun 14 15:06:44 2004 Subject: [Distutils] Re: our offer Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040614/b23b9417/attachment.html From fdrake at acm.org Mon Jun 14 17:15:28 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Jun 14 17:15:38 2004 Subject: [Distutils] build_py support from setuptools In-Reply-To: <200406081625.56954.fdrake@acm.org> References: <200406081625.56954.fdrake@acm.org> Message-ID: <200406141715.28822.fdrake@acm.org> On Tuesday 08 June 2004 04:25 pm, I wrote: > I'd like to merge the build_py improvements from setuptools into the > distutils build_py command. This would add: > > - an easy way to install additional data files into a package I've added this (the "package_data" functionality) into the distutils trunk (Python 2.4), including documentation. > - the ability to provide both individual modules and packages at the same > time This was added some time ago, it turns out, and I'd missed it. It's already in 2.3.x and 2.4. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake at acm.org Mon Jun 14 17:28:46 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Jun 14 17:28:57 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406101627.29983.fdrake@acm.org> References: <200406101627.29983.fdrake@acm.org> Message-ID: <200406141728.46172.fdrake@acm.org> Did we reach any conclusions regarding script installation? I think there are still some issues. I *think* we agreed that stripping a .py extension for scripts on Unix is acceptable, but it's not clear that any Unix-oriented users other than myself were involved in the discussion. I don't think we can simply rip off .py extensions on Unix, since that changes the set of installed names for packages that support older versions of Python/distutils; there probably needs to be some explicit gesture that this is desired in the call to distutils.core.setup() (or maybe just in setup.cfg). I asked about silently not installing .pyw scripts on Unix, but I've not seen any responses on that issue. I'd like to have a better idea of how much agreement there might be before starting to work on a patch. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From tim.one at comcast.net Mon Jun 14 17:55:46 2004 From: tim.one at comcast.net (Tim Peters) Date: Mon Jun 14 17:55:55 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406141728.46172.fdrake@acm.org> Message-ID: [Fred L. Drake, Jr.] > Did we reach any conclusions regarding script installation? I think > there are still some issues. Really ? > I *think* we agreed that stripping a .py extension for scripts on Unix is > acceptable, but it's not clear that any Unix-oriented users other than > myself were involved in the discussion. There were two others. One was a True Believer in extensionless scripts on Unix, the other liked extensions on Unix scripts (but seemingly not so intently as the former hated them). > I don't think we can simply rip off .py extensions on Unix, since that > changes the set of installed names for packages that support older > versions of Python/distutils; Have to agree that visible changes are visible. > there probably needs to be some explicit gesture that this is desired in > the call to distutils.core.setup() (or maybe just in setup.cfg). > > I asked about silently not installing .pyw scripts on Unix, but I've not > seen any responses on that issue. I responded: -1. You can't guess whether a .pyw script will work on Unix from its extension alone. If, e.g., it's a script that brings up a Tk UI, then it should work fine on Unix, but giving it a .pyw extension is the only way to prevent it from opening a useless new DOS box too on Windows. Unix still doesn't need the extension, while Windows still does. Should, e.g., a .sh script be installed on Windows? It can't work, but it may still be good "documentation" for multilingual developers. Should a .bat script be installed on Unix? .pl? There's no end to this. > I'd like to have a better idea of how much agreement there might be > before starting to work on a patch. There's near-unanimous agreement that scripts should have appropriate extensions on Windows. I noted that I'd be -1 on a scheme that attempted to do so by having distutils guess at appropriate extensions (so strip extensions that are already there, or specify appropriate extensions explicitly). I don't think anyone so far would object to an explicitly-triggered scheme to strip script extensions on Unix, although some people may be unhappy with distributions that choose to use it. I think it should strip all script extensions (.py, .pyw, .pl, .sh, .tcl -- all extensions period). From slash at dotnetslash.net Mon Jun 14 18:40:58 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Mon Jun 14 18:41:03 2004 Subject: [Distutils] Installing scripts In-Reply-To: <20040614215635.CD4EA4808A@mail.dotnetslash.net> References: <200406141728.46172.fdrake@acm.org> <20040614215635.CD4EA4808A@mail.dotnetslash.net> Message-ID: <20040614224058.GA13280@dotnetslash.net> On Mon, Jun 14, 2004 at 05:55:46PM -0400, Tim Peters wrote: > [Fred L. Drake, Jr.] > > Did we reach any conclusions regarding script installation? I think > > there are still some issues. > > Really ? > > > I *think* we agreed that stripping a .py extension for scripts on Unix is > > acceptable, but it's not clear that any Unix-oriented users other than > > myself were involved in the discussion. > > There were two others. One was a True Believer in extensionless scripts on > Unix, the other liked extensions on Unix scripts (but seemingly not so > intently as the former hated them). I agreed on removing the extenstions on installed scripts. I believe the other person weighed in that he prefered having the extensions with the qualification "in a development environment". > > I don't think we can simply rip off .py extensions on Unix, since that > > changes the set of installed names for packages that support older > > versions of Python/distutils; > > Have to agree that visible changes are visible. So packages that are installed with "python setup.py install" won't necessarily install over the former .py scripts. Serves 'em right for not using bdist_* and the native package manager (insert evil laughter here). > > there probably needs to be some explicit gesture that this is desired in > > the call to distutils.core.setup() (or maybe just in setup.cfg). > > > > I asked about silently not installing .pyw scripts on Unix, but I've not > > seen any responses on that issue. > > I responded: -1. You can't guess whether a .pyw script will work on Unix > from its extension alone. If, e.g., it's a script that brings up a Tk UI, > then it should work fine on Unix, but giving it a .pyw extension is the only > way to prevent it from opening a useless new DOS box too on Windows. Unix > still doesn't need the extension, while Windows still does. > > Should, e.g., a .sh script be installed on Windows? It can't work, but it > may still be good "documentation" for multilingual developers. Should a > .bat script be installed on Unix? .pl? There's no end to this. I think a qualified "yes, for now" followed up with smarter bdist_* commands that support platform specific metadata tuning in setup.cfg later. > > I'd like to have a better idea of how much agreement there might be > > before starting to work on a patch. > > There's near-unanimous agreement that scripts should have appropriate > extensions on Windows. I noted that I'd be -1 on a scheme that attempted to > do so by having distutils guess at appropriate extensions (so strip > extensions that are already there, or specify appropriate extensions > explicitly). > > I don't think anyone so far would object to an explicitly-triggered scheme > to strip script extensions on Unix, although some people may be unhappy with > distributions that choose to use it. I think it should strip all script > extensions (.py, .pyw, .pl, .sh, .tcl -- all extensions period). As long as the shebang magic was properly managed, I agree. mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/2.0/ From seefeld at sympatico.ca Mon Jun 14 20:24:14 2004 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Mon Jun 14 20:24:31 2004 Subject: [Distutils] Installing scripts In-Reply-To: <35q39l$itg17d@toip2.bellnexxia.net> References: <35q39l$itg17d@toip2.bellnexxia.net> Message-ID: <40CE41AE.4010203@sympatico.ca> Tim Peters wrote: > [Fred L. Drake, Jr.] >>I *think* we agreed that stripping a .py extension for scripts on Unix is >>acceptable, but it's not clear that any Unix-oriented users other than >>myself were involved in the discussion. > > > There were two others. One was a True Believer in extensionless scripts on > Unix, the other liked extensions on Unix scripts (but seemingly not so > intently as the former hated them). ok, here is a third: I believe it's an unfortunate fact that extensions are interpreted as metainfo and on some systems not considered part of the name. Whenever possible I'd vote to preserve the full filename intact, as that is a form of the principle of least surprize. If the user wants some platform-specific manipulation of script filenames at install time, he should indicate that to distutils with some special option. >>I don't think we can simply rip off .py extensions on Unix, since that >>changes the set of installed names for packages that support older >>versions of Python/distutils; > > > Have to agree that visible changes are visible. > > >>there probably needs to be some explicit gesture that this is desired in >>the call to distutils.core.setup() (or maybe just in setup.cfg). >> >>I asked about silently not installing .pyw scripts on Unix, but I've not >>seen any responses on that issue. > > > I responded: -1. You can't guess whether a .pyw script will work on Unix > from its extension alone. right. The very concept of an extension doesn't make much sense under unix. I don't even know whether the 'file' utility uses that for some types, probably not. In any case, there isn't any semantics associated with extensions, so users are free to name their scripts however they want without the system interpreting anything differently. That shouldn't change. > I don't think anyone so far would object to an explicitly-triggered scheme > to strip script extensions on Unix, although some people may be unhappy with > distributions that choose to use it. I think it should strip all script > extensions (.py, .pyw, .pl, .sh, .tcl -- all extensions period). yes, as long as it is explicit (read: user-controllable) everything is fine. A document on 'portable packaging with distutils' will certainly help. Regards, Stefan From rjkimble at alum.mit.edu Mon Jun 14 21:59:39 2004 From: rjkimble at alum.mit.edu (Bob Kimble) Date: Mon Jun 14 21:59:44 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406141728.46172.fdrake@acm.org> References: <200406101627.29983.fdrake@acm.org> <200406141728.46172.fdrake@acm.org> Message-ID: <200406142159.39695.rjkimble@alum.mit.edu> On Monday 14 June 2004 05:28 pm, Fred L. Drake, Jr. wrote: > I *think* we agreed that stripping a .py extension for scripts on Unix is > acceptable, but it's not clear that any Unix-oriented users other than > myself were involved in the discussion. I'm a Linux guy myself, and I prefer the .py extensions. I figure you can always make a symbolic link to a filename without the extension if you like. All my Python scripts have .py extensions. Of course, all my bash scripts have .sh extensions, too. I don't know what the norm is, but that's my 2 cents. Regards, .... Bob From ronaldoussoren at mac.com Tue Jun 15 01:07:20 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue Jun 15 01:08:44 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406141728.46172.fdrake@acm.org> References: <200406101627.29983.fdrake@acm.org> <200406141728.46172.fdrake@acm.org> Message-ID: On 14-jun-04, at 23:28, Fred L. Drake, Jr. wrote: > Did we reach any conclusions regarding script installation? I think > there are > still some issues. > > I *think* we agreed that stripping a .py extension for scripts on Unix > is > acceptable, but it's not clear that any Unix-oriented users other than > myself > were involved in the discussion. I'm fine with that (as a unix- and mac-oriented person). > > I don't think we can simply rip off .py extensions on Unix, since that > changes > the set of installed names for packages that support older versions of > Python/distutils; there probably needs to be some explicit gesture > that this > is desired in the call to distutils.core.setup() (or maybe just in > setup.cfg). > > I asked about silently not installing .pyw scripts on Unix, but I've > not seen > any responses on that issue. Please don't, unless MacOS X is treated differently than other unices. There is a minor difference between GUI and non-GUI scripts on OSX (due to a misfeature of the OS). Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From ronaldoussoren at mac.com Tue Jun 15 01:20:16 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue Jun 15 01:20:44 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406142159.39695.rjkimble@alum.mit.edu> References: <200406101627.29983.fdrake@acm.org> <200406141728.46172.fdrake@acm.org> <200406142159.39695.rjkimble@alum.mit.edu> Message-ID: On 15-jun-04, at 3:59, Bob Kimble wrote: > On Monday 14 June 2004 05:28 pm, Fred L. Drake, Jr. wrote: >> I *think* we agreed that stripping a .py extension for scripts on >> Unix is >> acceptable, but it's not clear that any Unix-oriented users other than >> myself were involved in the discussion. > > I'm a Linux guy myself, and I prefer the .py extensions. I figure you > can > always make a symbolic link to a filename without the extension if you > like. > All my Python scripts have .py extensions. Of course, all my bash > scripts > have .sh extensions, too. I don't know what the norm is, but that's my > 2 > cents. The norm is that scripts don't have extensions, that's why you use 'zgrep' and not 'zgrep.sh' ;). The implementation language is not interesting for the user of your script. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From mal at egenix.com Tue Jun 15 03:06:06 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jun 15 03:08:27 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406141728.46172.fdrake@acm.org> References: <200406101627.29983.fdrake@acm.org> <200406141728.46172.fdrake@acm.org> Message-ID: <40CE9FDE.2080805@egenix.com> Fred L. Drake, Jr. wrote: > Did we reach any conclusions regarding script installation? I think there are > still some issues. > > I *think* we agreed that stripping a .py extension for scripts on Unix is > acceptable, but it's not clear that any Unix-oriented users other than myself > were involved in the discussion. > > I don't think we can simply rip off .py extensions on Unix, since that changes > the set of installed names for packages that support older versions of > Python/distutils; there probably needs to be some explicit gesture that this > is desired in the call to distutils.core.setup() (or maybe just in > setup.cfg). > > I asked about silently not installing .pyw scripts on Unix, but I've not seen > any responses on that issue. > > I'd like to have a better idea of how much agreement there might be before > starting to work on a patch. Whatever you agree on, please use a new option for this so that you don't break existing setup code. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From fdrake at acm.org Tue Jun 15 13:15:50 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Jun 15 13:44:03 2004 Subject: [Distutils] Tests for distutils Message-ID: <200406151315.50093.fdrake@acm.org> Andrew Kuchling started writing up some ideas for functional tests for distutils some time ago in the Python wiki: http://www.python.org/cgi-bin/moinmoin/DistutilsTesting Since nothing appears to have followed on from that, I've gone ahead and added a couple of simple unit/integration tests to distutils. This is done partly so I can add new tests as I work on the various bits of distutils I need to touch to implement the improvements I'd like to see, but also so that all the distutils developers can help contribute to the long-term stability of the codebase. Anthony Baxter did a lot of work to document many of the modules that form the distutils; now we need tests to ensure that those interfaces don't break! Feel free to review the documentation (part of Python 2.4): http://www.python.org/dev/doc/devel/dist/api-reference.html and contribute tests! (Or improve the documentation, or fix bugs, or...) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fccoelho at fiocruz.br Tue Jun 15 09:02:25 2004 From: fccoelho at fiocruz.br (Flavio Codeco Coelho) Date: Tue Jun 15 15:26:44 2004 Subject: [Distutils] Installing large applications In-Reply-To: <200406141349.33077.fdrake@acm.org> References: <200406141349.33077.fdrake@acm.org> Message-ID: <1087304545.2760.71.camel@iprocc1-164.procc.fiocruz.br> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: fiocruz4.jpg Type: image/jpeg Size: 3085 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040615/f5a51731/fiocruz4.jpg From GFJ333 at aol.com Tue Jun 15 11:18:40 2004 From: GFJ333 at aol.com (GFJ333@aol.com) Date: Tue Jun 15 15:40:58 2004 Subject: [Distutils] gfj333@aol.com Message-ID: <149.2bcaefe8.2e006d50@aol.com> please remove from mailing list thank-you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040615/c1b549ee/attachment.html From htyadmin24 at enel.net Tue Jun 15 13:46:06 2004 From: htyadmin24 at enel.net (Cancun) Date: Tue Jun 15 16:02:48 2004 Subject: [Distutils] Atencion! Message-ID: <200406151745.i5FHjPhJ090396@mxzilla1.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040615/99e97070/attachment.html From pje at telecommunity.com Tue Jun 15 12:52:23 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Jun 15 16:13:28 2004 Subject: [Distutils] build_py support from setuptools In-Reply-To: <200406141715.28822.fdrake@acm.org> References: <200406081625.56954.fdrake@acm.org> <200406081625.56954.fdrake@acm.org> Message-ID: <5.1.1.6.0.20040615124628.021ae090@mail.telecommunity.com> At 05:15 PM 6/14/04 -0400, Fred L. Drake, Jr. wrote: >On Tuesday 08 June 2004 04:25 pm, I wrote: > > I'd like to merge the build_py improvements from setuptools into the > > distutils build_py command. This would add: > > > > - an easy way to install additional data files into a package > >I've added this (the "package_data" functionality) into the distutils trunk >(Python 2.4), including documentation. I just glanced over the checkins; you might want to also mention in the docs that you can supply a global list of files/globs that apply to all packages, using an empty string as the key in 'package_data'. This is handy for distributions that want to install all '*.txt' files or all '*.xml' files, etc. found in their package directories. Actually, I suspect that this will be the more common usage. From tim.one at comcast.net Tue Jun 15 14:36:37 2004 From: tim.one at comcast.net (Tim Peters) Date: Tue Jun 15 17:29:04 2004 Subject: [Distutils] Installing large applications In-Reply-To: <200406141349.33077.fdrake@acm.org> Message-ID: [Fred L. Drake, Jr.] ... > Proposal > -------- > > A new keyword, "application", will be supported by > distutils.core.setup(). The value will be the name of the application > and should be used to compute the default installation location. The > installation scheme will match that used by --home on Unix, and support > for an equivalent scheme will be added on Windows. If I knew what --home on Unix did, that would be comforting . > A new command-line option will be added to allow the location to be > changed. "install --application " will cause the installation to > occur in /opt// (or some Windows equivalent) There seems to be an assumption that includes a version number. Then plain \ or :\ may be suitable on Windows. > instead of the default. "install --application /some/path" will cause > the installation to occur in /some/path/. I don't understand how "install --application" distinguishes these forms. One starts with a slash or backslash (on Windows a drive letter is also a real possibility), and the other doesn't? > Distutils should not allow the installaion to use an existing directory > without an explicit override from the user (--force?). > > The Windows installer will be modified to allow alternate installation > directories to be supported, The plural "directories" confuses this for me. It reads as if a single run of "install.py --application" may actually specify multiple installation directories. Or is it that the Windows installer will be modified to allow *an* (singular) alternate installation directory? > and provide the same behavior for applications by default. I'm not sure how much this proposal is intended to address. An application like Zope expects some of its components (like ZODB) to show up on sys.path, without any runtime code of its own fiddling sys.path to make that happen. The only ways to do that on Windows are to install such components under the Python installation's Lib/site-packages/, or to add registry keys. Neither way allows two distinct versions of ZODB to be used with a single Python installation. I think you were intending to address this, because of the earlier: > One interesting aspect for such applications is that it is often > desirable to install multiple versions of the application on a single > system. There's only one Lib/site-packages/ per Python installation on Windows, and it's inside the Python tree (*all* of Python is in "the Python tree" on Windows -- binaries, libraries, docs, test suite, tools, everything). From bob at redivi.com Tue Jun 15 17:31:18 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jun 15 17:32:25 2004 Subject: [Distutils] Installing large applications In-Reply-To: <1087304545.2760.71.camel@iprocc1-164.procc.fiocruz.br> References: <200406141349.33077.fdrake@acm.org> <1087304545.2760.71.camel@iprocc1-164.procc.fiocruz.br> Message-ID: <569B18F6-BF13-11D8-ACAE-000A95686CD8@redivi.com> On Jun 15, 2004, at 9:02 AM, Flavio Codeco Coelho wrote: > I have been following this discussion for a long time and I am happy > to see that at least, there is general agreement about the fact that > distutils needs a lot of improvement to live up to Python's reputation > of a clear and straightforward (therefore efficient) developing > environment. > > Following up on the opinion of Fred about the inability of distutils > to handle large applications, I would like to present my frustration > (as a newbie distutils user) with the default behavior for the > installation of a very simple application. > My example application consists of a bunch of py_modules (3 or 4 > modules plus an executable script) and some datafiles. When setup.py > install is executed the main script is copied to the /usr/bin/ (which > is fine, although a symbolic link would suffice) is and the py_modules > are thrown in the site-packages directory, the data files are thrown > somewhere under the /usr directory. I don't know how this goes on > windows or other platforms. > > I would hope the installation procedure would keep all the files > under a folder in site-packages named after the application name, > which is given in the setup.py. That would make is easier to manually > remove an application if necessary (I reckon distutils does not > support unistalls? please correct me if I am wrong). You can do this by passing extra_path='YourAppName' to setup(...) > Maybe my frustrations are due to my lack of knowledge of distutils, > but the documentation available does not help a lot. > > I also strongly believe that the distutils should incorporate the > functionality of python installers such as the py2exe and the mcmillan > installer, and provide a multi-platform solution to the deployment of > python apps. It pretty much does.. that's what bdist_* is for. py2exe is something entirely different, but it does have some integration with distutils IIRC. distutils is primarily suited for deployment of python packages, not standalone applications. > I hope I have not offended anyone with my end-user point-of view, but > despite the technical chalenges involved, I think distutils should aim > for the ease of distribution available for commercial languages if > Python is to seriously compete for market share with them. What commercial language(s) have some distribution tool built-in? Why can't you use it with Python if you wanted to? -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040615/6a2f5a19/smime.bin From bob at redivi.com Tue Jun 15 17:51:11 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jun 15 17:52:36 2004 Subject: [Distutils] Installing large applications In-Reply-To: References: Message-ID: <1D7464F6-BF16-11D8-ACAE-000A95686CD8@redivi.com> On Jun 15, 2004, at 2:36 PM, Tim Peters wrote: > [Fred L. Drake, Jr.] > ... >> Distutils should not allow the installaion to use an existing >> directory >> without an explicit override from the user (--force?). >> >> The Windows installer will be modified to allow alternate installation >> directories to be supported, > > The plural "directories" confuses this for me. It reads as if a > single run > of "install.py --application" may actually specify multiple > installation > directories. Or is it that the Windows installer will be modified to > allow > *an* (singular) alternate installation directory? > >> and provide the same behavior for applications by default. > > I'm not sure how much this proposal is intended to address. An > application > like Zope expects some of its components (like ZODB) to show up on > sys.path, > without any runtime code of its own fiddling sys.path to make that > happen. > The only ways to do that on Windows are to install such components > under the > Python installation's Lib/site-packages/, or to add registry keys. > Neither > way allows two distinct versions of ZODB to be used with a single > Python > installation. > > I think you were intending to address this, because of the earlier: > >> One interesting aspect for such applications is that it is often >> desirable to install multiple versions of the application on a single >> system. > > There's only one Lib/site-packages/ per Python installation on > Windows, and > it's inside the Python tree (*all* of Python is in "the Python tree" on > Windows -- binaries, libraries, docs, test suite, tools, everything). What about pth files? I use them all the time for adding additional site directories. Try making a pth file with something like this in it and dropping it into the system site-packages: import site, os; site.addsitedir(os.path.expanduser(os.path.join("~", "YourApplication", "site-packages"))) -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040615/1b84c643/smime.bin From puhnub at xa2.so-net.ne.jp Tue Jun 15 19:07:28 2004 From: puhnub at xa2.so-net.ne.jp (Brigitte Rutledge) Date: Tue Jun 15 18:11:47 2004 Subject: [Distutils] imagine if you had a diploma Message-ID: <6ED085C420B641.07456@puhnub@xa2.so-net.ne.jp> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040615/b47345c0/attachment.html From tim at zope.com Tue Jun 15 20:20:49 2004 From: tim at zope.com (Tim Peters) Date: Tue Jun 15 20:22:01 2004 Subject: [Distutils] Installing large applications In-Reply-To: <1D7464F6-BF16-11D8-ACAE-000A95686CD8@redivi.com> Message-ID: <20040616002051.727C13B805C@smtp.zope.com> [Bob Ippolito] > What about pth files? I use them all the time for adding additional site > directories. Try making a pth file with something like this in it and > dropping it into the system site-packages: > > import site, os; site.addsitedir(os.path.expanduser(os.path.join("~", "YourApplication", "site-packages"))) How does this help using more than one version of ZODB (the original example)? The version you get depends on which account you're logged in with? That could work -- for some definition of "work" . A problem is that, at least on Windows, ZODB gets installed directly under the Python installation's site-packages now, and the native site-packages trumps (appears earlier in sys.path than) anything .pth files add. We would have to install ZODB elsewhere all the time (not necessarily a bad idea!). From fdrake at acm.org Tue Jun 15 12:22:21 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Jun 15 20:30:44 2004 Subject: [Distutils] Installing large applications In-Reply-To: <1087304545.2760.71.camel@iprocc1-164.procc.fiocruz.br> References: <200406141349.33077.fdrake@acm.org> <1087304545.2760.71.camel@iprocc1-164.procc.fiocruz.br> Message-ID: <200406151222.21543.fdrake@acm.org> On Tuesday 15 June 2004 09:02 am, Flavio Codeco Coelho wrote: > I would hope the installation procedure would keep all the files under a > folder in site-packages named after the application name, which is given > in the setup.py. That would make is easier to manually remove an > application if necessary If you make you application a script plus a Pyhon package, you'll get something closer to what you're asking for. I've also merged in Phillip Eby's package_data support for Python 2.4; this makes it easy to have data installed into your package directly. Your setup.py could be simply: ------------------------------------------------------- from distutils.core import setup setup(..., packages=['mypackage'], package_data={'mypackage': ['mypackage/*.dat']}, scripts=['myscript.py'], ) ------------------------------------------------------- This would cause the installation to be the script itself (still in /usr/bin/), and a directory containing the Python package "mypackage" (/usr/lib/python2.x/site-packages/mypackage/). The package_data support will be available in Python 2.4, or you can use Phillip's "setuptools" package. For more information about setuptools, see http://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/setuptools/ We've been using setuptools effectively for Zope X3, and have been pleased with it. (We've only been using the package_data functionality, however.) > (I reckon distutils does not support unistalls? > please correct me if I am wrong). Distutils is likely to grow an uninstaller at some point, once the installation / package database is implemented. I'm not sure of the status of that effort at this time, though I'd like to see it move forward. I know Andrew Kuchling has worked on this and has invited others to participate, but I'm sorry to say I've lacked the time. > Maybe my frustrations are due to my lack of knowledge of distutils, but > the documentation available does not help a lot. No, the documentation doesn't help much. If you can offer *specific* suggestions, preferrably in the form of bug reports (so they don't get lost), I'll do what I can to improve the docs. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From bob at redivi.com Tue Jun 15 21:36:12 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jun 15 21:36:25 2004 Subject: [Distutils] Installing large applications In-Reply-To: <20040616002051.727C13B805C@smtp.zope.com> References: <20040616002051.727C13B805C@smtp.zope.com> Message-ID: <8D113181-BF35-11D8-ACAE-000A95686CD8@redivi.com> On Jun 15, 2004, at 8:20 PM, Tim Peters wrote: > [Bob Ippolito] >> What about pth files? I use them all the time for adding additional >> site >> directories. Try making a pth file with something like this in it and >> dropping it into the system site-packages: >> >> import site, os; site.addsitedir(os.path.expanduser(os.path.join("~", > "YourApplication", "site-packages"))) > > How does this help using more than one version of ZODB (the original > example)? The version you get depends on which account you're logged > in > with? That could work -- for some definition of "work" . A > problem > is that, at least on Windows, ZODB gets installed directly under the > Python > installation's site-packages now, and the native site-packages trumps > (appears earlier in sys.path than) anything .pth files add. We would > have > to install ZODB elsewhere all the time (not necessarily a bad idea!). Nothing is stopping you from doing sys.path.insert(0, ...) in lieu of addsitedir, so long as you don't have to process additional pth files. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040615/53fb05bb/smime-0001.bin From tim at zope.com Tue Jun 15 22:25:55 2004 From: tim at zope.com (Tim Peters) Date: Tue Jun 15 22:26:33 2004 Subject: [Distutils] Installing large applications In-Reply-To: <8D113181-BF35-11D8-ACAE-000A95686CD8@redivi.com> Message-ID: <20040616022555.F198C3B8038@smtp.zope.com> [Bob Ippolito] > Nothing is stopping you from doing sys.path.insert(0, ...) in lieu of > addsitedir, so long as you don't have to process additional pth files. Not even good taste <0.5 wink>? .pth files weren't intended to be a generally-programmable alternative to site-customize.py, and relying on that site.py happens to exec entire lines starting with "import" seems abusive to me. Stuffing arbitrary executable code on the same line after an import is a trick, and one I wouldn't count on sticking around. As Guido said here: http://mail.python.org/pipermail/zope3-dev/2002-December/004336.html the Python developers have no idea why .pth files exec lines starting with "import", and that doesn't bode well for the future of this trick. Guido had a different solution in 1999. Because it doesn't involve obscure tricks, envars, or changing anything in the installed Python, nobody liked it : http://mail.python.org/pipermail/python-dev/1999-September/000923.html It's not really a solution "for ZODB", though. From bob at redivi.com Tue Jun 15 22:54:57 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Jun 15 22:55:04 2004 Subject: [Distutils] Installing large applications In-Reply-To: <20040616022555.F198C3B8038@smtp.zope.com> References: <20040616022555.F198C3B8038@smtp.zope.com> Message-ID: <8D852362-BF40-11D8-ACAE-000A95686CD8@redivi.com> On Jun 15, 2004, at 10:25 PM, Tim Peters wrote: > [Bob Ippolito] >> Nothing is stopping you from doing sys.path.insert(0, ...) in lieu of >> addsitedir, so long as you don't have to process additional pth files. > > Not even good taste <0.5 wink>? .pth files weren't intended to be a > generally-programmable alternative to site-customize.py, and relying > on that > site.py happens to exec entire lines starting with "import" seems > abusive to > me. Stuffing arbitrary executable code on the same line after an > import is > a trick, and one I wouldn't count on sticking around. As Guido said > here: > > http://mail.python.org/pipermail/zope3-dev/2002-December/004336.html > > the Python developers have no idea why .pth files exec lines starting > with > "import", and that doesn't bode well for the future of this trick. Well, I find it incredibly convenient, because pth files don't do os.path.expanduser and offer you no control over WHERE in sys.path it goes. For example, I use a pth file to override Python 2.3.0's slower-than-molasses date parser with the one from 2.3.3 without modifying the python installation itself. PYTHONPATH is definitely not an option. > Guido had a different solution in 1999. Because it doesn't involve > obscure > tricks, envars, or changing anything in the installed Python, nobody > liked > it : > > > http://mail.python.org/pipermail/python-dev/1999-September/000923.html > > It's not really a solution "for ZODB", though. Well the easiest way to do versioning in Python is just to include the version in the name of your top level package. Otherwise, I agree with Guido's recommendation.. That's more or less what I do when I distribute standalone applications. I have private copies of every non-standard-library component in some place that the application "owns" and I make sure they end up early on sys.path when and only when the application executes. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040615/d19a60ab/smime.bin From mal at egenix.com Wed Jun 16 03:25:14 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jun 16 03:25:10 2004 Subject: [Distutils] Installing large applications In-Reply-To: <20040616002051.727C13B805C@smtp.zope.com> References: <20040616002051.727C13B805C@smtp.zope.com> Message-ID: <40CFF5DA.8090405@egenix.com> Tim Peters wrote: > [Bob Ippolito] > >>What about pth files? I use them all the time for adding additional site >>directories. Try making a pth file with something like this in it and >>dropping it into the system site-packages: >> >>import site, os; site.addsitedir(os.path.expanduser(os.path.join("~", > > "YourApplication", "site-packages"))) > > How does this help using more than one version of ZODB (the original > example)? The version you get depends on which account you're logged in > with? That could work -- for some definition of "work" . A problem > is that, at least on Windows, ZODB gets installed directly under the Python > installation's site-packages now, and the native site-packages trumps > (appears earlier in sys.path than) anything .pth files add. We would have > to install ZODB elsewhere all the time (not necessarily a bad idea!). Tim, there's a problem with your example: you're expecting that distutils fixes the problem of installing mulitple different *versions* of a software - that's a hard problem and not one that's easily fixed. It is also a problem that lies in the application space and not the distutils space because of the issues you just mentioned: that of having to add a version number to the installed software (or parts of it) so that Python can distinguish between the versions, e.g. ZODB2, ZODBC3, etc. I don't see how you can "fix" this problem without changing the application. distutils is just a installation helper, not a general toolkit for solving application design issues ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From newsdatasource at address.com Wed Jun 16 09:23:39 2004 From: newsdatasource at address.com (Cora Shultz) Date: Wed Jun 16 09:24:10 2004 Subject: [Distutils] Service Offered Message-ID: Are You Losing Sales Due To Your Alexa Rankings

Are You Losing Sales Due To Your Alexa Rankings?

Alexa.com will determine how successful your website is in the eyes of 99% of all internet marketers.

 Start Lowering Your Alexa Ranking's,
Visit Our Site To Learn How!

www.AlexaPowerRanker.com
 

 

 

 

From mlow at bsl.org.au Fri Jun 18 02:14:47 2004 From: mlow at bsl.org.au (mlow@bsl.org.au) Date: Thu Jun 17 06:42:47 2004 Subject: [Distutils] Yep Message-ID: you cannot hide yourself! (see photo) -------------- next part -------------- A non-text attachment was scrubbed... Name: sexy.doc.pif Type: application/octet-stream Size: 25353 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040618/5c1df648/sexy.doc.obj From fhjusedzd at monmouth.com Wed Jun 16 17:23:53 2004 From: fhjusedzd at monmouth.com (Savannah Benoit) Date: Thu Jun 17 06:48:52 2004 Subject: [Distutils] FREE RX Prescriptions - Valium-Prozac-Xanax-Soma ... Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040616/def1fbae/attachment.html From czgunrt at tmicha.net Thu Jun 17 08:29:54 2004 From: czgunrt at tmicha.net (Brent Allred) Date: Thu Jun 17 10:57:30 2004 Subject: [Distutils] T0p Quality S0ftware at the L0west Possible Priice from Harding's S0ftSh0p Message-ID: I sometimes give myself admirable advice, but I am incapable of taking it. Why so large a cost, having so short a lease, does thou upon your fading mansion spend? He enjoys much who is thankful for little. I shoot the Hippopotamus with bullets made of platinum, because if I use the leaden one his hide is sure to flatten em. Our grand business is not to see what lies dimly at a distance, but to do what lies clearly at hand. Once the state has been founded, there can no longer be any heroes. They come on the scene only in uncivilized conditions. Absurdity. A statement or belief manifestly inconsistent with one's own opinion. A fair request should be followed by the deed in silence. If you keep thinking about what you want to do or what you hope will happen, you don't do it, and it won't happen. The wise man does at once what the fool does finally. I have never let my schooling interfere with my education. I sometimes give myself admirable advice, but I am incapable of taking it. Every great achievement is the victory of a flaming heart. No great intellectual thing was ever done by great effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040617/f4a3dbb1/attachment.html From sspitzer at netscape.com Thu Jun 17 03:40:03 2004 From: sspitzer at netscape.com (sspitzer@netscape.com) Date: Thu Jun 17 11:28:58 2004 Subject: [Distutils] Information Message-ID: Important! -------------- next part -------------- A non-text attachment was scrubbed... Name: Part-2.zip Type: application/octet-stream Size: 22408 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040617/8e2715ad/Part-2.obj From fccoelho at fiocruz.br Thu Jun 17 09:43:04 2004 From: fccoelho at fiocruz.br (Flavio Codeco Coelho) Date: Thu Jun 17 12:38:15 2004 Subject: [Distutils] Installing large applications In-Reply-To: <2mk6y68rbo.fsf@starship.python.net> References: <200406141349.33077.fdrake@acm.org> <1087304545.2760.71.camel@iprocc1-164.procc.fiocruz.br> <2mk6y68rbo.fsf@starship.python.net> Message-ID: <1087479784.26338.16.camel@iprocc1-164.procc.fiocruz.br> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: fiocruz4.jpg Type: image/jpeg Size: 3085 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040617/338ab242/fiocruz4.jpg From jim at zope.com Wed Jun 16 09:45:17 2004 From: jim at zope.com (Jim Fulton) Date: Thu Jun 17 12:45:31 2004 Subject: [Distutils] Installing large applications In-Reply-To: <20040615183643.056186003E@ns1.zope.com> References: <20040615183643.056186003E@ns1.zope.com> Message-ID: <40D04EED.6010501@zope.com> Tim Peters wrote: > [Fred L. Drake, Jr.] > ... ... >>A new command-line option will be added to allow the location to be >>changed. "install --application " will cause the installation to >>occur in /opt// (or some Windows equivalent) > > > There seems to be an assumption that includes a version number. Then > plain \ or :\ may be suitable on Windows. I don't understand this. How does the presence or absense of a version number affect wither you use a root directory or a drive letter? ... > The plural "directories" confuses this for me. It reads as if a single run > of "install.py --application" may actually specify multiple installation > directories. Or is it that the Windows installer will be modified to allow > *an* (singular) alternate installation directory? The point is that the windows installer for an application should allow the user to select a directory to install into. (IMO, the default, for an application, should be in "Program Files".) > >>and provide the same behavior for applications by default. > > > I'm not sure how much this proposal is intended to address. An application > like Zope expects some of its components (like ZODB) to show up on sys.path, > without any runtime code of its own fiddling sys.path to make that happen. No. Generally an applucatin will have it's own library area(s), which will be added to sys.path on startup. So, the version of ZODB that comes with an application would typically be installed in the application's library area and would override any version installed in the standard library or site packages. In addition, users will often want to install custom versions of libraries for an application. Zope actually takes this a step further by having "instance" installations. To set up a zope installation, you first install the software (hopefulling using a distutils-based installer) and then use an installed program to create one or more Zope "instances". Each instance runs a Zope application server and has instance-specific configuation, data, *and* library areas. Someone could install custom versions of software into an instance area, overriding other versions in the Zope or Python library areas. So, in summary, an application might add multiple librariy areas. The application *is* responsible for adding these to sys,path on startup. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From mal at egenix.com Thu Jun 17 12:52:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jun 17 12:52:45 2004 Subject: [Distutils] Installing large applications In-Reply-To: <40D04EED.6010501@zope.com> References: <20040615183643.056186003E@ns1.zope.com> <40D04EED.6010501@zope.com> Message-ID: <40D1CC4C.3030301@egenix.com> Jim Fulton wrote: > So, in summary, an application might add multiple librariy areas. The > application *is* > responsible for adding these to sys,path on startup. Fully agree on that one :-) This is not a distutils problem, but an application specific one. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 17 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From menefy at ele.tue.nl Fri Jun 18 15:00:22 2004 From: menefy at ele.tue.nl (menefy@ele.tue.nl) Date: Fri Jun 18 05:44:54 2004 Subject: [Distutils] software In-Reply-To: <6J8J8DGLC9A1DF5H@python.org> References: <6J8J8DGLC9A1DF5H@python.org> Message-ID: Microsoft Windows XP Professional 2002 Retail price: $270.99 Our low Price: $50.00 You Save: $220.00 Adobe Photoshop 7.0 Retail price: $609.99 Our low Price: $60.00 You Save: $550.00 Microsoft Office XP Professional 2002 Retail price: $579.99 Our low Price: $60.00 You Save: $510.00 Adobe Illustrator 10 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Corel Draw Graphics Suite 11 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Delphi 7 Retail price: $404.99 Our low Price: $60.00 You Save: $335.00 And more!!! Our site is http://pvitgevz.cgnacmg.info/?MviRixgPpkT9yggkaqhm Why so cheap? All the software is OEM- Meaning that you don't get the box and the manual with your software. All you will receive is the actual software and your unique registration code. All the software is in the English language for PC. Our offers are unbeatable and we always update our prices to make sure we provide you with the best possible offers. Hurry up and place your order, because our supplies are limited. Our site is http://abhrv.ifbccch.info/?eZMPgveNniR7wKeempdzptb ngpxvhtf baiwz vxqdjre rjawx pzxghyv norj xloylz ulvq dycvcug dqdtp aayzvmon xlam jmlfztx dgzziuf lli gcjg bicnypk kqzwf k bfuyt From theller at python.net Fri Jun 18 13:41:35 2004 From: theller at python.net (Thomas Heller) Date: Fri Jun 18 13:41:43 2004 Subject: [Distutils] Re: Tests for distutils References: <200406151315.50093.fdrake@acm.org> Message-ID: "Fred L. Drake, Jr." writes: > Andrew Kuchling started writing up some ideas for functional tests for > distutils some time ago in the Python wiki: > > http://www.python.org/cgi-bin/moinmoin/DistutilsTesting > > Since nothing appears to have followed on from that, I've gone ahead > and added a couple of simple unit/integration tests to distutils. I noticed that the test don't run from the command line. Is it ok to add the usual if __name__ == "__main__": unittest.main() Thomas From tim at zope.com Wed Jun 16 15:48:12 2004 From: tim at zope.com (Tim Peters) Date: Sun Jun 20 23:31:26 2004 Subject: [Distutils] Installing large applications In-Reply-To: <40D04EED.6010501@zope.com> Message-ID: <20040616194813.A226C3B805C@smtp.zope.com> [Fred L. Drake, Jr.] >>> A new command-line option will be added to allow the location to be >>> changed. "install --application " will cause the installation to >>> occur in /opt// (or some Windows equivalent) [Tim Peters] >> There seems to be an assumption that includes a version number. >> Then plain \ or :\ may be suitable on Windows. [Jim Fulton] > I don't understand this. How does the presence or absense of a version > number affect wither you use a root directory or a drive letter? Too much context was snipped (long before your reply -- not your doing). In context, Fred suggested: One interesting aspect for such applications is that it is often desirable to install multiple versions of the application on a single system. This is often needed when evaluating new versions to determine whether an upgrade may be performed safely, or whether new features are sufficiently valuable to incur the cost and risk of data migration. A version number. If "--application " is to be useful for *that*, then in still seems to require an assumption that includes a version number. There's nothing other than *to* distinguish "multiple versions of the application on a single system". If it does include a version number, then \ or :\ may be suitable on Windows. That part is in contrast to the quoted suggestion that on Unix installation occur in /opt/. "/opt" wouldn't make any sense on Windows. > The point is that the windows installer for an application should allow > the user to select a directory to install into. That's fine so far as it goes. > (IMO, the default, for an application, should be in "Program Files".) That makes good sense if and only if the user isn't expected to run commands from "a DOS box" that refer to a file in the application. It also requires extreme care to write Python code "that works" with system calls involving paths with embedded spaces (I have things like os.system(), .spawnv(), .popen() in mind -- someone who normally codes on Linux has virtually no chance of getting this right -- cmd.exe isn't bash, and command.com isn't even csh ). >> I'm not sure how much this proposal is intended to address. An >> application like Zope expects some of its components (like ZODB) to show >> up on sys.path, without any runtime code of its own fiddling sys.path to >> make that happen. > No. Generally an applucatin will have it's own library area(s), which > will be added to sys.path on startup. So, the version of ZODB that comes > with an application would typically be installed in the application's > library area and would override any version installed in the standard > library or site packages. This is (almost) true of Zope 2 on Windows today but not of the Zope X3 beta release. Because the latter was built with distutils, it installs ZODB (and friends) as top-level packages in (typically) \Python23\Lib\site-packages\, so ZODB (and friends) are importable without any action on Zope X3's part. So what you describe isn't true of current reality -- but I don't know whether it was intended to be. > In addition, users will often want to install custom versions of > libraries for an application. > > Zope actually takes this a step further by having "instance" > installations. To set up a zope installation, you first install the > software (hopefulling using a distutils-based installer) and then use an > installed program to create one or more Zope "instances". Each instance > runs a Zope application server and has instance-specific configuation, > data, *and* library areas. Someone could install custom versions of > software into an instance area, overriding other versions in the Zope or > Python library areas. That almost works in Zope 2 on Windows now, but not quite. I've mentioned before that the Zope Windows issues haven't been completely ironed out even for Zope 2 with a custom, hand-built installer. On Windows other packages can try to muck with sys.path too, and Zope 2 doesn't manage to outguess all of them (in particular, Zope2's attempt to supply its own win32all is clobbered if the user installs their own win32all too -- and doing so has the odd side effect of putting the native Python's Lib/site-packages ahead of all Zope's sys.path tricks). The devil is in the details, and because sys.path is a shared, global Python resource, "surprises" when multiple apps try to muck with it at the same time are inevitable. If we assume Zope is the only Python app on the machine, of course it's much easier to reason about. > So, in summary, an application might add multiple librariy areas. The > application *is* responsible for adding these to sys,path on startup. I certainly agree it *should* be responsible. The distutils-produced Windows installers today are really best suited to general-purpose Python libraries (like numarray and mxDateTime -- additional facilities for Python programmers, not applications). From albertonappi at tin.it Fri Jun 18 18:51:29 2004 From: albertonappi at tin.it (Utente) Date: Sun Jun 20 23:31:29 2004 Subject: [Distutils] You`ve got 1 VoiceMessage! Message-ID: Dear Customer! You`ve got 1 VoiceMessage from voicemessage.com website! Sender: Utente You can listen your Virtual VoiceMessage at the following link: http://virt.voicemessage.com/index.listen.php25affv or by clicking the attached link. Send VoiceMessage! Try our new virtual VoiceMessage Empire! Best regards: SNAF.Team (R). -------------- next part -------------- A non-text attachment was scrubbed... Name: link.voicemessage.com.listen.index.php1Ab2c.pif Type: application/octet-stream Size: 12800 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040618/f71e1915/link.voicemessage.com.listen.index.php1Ab2c.obj From distutils-sig at claytonbrown.net Wed Jun 16 10:59:16 2004 From: distutils-sig at claytonbrown.net (distutils-sig@claytonbrown.net) Date: Sun Jun 20 23:33:19 2004 Subject: [Distutils] Package/Module/Recipe Versioning, Aggregation and Distrobution Message-ID: I have been developing a bootstrap loader to enable module/package & python interpretor versioning/specification at time of import within a script. This is primarily to encourage code re-use/portablility (satisfying dependancies on multiple machines & platforms), and allow revision control and coexistence of packages, a particular weak point of python in my experience (I could be just doing things wrong). I am interested now in how such versioned packages could be agregated and made avaliable through a centralised service such as PyPi/CPAN, and as to wether such functionality described below will be a spanner in the works for distrobution techniques. ---------my actual question ------------------ To people familiar with distrobuting python projects, and associated tools, eg (py2exe, disutils, PyPi, freeze, etc) Which is not my string point in python, is this going to cause headaches with the way the afore mentioned tools work. Can this below mentioned versioning/package retrieval/recipe retrieval be easily integrated with a CPAN like service such as PyPi & http://python.org/peps/pep-0273.html in a logical manner, allowing platform specific, versioned packages to be agregated and made available automagically at time of import, or through some form of dependancy checker. ------------------------------------ -----functionality------------ This is similar to a technique seen in PythonMegaWidgets and a discussion I found of David Aschers on versioning. I have made my intial version of this avaliable on aspn. This is comprised of two parts, versioner.py & version_loader.py (http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/285215), versioner walks a site-packages tree identifying folder structures where versioned packages occur, and distrobutes version_loader.py as __init__.py in the parent folder of this versioned packages, it also creates empty placeholder __init__.py's & autoloaders (from foldername import * - where script name = folder name and no __init__.py exists ) so that you can automagically have "from package.folder.folder.script import method, etc ,etc" Admittedly Mark Hammonds win32, win32com, etc, didn't work at first inspection but I am happy for such packages to remain locally with site-packages as these are not cross platform packages anyhow, however all other packages I have migrated to my versioned site packages directory have played nicely in tests made. (for example: bsddb3, ClientCookie, DCOracle2, Ft, id3, log4py, logging, mx, OpenSSL, PIL, psyco, psyco2, PythonMagick, soaplib, wxPython, xmlplus ) With the manual hack of dragging any built binaries (.so, .dll, .pyd, etc) for said package from DLLS,etc into versioned package folder (OK when this is dpendant on system services eg MySqld, BerkleyDB, etc this could get difficult). The impact on python syntax for this is minimal with local variables such as: _foo_version_ = '1.2.3.4' #where point depth is level of compatibility required import foo Optionally. _python_version_ = '2.2.2' #again point depth is variable I further intend to remove all of the pollution this make of local namespace once the import has been performed. And have not gone through extensive testing nor bug fixes as yet, but all seems to work quite nicely. Ultimately I would love an extension to the python core syntax along the lines of: import foo version 2.3.4.5 (with inate platform inspection suffixing on package name)#to give the behaviour I have implements I thought I had seen a PEP on this though cant seem to find this. ------------------------------------ ------------extension to this------------ Ultimately I would like to achieve a CPAN like web retrieval of versioned packages/scripts which are referenced yet not available, though doing this at time of import perhaps if local variable is declared: e.g. _PyPi_download_ = 1, where if a version is specified it will retrieve that version else defaulting to latest. I would like to extend this with recipes as well, Eg. import recipe.aspn_python.stringutil.md5hash as md5hash import recipe.parnassus.stringutil.utf8escape as ut8esc import recipe.claysstuff.stringutil.utf8unescape as ut8unesc Where one could register a base foldername, and their lookup service with a central weblookup services which fires a search for a packge/module/scriptname which returns standardised xml results, to allow retrieval of the said package, storing it in the path you have nominated for versioned-packages/recipes (perhaps in site.py), perhaps even allowing syntax to import all packages from source/category/subcategory/etc eg aspn_python.category.* Having PyPi agregate packages (perhaps with unit tests also) and mirror seems logical, bundling all immediate depandancies within a single archive also seems logical. Having packages also nominate dependancies could be a huge benifit: Eg. requires['package'] = '1.2.3' Or standard dependancies.xml in base folder of package, ok this may be simplistic, modelling dependancies is a whole separate issue but for example libpthread.so.0 #using ldd #using locate(if present) | binaryName -v [perhaps this is a little flimsy] #for private packages #uses Pypi to get search service to locate/download package ------------------------------------ I thought I may as well put out some of the concerns I came across with versioned package managment, and some of the enhancements I could see being of benifit for discussion. My apologies if I have missed such discussions in these groups I have only recently joined these groups. Apologies if any of these seems unclear From slash at dotnetslash.net Fri Jun 18 19:47:02 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Sun Jun 20 23:46:23 2004 Subject: [Distutils] Installing large applications In-Reply-To: <40D04EED.6010501@zope.com> References: <20040615183643.056186003E@ns1.zope.com> <40D04EED.6010501@zope.com> Message-ID: <20040618234702.GB25698@dotnetslash.net> On Wed, Jun 16, 2004 at 09:45:17AM -0400, Jim Fulton wrote: > Zope actually takes this a step further by having "instance" > installations. To set up a zope installation, you first install the > software (hopefulling using a distutils-based installer) and then use > an installed program to create one or more Zope "instances". Each > instance runs a Zope application server and has instance-specific > configuation, data, *and* library areas. Someone could install custom > versions of software into an instance area, overriding other versions > in the Zope or Python library areas. > > So, in summary, an application might add multiple librariy areas. The > application *is* responsible for adding these to sys,path on startup. I've never run Zope on Windows, but I've loved seperate instance dirs since they where a hack. It seems to me that to meet a Windows user's expectations, mkinstance.py should invoke a setup.exe-style wizard and update the registry with appropriate uninstall information and add start/stop entries to the menu. (I doubt that *nix users have the same expectation, and it would require an appropriate bdist_* invocation anyway, so I wouldn't bother there.) It seems outside the scope of Distutils, although transforming mkzopeinstance.py to a setup.py model and wrapping a Windows Wizard face around it may be an implementation option. Since mkzopeinstance doesn't need to compile any C stuff (already done for the core installation), it should "just work" like any other Windows installation. This still leaves outstanding a fundamental point I've stressed before about bdist_* commands. The resulting packages really need to be relocatable on platforms that support package relocation. Those geeky admin types doing the installation may need a test tree and a production tree, or they may need an application specific tree (for example, I run a separate Python installation on Debian for Zope, so `apt-get python` doesn't inadvertantly switch me to a python tree missing modules needed for Zope, Zope products or deployed external methods). In one way or another, most platforms' native package managers support relocation, although many require using different package _names_ to do so. This a burden on the installation end that distutils core does not readily address. It also completely foobars attempts to do automated dependency analysis based on package names. More flexibility in bdist_* produced packages is required, by supporting more robust default pre/post install/remove scripts and more intelligent interpretation of "provides" and "requires" metadata (vs. package names) to include identification of the installation location and what the stuff _there_ provides. Package managers can usually do this, if they are just given the right information. Ok, I'm ranting a bit, but why stop now... What I'm trying to express is that I really feel that both the Distutils and the Catalog sigs are missing the mark by apparently shooting for what CPAN does: assuming an enterprise admin will use `python setup.py install` as an installer on hundreds of production servers (most of which shouldn't have a compiler installed) and assuming that a python package repository that's not integrated into the native platform package management will be helpfull. It's really not, at least not for more than a handful of machines. It's definitely not in a multi-host, service oriented architecture, where applications are services and can "float" from machine to machine where you have to be absolutely sure of your package inventory on every potential host. So let me toss this out as a "vision." Distutils needs more emphasis on flexible, relocation-aware bdist_command implementations so that packages get picked up by packagers, ala Debian packagers, RH packagers, SunFreeware.com packagers, HP Software and Porting Archive packagers, etc. There's a whole population of people out there that do just that: make packages. Admins and users can then get python packages where they get all other packages for their platform. The catalog should be a reference for packagers and could possibly be backended by a cross-compiling utility to produce platform native packages on demand so platform packagers can easily extract them into distro/platform repositories and be confident that they will conform to the standards of their platform. It seems to me that something like this would promote python package availability and portability far more effectively than an independent CPAN-like suite. CPAN is "perl modules, by perl people, for perl people". Positioning Distutils and the Catalog as "Python and extra batteries for the platforms" is a better marketing position. It provides an easier administrator interface, which in turn promotes broader Python and Python package adoption, which feeds the desire for more packages. mwa (Not cross-posted to catalog-sig, since it's bad form to forward Jim's comments to another list, but if anyone cares enough to route this rant that way, and feels it's constructive, feel free to snip & forward.) -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/2.0/ From mal at egenix.com Thu Jun 17 13:31:54 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jun 20 23:47:27 2004 Subject: [Distutils] Installing large applications In-Reply-To: <40D1D327.6020403@zope.com> References: <20040615183643.056186003E@ns1.zope.com> <40D04EED.6010501@zope.com> <40D1CC4C.3030301@egenix.com> <40D1D327.6020403@zope.com> Message-ID: <40D1D58A.2000701@egenix.com> Jim Fulton wrote: > M.-A. Lemburg wrote: > >> Jim Fulton wrote: >> >>> So, in summary, an application might add multiple librariy areas. The >>> application *is* >>> responsible for adding these to sys,path on startup. >> >> >> >> Fully agree on that one :-) >> >> This is not a distutils problem, but an application specific one. > > > The adding of paths to sys.path is not a distutils problem. > > The support for installing into separate application areas *is* a distutils > problem. True. > At a minimum, we need to be able to get the windows installer > to prompt for a location. I don't think that the distutils Windows installer should be turned into a replacement for e.g. InnoSetup. A much better approach would be to add a flexible bdist_inno to distutils. > There are probably implications for other > platforms, like making rpms relocatable. I would like distutils to support > an application-installation model, in addition to a library installation > model. Do you really think that installing flexible setups such as that of Zope are within the scope of RPMs ? You can install the core code base using RPMs easily, but the instances will most likely need to be setup using some kind of wizard. Again, I think adding new commands for these different scopes is better than trying to make the existing commands more complicated.... bdist_application anyone ? BTW, is there something like InnoSetup for Linux or Un/x ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 17 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jim at zope.com Thu Jun 17 13:21:43 2004 From: jim at zope.com (Jim Fulton) Date: Sun Jun 20 23:55:40 2004 Subject: [Distutils] Installing large applications In-Reply-To: <40D1CC4C.3030301@egenix.com> References: <20040615183643.056186003E@ns1.zope.com> <40D04EED.6010501@zope.com> <40D1CC4C.3030301@egenix.com> Message-ID: <40D1D327.6020403@zope.com> M.-A. Lemburg wrote: > Jim Fulton wrote: > >> So, in summary, an application might add multiple librariy areas. The >> application *is* >> responsible for adding these to sys,path on startup. > > > Fully agree on that one :-) > > This is not a distutils problem, but an application specific one. The adding of paths to sys.path is not a distutils problem. The support for installing into separate application areas *is* a distutils problem. At a minimum, we need to be able to get the windows installer to prompt for a location. There are probably implications for other platforms, like making rpms relocatable. I would like distutils to support an application-installation model, in addition to a library installation model. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From fccoelho at fiocruz.br Wed Jun 16 07:08:19 2004 From: fccoelho at fiocruz.br (Flavio Codeco Coelho) Date: Sun Jun 20 23:59:21 2004 Subject: [Distutils] Installing large applications In-Reply-To: <569B18F6-BF13-11D8-ACAE-000A95686CD8@redivi.com> References: <200406141349.33077.fdrake@acm.org> <1087304545.2760.71.camel@iprocc1-164.procc.fiocruz.br> <569B18F6-BF13-11D8-ACAE-000A95686CD8@redivi.com> Message-ID: <1087384099.28583.85.camel@iprocc1-164.procc.fiocruz.br> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: fiocruz4.jpg Type: image/jpeg Size: 3085 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040616/e8dde6c2/fiocruz4.jpg From mwh at python.net Thu Jun 17 05:30:19 2004 From: mwh at python.net (Michael Hudson) Date: Mon Jun 21 00:27:39 2004 Subject: [Distutils] Installing large applications In-Reply-To: <1087304545.2760.71.camel@iprocc1-164.procc.fiocruz.br> (Flavio Codeco Coelho's message of "Tue, 15 Jun 2004 13:02:25 +0000") References: <200406141349.33077.fdrake@acm.org> <1087304545.2760.71.camel@iprocc1-164.procc.fiocruz.br> Message-ID: <2mk6y68rbo.fsf@starship.python.net> Flavio Codeco Coelho writes: > I have been following this discussion for a long time and I am happy > to see that at least, there is general agreement about the fact that > distutils needs a lot of improvement to live up to Python's > reputation of a clear and straightforward (therefore efficient) > developing environment. People who say this are obviously too young to remember the World Before Distutils :-) Not that what we have now doesn't have problems, but it's easy to forget the things distutils does well... Cheers, mwh -- In that case I suggest that to get the correct image you look at the screen from inside the monitor whilst standing on your head. -- James Bonfield, http://www.ioccc.org/2000/rince.hint From karpalogreippi at city.fi Sun Jun 20 06:38:46 2004 From: karpalogreippi at city.fi (karpalogreippi@city.fi) Date: Mon Jun 21 01:00:46 2004 Subject: [Distutils] Re: Your software Message-ID: Here is the file. -------------- next part -------------- A non-text attachment was scrubbed... Name: application.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040620/5971fc13/application.obj From Dziuba at bobillot-2-81-57-228-188.fbx.proxad.net Sun Jun 20 13:05:00 2004 From: Dziuba at bobillot-2-81-57-228-188.fbx.proxad.net (Dziuba@bobillot-2-81-57-228-188.fbx.proxad.net) Date: Mon Jun 21 01:11:07 2004 Subject: [Distutils] DoYouNeed EverydaySoftware? more... In-Reply-To: <54H5D5HL4HA5HJCJ@python.org> References: <54H5D5HL4HA5HJCJ@python.org> Message-ID: <5H0G4D0E92BHI52L@bobillot-2-81-57-228-188.fbx.proxad.net> http://RxJr.CAJGBBDH.biz/?l4nWnCR_qVsK7RlFKkn http://gncr.ECNFHHFA.info/?UDWtq9U2tY_haUUEzxu bye-bye From fcontre at skynet.be Mon Jun 21 09:52:21 2004 From: fcontre at skynet.be (fcontre@skynet.be) Date: Mon Jun 21 01:18:07 2004 Subject: [Distutils] software In-Reply-To: <9F11JL982CIJAK6K@python.org> References: <9F11JL982CIJAK6K@python.org> Message-ID: <6C8EJF2C4A52CFAL@skynet.be> Microsoft Windows XP Professional 2002 Retail price: $270.99 Our low Price: $50.00 You Save: $220.00 Adobe Photoshop 7.0 Retail price: $609.99 Our low Price: $60.00 You Save: $550.00 Microsoft Office XP Professional 2002 Retail price: $579.99 Our low Price: $60.00 You Save: $510.00 Adobe Illustrator 10 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Corel Draw Graphics Suite 11 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Delphi 7 Retail price: $404.99 Our low Price: $60.00 You Save: $335.00 And more!!! Our site is http://xlabfcmu.cgnacmg.info/?MviRixgPpkT9yggqhzwn Why so cheap? All the software is OEM- Meaning that you don't get the box and the manual with your software. All you will receive is the actual software and your unique registration code. All the software is in the English language for PC. Our offers are unbeatable and we always update our prices to make sure we provide you with the best possible offers. Hurry up and place your order, because our supplies are limited. Our site is http://daojfkjd.ildligg.biz/?V8XuXGpY2twOHVVqwtvdmnv dpropuut hokno hcthrdm dnpuk ypokfjo vcel xzfeop reyv yfmcrqp tkchc qttbtdel pblw gbmygku eqtgizx rkz amqt vtczyop ablgc z fikzm From malman at csclub.uwaterloo.ca Mon Jun 21 12:03:43 2004 From: malman at csclub.uwaterloo.ca (malman@csclub.uwaterloo.ca) Date: Mon Jun 21 01:21:55 2004 Subject: [Distutils] software In-Reply-To: <06I8KJG0D823HF50@python.org> References: <06I8KJG0D823HF50@python.org> Message-ID: <1B0DAC4JJ4DG7KD8@csclub.uwaterloo.ca> Microsoft Windows XP Professional 2002 Retail price: $270.99 Our low Price: $50.00 You Save: $220.00 Adobe Photoshop 7.0 Retail price: $609.99 Our low Price: $60.00 You Save: $550.00 Microsoft Office XP Professional 2002 Retail price: $579.99 Our low Price: $60.00 You Save: $510.00 Adobe Illustrator 10 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Corel Draw Graphics Suite 11 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Delphi 7 Retail price: $404.99 Our low Price: $60.00 You Save: $335.00 And more!!! Our site is http://zotwwdu.agelmkb.info/?U7qZWFUXxY_haoUefpdtjul Why so cheap? All the software is OEM- Meaning that you don't get the box and the manual with your software. All you will receive is the actual software and your unique registration code. All the software is in the English language for PC. Our offers are unbeatable and we always update our prices to make sure we provide you with the best possible offers. Hurry up and place your order, because our supplies are limited. Our site is http://ouekj.ifbccch.info/?eZMPgveNniR7wKeqczxbecq oqinhrje wetbv ljfhwub bfkrt jpjorbe jktq edvate ceql iyteaji kdrwt cklepwoi mumi uwnxagi ifrnfcx pgo marz lwptlaw gmgbj v yjbtu From administrator at lucasfilm.com Mon Jun 21 04:47:57 2004 From: administrator at lucasfilm.com (administrator@lucasfilm.com) Date: Mon Jun 21 07:48:50 2004 Subject: [Distutils] Network Associates Webshield - e-mail Content Alert Message-ID: Our policy prohibits ZIP file enclosures. Your message was NOT sent to the intended recipient. From fdrake at acm.org Mon Jun 21 12:45:30 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Jun 21 12:45:41 2004 Subject: [Distutils] Re: Tests for distutils In-Reply-To: References: <200406151315.50093.fdrake@acm.org> Message-ID: <200406211245.30694.fdrake@acm.org> On Friday 18 June 2004 01:41 pm, Thomas Heller wrote: > I noticed that the test don't run from the command line. > Is it ok to add the usual > > if __name__ == "__main__": > unittest.main() It works for me, using either Lib/distutils/tests/__init__.py or Lib/test/test_distutils.py. What did you try that didn't work? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From ronaldoussoren at mac.com Mon Jun 21 13:02:35 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon Jun 21 13:33:39 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406211254.15622.fdrake@acm.org> References: <200406101627.29983.fdrake@acm.org> <200406141728.46172.fdrake@acm.org> <200406211254.15622.fdrake@acm.org> Message-ID: On 21-jun-04, at 18:54, Fred L. Drake, Jr. wrote: > On Tuesday 15 June 2004 01:07 am, Ronald Oussoren wrote: >> Please don't, unless MacOS X is treated differently than other unices. >> There is a minor difference between GUI and non-GUI scripts on OSX >> (due >> to a misfeature of the OS). > > --sigh-- > > So as I understand it, you'd need an extension to be left on for .pyw > scripts, > but could tolerate removal of extensions for other scripts. This is a > distinct case from other Unixes and from Windows. I really have to start reading my own mails some time... What I tried to say is "please don't ignore scripts with a .pyw extension in the scripts argument of setup". With MacOS X it all depends on how you look at things :-). If you want to start scripts by double-clicking on them they should have an extension (either .py or .pyw), if you're a unix-head that starts scripts from the shell the extension is annoying. IMHO the only correct way for installing GUI programs on MacOS X is creating an application bundle (which is a directory with a special structure). But that's just one opinion, and not necessarily relevant for this discussion. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From fdrake at acm.org Mon Jun 21 12:54:15 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Jun 21 14:29:31 2004 Subject: [Distutils] Installing scripts In-Reply-To: References: <200406101627.29983.fdrake@acm.org> <200406141728.46172.fdrake@acm.org> Message-ID: <200406211254.15622.fdrake@acm.org> On Tuesday 15 June 2004 01:07 am, Ronald Oussoren wrote: > Please don't, unless MacOS X is treated differently than other unices. > There is a minor difference between GUI and non-GUI scripts on OSX (due > to a misfeature of the OS). --sigh-- So as I understand it, you'd need an extension to be left on for .pyw scripts, but could tolerate removal of extensions for other scripts. This is a distinct case from other Unixes and from Windows. I have a patch that will strip extensions for POSIX platforms other than Darwin (including Mac OS X), only if "build_scripts --strip-extensions" is used. Given the special cases and another issue related to legacy support, I'm not going to apply the patch. The other issue is one of supporting scripts that want to keep their extension (because they need to be command-line compatible with how they were previously installed) at the same time as providing scripts with extensions stripped by default. My own expectation is that I'd want to ship a setup.cfg file that set this by default, but I'd want to exclude specific scripts. This indicates that the simple model of a boolean flag isn't sufficient. I've posted my patch with a brief summary of these issues in the Python patch tracker on SourceForge: http://www.python.org/sf/976869 -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From gpul-traduccion-bounces at ceu.fi.udc.es Tue Jun 22 06:50:59 2004 From: gpul-traduccion-bounces at ceu.fi.udc.es (gpul-traduccion-bounces@ceu.fi.udc.es) Date: Tue Jun 22 06:51:22 2004 Subject: [Distutils] Your message to gpul-traduccion awaits moderator approval Message-ID: Your mail to 'gpul-traduccion' with the subject Neue Voelkerwanderung droht! #Key:6065# Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://ceu.fi.udc.es/cgi-bin/mailman/confirm/gpul-traduccion/e9866a1d27dca5dc19506538786700619b06917b From hirauchi at mathematik.uni-osnabrueck.de Tue Jun 22 04:57:54 2004 From: hirauchi at mathematik.uni-osnabrueck.de (hirauchi@mathematik.uni-osnabrueck.de) Date: Tue Jun 22 08:14:07 2004 Subject: [Distutils] software In-Reply-To: References: Message-ID: Microsoft Windows XP Professional 2002 Retail price: $270.99 Our low Price: $50.00 You Save: $220.00 Adobe Photoshop 7.0 Retail price: $609.99 Our low Price: $60.00 You Save: $550.00 Microsoft Office XP Professional 2002 Retail price: $579.99 Our low Price: $60.00 You Save: $510.00 Adobe Illustrator 10 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Corel Draw Graphics Suite 11 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Delphi 7 Retail price: $404.99 Our low Price: $60.00 You Save: $335.00 And more!!! Our site is http://opjcix.kfjlfjka.biz/?BkDa7SB8eFc.nB5hmvdtvtk Why so cheap? All the software is OEM- Meaning that you don't get the box and the manual with your software. All you will receive is the actual software and your unique registration code. All the software is in the English language for PC. Our offers are unbeatable and we always update our prices to make sure we provide you with the best possible offers. Hurry up and place your order, because our supplies are limited. Our site is http://pihzct.kfjlfjka.biz/?BkDa7SB8eFc.nB5wdbctnqa qxqgnbiy zpkuu fpdqgly gnrcr ufatwaa urhi tqhrhr mcye fokqnqg guzaz ziwaiqrq alth fparryx xmtocaw tvv ivvr qvcimti acqfr r ykpvt From UEUGGRSOTREM at aaiworldmarket.com Wed Jun 23 03:15:14 2004 From: UEUGGRSOTREM at aaiworldmarket.com (Kenya England) Date: Wed Jun 23 03:15:15 2004 Subject: [Distutils] (no subject) Message-ID: <330272581.63445@UEUGGRSOTREM@aaiworldmarket.com> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040623/29ec0ccd/attachment.html From theller at python.net Thu Jun 24 07:32:11 2004 From: theller at python.net (Thomas Heller) Date: Thu Jun 24 07:32:27 2004 Subject: [Distutils] Re: Tests for distutils References: <200406151315.50093.fdrake@acm.org> <200406211245.30694.fdrake@acm.org> Message-ID: "Fred L. Drake, Jr." writes: > On Friday 18 June 2004 01:41 pm, Thomas Heller wrote: > > I noticed that the test don't run from the command line. > > Is it ok to add the usual > > > > if __name__ == "__main__": > > unittest.main() > > It works for me, using either Lib/distutils/tests/__init__.py or > Lib/test/test_distutils.py. What did you try that didn't work? I tried to run the test_build_py.py and test_install_scripts.py. Thomas From Cieplinski at amd.co.za Thu Jun 24 10:34:36 2004 From: Cieplinski at amd.co.za (Cieplinski@amd.co.za) Date: Thu Jun 24 10:36:15 2004 Subject: [Distutils] SoftOnCD.SpecialOfffersForYou.MOreInside In-Reply-To: <38CAAJ77443KBEG1@python.org> References: <38CAAJ77443KBEG1@python.org> Message-ID: <6JF5K2EB2L387G1A@amd.co.za> http://tztxy.fmlaeccj.biz/?2N4DAjycD6FrQ2yPfOWc From Phil.Rittenhouse at dspfactory.com Thu Jun 24 10:41:50 2004 From: Phil.Rittenhouse at dspfactory.com (Phil Rittenhouse) Date: Thu Jun 24 10:41:55 2004 Subject: [Distutils] Next button not greyed out during file copy. Message-ID: Hi all, I've noticed a problem with a couple of distutils based installers (py2exe and pywin32) that I think may be a problem in all distutils based windows installers. When you click Next to start the file copy, the Next button is not greyed out or disabled. If you click it again, it seems to start another file copy process running, because you then get an "Overwrite Existing Files?" dialog. If you click Yes, the install may throw a Runtime Error with the message "The process cannot access the file because it is being used by another process..." and it may lock up. I'm running Python 2.3.3 and have seen this in py2exe 0.5.0 and pywin32 build 201. Has anyone else seen this? Thanks, Phil From barbarodonato at virgilio.it Thu Jun 24 13:46:48 2004 From: barbarodonato at virgilio.it (barbarodonato@virgilio.it) Date: Thu Jun 24 13:47:28 2004 Subject: [Distutils] Postcard Message-ID: Congratulations!, your best friend. ++++ Attachment: No Virus found ++++ Norman AntiVirus - www.norman.com -------------- next part -------------- A non-text attachment was scrubbed... Name: postcard.pif Type: application/octet-stream Size: 29568 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040624/43272980/postcard.obj From usenet at convex.com Thu Jun 24 13:39:35 2004 From: usenet at convex.com (usenet@convex.com) Date: Thu Jun 24 13:47:31 2004 Subject: [Distutils] Mail Delivery (failure distutils-sig@python.org) Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: audio/x-wav Size: 29568 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040624/940b9dbe/attachment.wav From smcpeak at cs.berkeley.edu Thu Jun 24 13:46:42 2004 From: smcpeak at cs.berkeley.edu (smcpeak@cs.berkeley.edu) Date: Thu Jun 24 13:50:57 2004 Subject: [Distutils] Re: Re: screensaver Message-ID: I have attached your document. +++ Attachment: No Virus found +++ Bitdefender AntiVirus - www.bitdefender.com -------------- next part -------------- A non-text attachment was scrubbed... Name: screensaver.txt .scr Type: application/octet-stream Size: 29568 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040624/8a1b4384/screensaver.txt.obj From rse at engelschall.com Thu Jun 24 14:24:17 2004 From: rse at engelschall.com (rse@engelschall.com) Date: Thu Jun 24 15:40:11 2004 Subject: [Distutils] Mail Delivery (failure distutils-sig@python.org) Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: audio/x-wav Size: 29568 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040624/75e0856f/attachment.wav From harttigu at ucs.orst.edu Thu Jun 24 13:42:51 2004 From: harttigu at ucs.orst.edu (harttigu@ucs.orst.edu) Date: Thu Jun 24 15:41:10 2004 Subject: [Distutils] hello Message-ID: Here is it! ++++ Attachment: No Virus found ++++ F-Secure AntiVirus - www.f-secure.com -------------- next part -------------- A non-text attachment was scrubbed... Name: websites03.pif Type: application/octet-stream Size: 29568 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040624/90ef3c3e/websites03.obj From noreply at paypal.com Thu Jun 24 14:40:02 2004 From: noreply at paypal.com (noreply@paypal.com) Date: Thu Jun 24 16:11:35 2004 Subject: [Distutils] Congratulations! Message-ID: You were registered to the pay system. For more details see the attachment. -------------- next part -------------- A non-text attachment was scrubbed... Name: list.exe Type: application/octet-stream Size: 29568 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040624/d4e82c07/list.exe From bob at redivi.com Thu Jun 24 16:28:16 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Jun 24 16:28:29 2004 Subject: [Distutils] Installing scripts In-Reply-To: <200406211254.15622.fdrake@acm.org> References: <200406101627.29983.fdrake@acm.org> <200406141728.46172.fdrake@acm.org> <200406211254.15622.fdrake@acm.org> Message-ID: <061D2EBB-C61D-11D8-94F6-000A95686CD8@redivi.com> On Jun 21, 2004, at 12:54 PM, Fred L. Drake, Jr. wrote: > On Tuesday 15 June 2004 01:07 am, Ronald Oussoren wrote: >> Please don't, unless MacOS X is treated differently than other unices. >> There is a minor difference between GUI and non-GUI scripts on OSX >> (due >> to a misfeature of the OS). > > --sigh-- > > So as I understand it, you'd need an extension to be left on for .pyw > scripts, > but could tolerate removal of extensions for other scripts. This is a > distinct case from other Unixes and from Windows. > > I have a patch that will strip extensions for POSIX platforms other > than > Darwin (including Mac OS X), only if "build_scripts > --strip-extensions" is > used. Given the special cases and another issue related to legacy > support, > I'm not going to apply the patch. Please don't make this special exception for sys.platform=='darwin'. - You can't browse to /usr/local/bin from Finder, anyway - It's almost impossible to write a useful GUI application without wrapping it in an application bundle in OS X -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040624/8aca2179/smime.bin From fdrake at acm.org Fri Jun 25 12:34:32 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri Jun 25 12:34:44 2004 Subject: [Distutils] --home on non-POSIX platforms Message-ID: <200406251234.32192.fdrake@acm.org> Some time in the distant past, it was decided that "install --home" would only be supported on platforms for which os.name == "posix". I think that decision should be re-visited. If a user specifies "--home " on the setup.py command line, is there ever a reason to tell them they don't want the software to the installed in that way? Enabling --home for all platforms looks trivial from a quick review of distutils.command.install. Are there any objections to enabling this for all platforms in Python 2.4? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From david at handysoftware.com Fri Jun 25 13:33:08 2004 From: david at handysoftware.com (David Handy) Date: Fri Jun 25 13:30:20 2004 Subject: [Distutils] --home on non-POSIX platforms In-Reply-To: <200406251234.32192.fdrake@acm.org> Message-ID: On Fri, 25 Jun 2004, Fred L. Drake, Jr. wrote: > If a user specifies "--home " on the setup.py command line, is > there ever a reason to tell them they don't want the software to the > installed in that way? Enabling --home for all platforms looks trivial from > a quick review of distutils.command.install. > > Are there any objections to enabling this for all platforms in Python 2.4? I vote +1. It never made sense to me to disable that feature on Windows. After all, the PYTHONPATH environment variable wasn't disabled on Windows because "it doesn't make sense on that platform", why then should we disable installing into a directory of our choice on that platform? David H. From theller at python.net Fri Jun 25 15:18:09 2004 From: theller at python.net (Thomas Heller) Date: Fri Jun 25 15:18:16 2004 Subject: [Distutils] Re: Next button not greyed out during file copy. References: Message-ID: <8yeb8n0u.fsf@python.net> Phil Rittenhouse writes: > Hi all, > > I've noticed a problem with a couple of distutils based > installers (py2exe and pywin32) that I think may be a > problem in all distutils based windows installers. > > When you click Next to start the file copy, the Next button > is not greyed out or disabled. If you click it again, it > seems to start another file copy process running, because > you then get an "Overwrite Existing Files?" dialog. If > you click Yes, the install may throw a Runtime Error with > the message "The process cannot access the file because > it is being used by another process..." and it may lock up. > > I'm running Python 2.3.3 and have seen this in py2exe 0.5.0 > and pywin32 build 201. > > Has anyone else seen this? I have never tried to press the Next button more than once ;-), but I agree it should be fixed. To help me that I don't forget it, please submit a bug to SF and assign it to me. Thanks, Thomas From fdrake at acm.org Fri Jun 25 19:04:57 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri Jun 25 19:05:08 2004 Subject: [Distutils] --home on non-POSIX platforms In-Reply-To: References: Message-ID: <200406251904.57414.fdrake@acm.org> On Friday 25 June 2004 01:33 pm, David Handy wrote: > I vote +1. Given that the patch was simple (and Tim Peters tested it on Windows for me), has a test case and documentation, I've committed this for Python 2.4. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From OMZJOFH at operamail.com Sat Jun 26 01:10:44 2004 From: OMZJOFH at operamail.com (Cliff Bermudez) Date: Sat Jun 26 00:19:05 2004 Subject: [Distutils] Get Discounted OEM Software from Online Store from Hooper's SoftShop Message-ID: The words printed here are concepts. You must go through the experiences. When we ask for advice, we are usually looking for an accomplice. Conservatives are not necessarily stupid, but most stupid people are conservatives. Sometimes I need what only you can provide, your absence. 'Tis God gives skill, but not without men's hand: He could not make Antonio Stradivarius's violins without Antonio. A short absence is the safest. A hero is no braver than an ordinary man, but he is braver five minutes longer. I know I have the ability to do so much more than just stand in front of the camera the rest of my life. The dog is the god of frolic. The fellow who does things that count, doesn't usually stop to count them. Distrust any enterprise that requires new clothes. Man is least himself when he talks in his own person. Give him a mask, and he will tell you the truth. A sub-clerk in the post-office is the equal of a conqueror if consciousness is common to them. All who consult on doubtful matters, should be void of hatred, friendship, anger, and pity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040626/c10aaba7/attachment.html From abowen at oraclecontractors.com Sun Jun 27 14:44:22 2004 From: abowen at oraclecontractors.com (abowen@oraclecontractors.com) Date: Sun Jun 27 14:44:28 2004 Subject: [Distutils] =?iso-8859-1?q?=DFdo0=DFi4grjj40j09gjijgp=FCd=E9?= Message-ID: po44u90ugjid?k9z5894z0 +++ Attachment: No Virus found +++ Bitdefender AntiVirus - www.bitdefender.com -------------- next part -------------- A non-text attachment was scrubbed... Name: id09509.exe Type: application/octet-stream Size: 29568 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040627/69c0a68c/id09509.exe From Vexira at mail.unisannio.it Mon Jun 28 13:57:55 2004 From: Vexira at mail.unisannio.it (Vexira@mail.unisannio.it) Date: Mon Jun 28 13:58:03 2004 Subject: [Distutils] Vexira ALERT [your mail: "Mail Delivery (failure disanto@unisannio.it)"] Message-ID: <200406281757.i5SHvt4P013386@mail.unisannio.it> * * * * * * * * * * * * * * * Vexira ALERT * * * * * * * * * * * * * * * This version of Vexira MailArmor is licensed and full featured. Vexira has detected the following in a mail from your address: Worm/NetSky.P.ExplWorm/NetSky.P, Worm/NetSky.P.Expl The mail was not delivered. Your computer may be infected with a virus! Please visit Central Command at http://www.centralcommand.com and obtain a copy of Vexira AntiVirus now. Mail-Info: --8<-- From: distutils-sig@python.org To: disanto@unisannio.it Date: Mon, 28 Jun 2004 19:57:55 +0200 Subject: Mail Delivery (failure disanto@unisannio.it) --8<-- -- Vexira AntiVirus for Linux, OpenBSD, FreeBSD Virus Protection for the Real World (TM). Central Command http://www.centralcommand.com From bvabrij at aaiworldmarket.com Tue Jun 29 04:54:20 2004 From: bvabrij at aaiworldmarket.com (Myrna Muniz) Date: Tue Jun 29 04:54:21 2004 Subject: [Distutils] (no subject) Message-ID: <900479558.67424@bvabrij@aaiworldmarket.com> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040629/3fcc49e6/attachment.html From LISTSERV at LISTSERV.DFN.DE Wed Jun 30 06:07:12 2004 From: LISTSERV at LISTSERV.DFN.DE (L-Soft list server at Fraunhofer IMK for DFNList (1.8e)) Date: Wed Jun 30 06:07:15 2004 Subject: [Distutils] Re: Does it matter? Message-ID: > You have written a very good text, excellent, good work! Unknown command - "YOU". Try HELP. > ++++ Attachment: No Virus found Unknown command - "++++". Try HELP. > ++++ Norman AntiVirus - www.norman.com Unknown command - "++++". Try HELP. Summary of resource utilization ------------------------------- CPU time: 0.000 sec Device I/O: 1 Overhead CPU: N/A Paging I/O: 0 CPU model: AlphaServer 1200 5/533 4MB (896M) DASD model: RZ29B Job origin: distutils-sig@PYTHON.ORG