From xml-admin at gnome.org Sun Feb 1 00:47:03 2004 From: xml-admin at gnome.org (xml-admin@gnome.org) Date: Sun Feb 1 00:47:11 2004 Subject: [Distutils] Your message to xml awaits moderator approval Message-ID: <20040201054703.19700.16379.Mailman@moniker.gnome.org> Your mail to 'xml' with the subject test Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin thinks there may be spam in this message. Either the message will get posted to the list, or you will receive notification of the moderator's decision. From krjackson at lbl.gov Sun Feb 1 20:46:04 2004 From: krjackson at lbl.gov (Keith Jackson) Date: Sun Feb 1 20:45:52 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) In-Reply-To: References: <20040129111536.30B4B25AE97@bonanza.off.ekorp.com> Message-ID: <8FF97E6D-5521-11D8-BEC1-000A9577489A@lbl.gov> On Jan 31, 2004, at 2:34 PM, Bob Ippolito wrote: > > On Jan 31, 2004, at 4:59 PM, Keith Jackson wrote: > >> On Jan 29, 2004, at 3:26 AM, Bob Ippolito wrote: >> >>> On Jan 29, 2004, at 6:15 AM, Anthony Baxter wrote: >> >> Yes, but I don't think that prevents distutils from running a shell >> command to invoke gpg. I'd really like to see this as an option. As >> soon as people start putting more things up in a repository, the more >> likely it will become that someone tries to trojan things. I'd also >> like to see M2Crypto or pyOpenSSL support for S/MIME sigs. > > Well, right now there is no repository, PyPI links to the author's > page. There are repositories for Mac ports, though, but we're not > terribly worried at the moment (I maintain one of them, python.org has > the other maintained by Jack). The package index has MD5 hashes and > URLs to tarballs (that can be anywhere). Obviously you have to trust > me or Jack, and the integrity of our servers, but I don't think that's > a huge problem right now. I do have a CA-signed SSL cert for > pythonmac.org and I could put a package index there.. so you could > verify that there wasn't some sort of spoof or man in the middle > attack, but it just hasn't been worth doing so far. > I'm not concerned about man in the middle attacks. As far as I know, there has never been one documented in the wild. Seems more like something security people like to sit around and worry about. :) Mostly what I worry about is someone hacking the repository and handing out trojan binaries. This has happened to a number of major sites already, and can cause real problems, e.g., if someone trojans openssl for example. For now, I'm fine with having the md5/sha1 hashes on a different machine then the code. Now a cracker has to get access to both machines. We could even out of band mirror the hashes on other web sites. If I got pgp or s/mime mail from you or Jack, I would put hashes up on a LBNL machine. >> Yes, but of course this begs the age old key distribution problem. > > So does anything else? > :), No it always comes back to bite you. I think we could come up with a scheme that doesn't involve key distribution for more then a few of us. If we want to mirror the hashes of the packages, I think signed mail amongst a small subset of us would work fine. >> I'm all in favor of some kind of optional support for PGP or S/MIME >> signatures, I exist in an X.509 world, so I could take advantage of >> it for my own work. That said, I think that code integrity in the >> repository is a much bigger issue that authenticating who put the >> code into the repository. (yes i do understand that the sig will also >> handle integrity, but it is probably overkill) >> >> All a sha1 hash would say is that: The distutils repository only >> contains the code that was legitimately submitted. That doesn't mean >> someone didn't submit a trojan, but it does mean that for major >> projects like wxPython that if the hash verifies then most likely >> things are ok. > > md5 and sha1 hashes are fine, Python comes with those.. but crypto > isn't really an option because there are people who are concerned > about the associated export/import laws that will not let it go into > mainline Python (I tried). I think the hashes are great. I would still like to see optional support for some kind of dig sig. This could be completely optional, and require the separate installation of M2Crypto or PyOpenSSL. Mostly, I'd just like to design something that doesn't rule out using digital signatures. > >> Sorry for the long post, but I think if we're going to do a python >> repository, we should be concerned about the integrity of the >> repository. >> --keith >> >> p.s. How does CPAN deal with these issues? > > They don't, and I haven't really heard of any problems. From what I > understand, the author uploads a package to PAUSE (w/ a > login/password, probably not even over SSL), and it gets replicated > throughout CPAN in a few hours. > It's a good thing I'm not a cracker. :) That is just frightening to me. I doubt I'll be getting anything from CPAN any longer. I've always thought CPAN was the best part of perl, and I'd sure like to see the python community do something even better. ;) --keith From bob at redivi.com Sun Feb 1 21:10:44 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 1 21:07:56 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) In-Reply-To: <8FF97E6D-5521-11D8-BEC1-000A9577489A@lbl.gov> References: <20040129111536.30B4B25AE97@bonanza.off.ekorp.com> <8FF97E6D-5521-11D8-BEC1-000A9577489A@lbl.gov> Message-ID: <0236C649-5525-11D8-B571-000A95686CD8@redivi.com> On Feb 1, 2004, at 8:46 PM, Keith Jackson wrote: > On Jan 31, 2004, at 2:34 PM, Bob Ippolito wrote: > >> On Jan 31, 2004, at 4:59 PM, Keith Jackson wrote: >> >>> On Jan 29, 2004, at 3:26 AM, Bob Ippolito wrote: >>> >>>> On Jan 29, 2004, at 6:15 AM, Anthony Baxter wrote: >>> >>> Yes, but I don't think that prevents distutils from running a shell >>> command to invoke gpg. I'd really like to see this as an option. As >>> soon as people start putting more things up in a repository, the >>> more likely it will become that someone tries to trojan things. I'd >>> also like to see M2Crypto or pyOpenSSL support for S/MIME sigs. >> >> Well, right now there is no repository, PyPI links to the author's >> page. There are repositories for Mac ports, though, but we're not >> terribly worried at the moment (I maintain one of them, python.org >> has the other maintained by Jack). The package index has MD5 hashes >> and URLs to tarballs (that can be anywhere). Obviously you have to >> trust me or Jack, and the integrity of our servers, but I don't think >> that's a huge problem right now. I do have a CA-signed SSL cert for >> pythonmac.org and I could put a package index there.. so you could >> verify that there wasn't some sort of spoof or man in the middle >> attack, but it just hasn't been worth doing so far. > > I'm not concerned about man in the middle attacks. As far as I know, > there has never been one documented in the wild. Seems more like > something security people like to sit around and worry about. :) > > Mostly what I worry about is someone hacking the repository and > handing out trojan binaries. This has happened to a number of major > sites already, and can cause real problems, e.g., if someone trojans > openssl for example. For now, I'm fine with having the md5/sha1 hashes > on a different machine then the code. Now a cracker has to get access > to both machines. We could even out of band mirror the hashes on other > web sites. If I got pgp or s/mime mail from you or Jack, I would put > hashes up on a LBNL machine. The pythonmac-sig proposed-but-nobody-is-working-on-it solution is for Jack and I to use some secure mechanism, let's say s/mime or pgp, to send the hash of our package *index* every time we make an update. That way, one hash is sent that confirms the integrity of every hash in the index. >>> Yes, but of course this begs the age old key distribution problem. >> >> So does anything else? >> > > :), No it always comes back to bite you. I think we could come up with > a scheme that doesn't involve key distribution for more then a few of > us. If we want to mirror the hashes of the packages, I think signed > mail amongst a small subset of us would work fine. I'm fine with that, I use a script to update my package index anyways (though I suspect Jack might do his by hand ;). It wouldn't be much trouble for me to add the code to send a s/mime email to someone, my Mail.app is already configured to use s/mime (though it's off most of the time, because of stupid mailing lists and email clients that don't like them). >>> I'm all in favor of some kind of optional support for PGP or S/MIME >>> signatures, I exist in an X.509 world, so I could take advantage of >>> it for my own work. That said, I think that code integrity in the >>> repository is a much bigger issue that authenticating who put the >>> code into the repository. (yes i do understand that the sig will >>> also handle integrity, but it is probably overkill) >>> >>> All a sha1 hash would say is that: The distutils repository only >>> contains the code that was legitimately submitted. That doesn't mean >>> someone didn't submit a trojan, but it does mean that for major >>> projects like wxPython that if the hash verifies then most likely >>> things are ok. >> >> md5 and sha1 hashes are fine, Python comes with those.. but crypto >> isn't really an option because there are people who are concerned >> about the associated export/import laws that will not let it go into >> mainline Python (I tried). > > I think the hashes are great. I would still like to see optional > support for some kind of dig sig. This could be completely optional, > and require the separate installation of M2Crypto or PyOpenSSL. > Mostly, I'd just like to design something that doesn't rule out using > digital signatures. I'd like to see it too, the problem is that nobody wants to write the code and convince people to put it in Python and use it ;) >>> Sorry for the long post, but I think if we're going to do a python >>> repository, we should be concerned about the integrity of the >>> repository. >>> --keith >>> >>> p.s. How does CPAN deal with these issues? >> >> They don't, and I haven't really heard of any problems. From what I >> understand, the author uploads a package to PAUSE (w/ a >> login/password, probably not even over SSL), and it gets replicated >> throughout CPAN in a few hours. >> > > It's a good thing I'm not a cracker. :) That is just frightening to > me. I doubt I'll be getting anything from CPAN any longer. I've always > thought CPAN was the best part of perl, and I'd sure like to see the > python community do something even better. ;) Yeah, well, most of the software in CPAN is pretty poorly designed anyways ;) -bob From krjackson at lbl.gov Sun Feb 1 21:37:22 2004 From: krjackson at lbl.gov (Keith Jackson) Date: Sun Feb 1 21:37:11 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) In-Reply-To: <0236C649-5525-11D8-B571-000A95686CD8@redivi.com> References: <20040129111536.30B4B25AE97@bonanza.off.ekorp.com> <8FF97E6D-5521-11D8-BEC1-000A9577489A@lbl.gov> <0236C649-5525-11D8-B571-000A95686CD8@redivi.com> Message-ID: On Feb 1, 2004, at 6:10 PM, Bob Ippolito wrote: > The pythonmac-sig proposed-but-nobody-is-working-on-it solution is for > Jack and I to use some secure mechanism, let's say s/mime or pgp, to > send the hash of our package *index* every time we make an update. > > That way, one hash is sent that confirms the integrity of every hash > in the index. A single S/MIME email from you or Jack would totally suffice for me for the short term. That way I could look in the archive, verify the sig, and know that the hashes are valid. (Assuming you and Jack aren't really black hats. :) --keith -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2787 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040201/7681aeed/smime.bin From phil.hornby at accutest.co.uk Mon Feb 2 04:00:46 2004 From: phil.hornby at accutest.co.uk (Phil Hornby) Date: Mon Feb 2 04:05:05 2004 Subject: [Distutils] Distutils windows binaries... Message-ID: Okay, I love what I can do with distutils in windows - i.e. create a binary distribution of a module/package/etc But I have a few questions: If I write a script to generate all the details of the distribution - files list, etc - how do I force the script to make it into a binary distro? Do I modify the arguement list passed to the script to 'fake' that it was called with this? Cos I may well just want to run a script and have that as default behaviour. I have seen that there is the facility to build extension modules into the distro by actually building them from source - is it recommended to do it this way - what about including pre-built extensions? I have tried adding them to the 'data_files' option and it seems to work - although by default they don't end up where I would expect. Has anyone else played with that? I know you can change the bitmap displayed during the install but can you change the icon that is displayed for the *.exe that is generated? Well I think that is enough questions for now... -- Phil "Requirements - what are they I just hack something together that does what I think they want" ;) From virus.manager at st.com Mon Feb 2 05:21:17 2004 From: virus.manager at st.com (virus.manager@st.com) Date: Mon Feb 2 05:21:21 2004 Subject: [Distutils] Virus Alert Message-ID: <20040202102117.A9300F319@zeta.dmz-eu.st.com> The mail message (file: document.zip) you sent to contains a virus. (on zeta) From mhammond at skippinet.com.au Mon Feb 2 16:55:35 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon Feb 2 17:13:54 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: Message-ID: <9bdd01c3e9d7$49dce680$0200a8c0@eden> > >Just incase it slips under the radar, I have opened a bug > regarding MSVC7 > >directories. Specifically, changes I make to the > directories in the MSVC7 > >GUI are not seen by distutils. All the details, and a > patch, is in the bug: > > > >http://www.python.org/sf/883969 > >[ 883969 ] distutils doesn't see user-directories set via > VisStudio 7.1 > Always seemed a bit daft to do this implicitly from the IDE (eg when I > set things up for stackless my ordinary stuff seems to see the wrong > paths). Not sure what you mean here? I did find it strange that I could not setup the compiler as I would for any other project on the planet (ie, vie the env vars that the compiler itself supports), but that was pronounced to be a feature of distutils, so I dropped it. > There is special code in there about version >=7 though. > > if self.__version >= 7: > key = > (r"%s\%0.1f\VC\VC_OBJECTS_PLATFORM_INFO\Win32\Director > ies" > % (self.__root, self.__version)) > else: > key = (r"%s\6.0\Build System\Components\Platforms" > r"\Win32 (%s)\Directories" % (self.__root, > platform)) Yes, I did see that special code. My issue is that MSVC7.1 is not storing these paths in the registry at all. If you combine these 2 facts together (can't use env vars, MSVC doesn't store in the registry), it currently seems *impossible* to get MSVC7 to use an alternative path under distutils. My patch tries to address this (even if it seems the wrong one to support to me ) Can anyone else at least confirm that changing the directories in MSVC7 does not write the new paths to the registry? The standard paths seem to be written there at installation time, but changing paths in DevStudio does not change these registry values. Mark. From jeremy at alum.mit.edu Mon Feb 2 17:22:29 2004 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Mon Feb 2 17:25:19 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: <9bdd01c3e9d7$49dce680$0200a8c0@eden> Message-ID: Mark Hammond wrote: > Not sure what you mean here? I did find it strange that I could not setup > the compiler as I would for any other project on the planet (ie, vie the env > vars that the compiler itself supports), but that was pronounced to be a > feature of distutils, so I dropped it. Let's not drop it. When I asked about this feature years ago, I dropped it because people told me that real Windows users would never want this feature. Presumably that only reason I was asking was that I was a wayward Unix developer in Windows land. You, on the other hand, can make some claim to being a real Windows user. A patch to honor environment variables when they are set would help developers and, presumably, hurt no one. (No real Windows user would set an environment variable anyway.) Jeremy From robin at jessikat.fsnet.co.uk Mon Feb 2 18:01:44 2004 From: robin at jessikat.fsnet.co.uk (Robin Becker) Date: Mon Feb 2 18:02:09 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: <9bdd01c3e9d7$49dce680$0200a8c0@eden> References: <9bdd01c3e9d7$49dce680$0200a8c0@eden> Message-ID: In article <9bdd01c3e9d7$49dce680$0200a8c0@eden>, Mark Hammond writes ...... >> Always seemed a bit daft to do this implicitly from the IDE (eg when I >> set things up for stackless my ordinary stuff seems to see the wrong >> paths). > >Not sure what you mean here? I did find it strange that I could not setup >the compiler as I would for any other project on the planet (ie, vie the env >vars that the compiler itself supports), but that was pronounced to be a >feature of distutils, so I dropped it. > I just feel it strange as you do that the tool should rely on another tool to do setup. I regularly use distutils with several different python versions. I would be lucky to be able to set up a single set of include/lib dirs that would work for all. That's not to say that some base set might be useful, but that's what I thought the base environment vars were for. >> There is special code in there about version >=7 though. >> >> if self.__version >= 7: >> key = >> (r"%s\%0.1f\VC\VC_OBJECTS_PLATFORM_INFO\Win32\Director >> ies" >> % (self.__root, self.__version)) >> else: >> key = (r"%s\6.0\Build System\Components\Platforms" >> r"\Win32 (%s)\Directories" % (self.__root, >> platform)) > >Yes, I did see that special code. My issue is that MSVC7.1 is not storing >these paths in the registry at all. > Again I see nothing unusual in VCxxx storing most of a project setup in a more and more opaque form. I would be a bit surprised if it stores nothing globally though. I am speaking blindly as I don't have access to 7 yet. I would prefer the priorities to be 1) environment, 2) python version, 3) compiler/tool global. >If you combine these 2 facts together (can't use env vars, MSVC doesn't >store in the registry), it currently seems *impossible* to get MSVC7 to use >an alternative path under distutils. My patch tries to address this (even >if it seems the wrong one to support to me ) > >Can anyone else at least confirm that changing the directories in MSVC7 does >not write the new paths to the registry? The standard paths seem to be >written there at installation time, but changing paths in DevStudio does not >change these registry values. > >Mark. ... -- Robin Becker From mhammond at skippinet.com.au Mon Feb 2 18:05:40 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon Feb 2 18:06:01 2004 Subject: [Distutils] Distutils windows binaries... In-Reply-To: Message-ID: > If I write a script to generate all the details of the > distribution - files > list, etc - how do I force the script to make it into a > binary distro? Do I > modify the arguement list passed to the script to 'fake' that > it was called > with this? Cos I may well just want to run a script and have > that as default > behaviour. One of my scripts does: """ # Default and only distutils command is "py2exe" - save adding it to the # command line every single time. if len(sys.argv)==1 or \ (len(sys.argv)==2 and sys.argv[1] in ['-q', '-n']): sys.argv.append("py2exe") """ Hacky, but it works :) (and presumably you want 'bdist_wininst') > I have seen that there is the facility to build extension > modules into the > distro by actually building them from source - is it > recommended to do it > this way - what about including pre-built extensions? I have > tried adding > them to the 'data_files' option and it seems to work - > although by default > they don't end up where I would expect. Has anyone else > played with that? I think that by default, the "binary" distributions all ship binaries of your extension modules too. Thus, if your binary distribution has an extension module, the distribution is specific to a particular version of Python. > I know you can change the bitmap displayed during the install > but can you > change the icon that is displayed for the *.exe that is generated? I dont think bdist_wininst does, but py2exe does. Mark From mhammond at skippinet.com.au Mon Feb 2 18:14:47 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon Feb 2 18:15:00 2004 Subject: [Distutils] Distutils windows binaries... In-Reply-To: Message-ID: > > I know you can change the bitmap displayed during the install > > but can you > > change the icon that is displayed for the *.exe that is generated? > > I dont think bdist_wininst does, but py2exe does. Doh! But py2exe is different than distutils, so that doesn't really help you :) Mark. From phil.hornby at accutest.co.uk Mon Feb 2 18:39:41 2004 From: phil.hornby at accutest.co.uk (Phil Hornby) Date: Mon Feb 2 18:43:56 2004 Subject: [Distutils] Distutils windows binaries... In-Reply-To: Message-ID: Mark, Thanks for the code snippet I knew how to do it but wasn't sure if that was the only way to give the 'bdist_wininst' behaviour? Is there not a function interface that allows me to do it explicity within my code say by calling a different function than the basic setup() function?? The documentation on any of the other function seems to be all but non-existent. >> If I write a script to generate all the details of the >> distribution - files >> list, etc - how do I force the script to make it into a >> binary distro? Do I >> modify the arguement list passed to the script to 'fake' that >> it was called >> with this? Cos I may well just want to run a script and have >> that as default >> behaviour. > > One of my scripts does: > > """ > # Default and only distutils command is "py2exe" - save adding it to the > # command line every single time. > if len(sys.argv)==1 or \ > (len(sys.argv)==2 and sys.argv[1] in ['-q', '-n']): > sys.argv.append("py2exe") > """ > Hacky, but it works :) (and presumably you want 'bdist_wininst') The documentation seems to imply that you can specify *.c file for extension modules with some compiler details but that indicates a need to compile the module to me...there don't seem to be any options that allow you to indicate *.dll(or *.pyd) files. For example I am not sure if distutils supports Borland C++ Builder and I have several extensions written and compiled with it that I would like to package up. I am now looking at moving them across to MSVC which will mean a MAJOR code revamp but at present I don't want to re-compile the extension everytime I make a distro. >> I have seen that there is the facility to build extension >> modules into the >> distro by actually building them from source - is it >> recommended to do it >> this way - what about including pre-built extensions? I have >> tried adding >> them to the 'data_files' option and it seems to work - >> although by default >> they don't end up where I would expect. Has anyone else >> played with that? > > I think that by default, the "binary" distributions all ship binaries of > your extension modules too. Thus, if your binary distribution has an > extension module, the distribution is specific to a particular version of > Python. I was just about to look at py2exe until I saw your other e-mail...doh nevermind...it would just be nice as when distributing a module putting an approriate icon on it would be useful...from a commercial point of view >> I know you can change the bitmap displayed during the install >> but can you >> change the icon that is displayed for the *.exe that is generated? > > I dont think bdist_wininst does, but py2exe does. -- Phil "Requirements - what are they I just hack something together that does what I think they want" ;) From tommie at iae.nl Mon Feb 2 19:10:55 2004 From: tommie at iae.nl (tommie@iae.nl) Date: Mon Feb 2 19:11:02 2004 Subject: [Distutils] Re: ***SPAM?*** hello In-Reply-To: <20040203001036.F0F8F2A9FC@mailhub4.vianetworks.nl> References: <20040203001036.F0F8F2A9FC@mailhub4.vianetworks.nl> Message-ID: <20040203001055.F08742AAFB@mailhub4.vianetworks.nl> This account will cease to exist on: Dit account wordt opgeheven op: 1 sep 2003 Thomas. From Rollei_SAVGW at fvc.com Mon Feb 2 22:25:57 2004 From: Rollei_SAVGW at fvc.com (Rollei_SAVGW@fvc.com) Date: Mon Feb 2 22:25:59 2004 Subject: [Distutils] Virus found in a message you sent Message-ID: A virus was found in a message sent by this account. --- Scan information follows --- Result: Virus Detected Virus Name: W32.Novarg.A@mm File Attachment: test.zip Attachment Status: deleted --- Original message information follows --- From: distutils-sig@python.org To: cduke@fvc.com Date: Tue, 3 Feb 2004 04:25:54 +0100 Subject: test Received: from python.org ([81.53.39.146]) by rollei.fvc.com (SAVSMTP 3.1.0.29) with SMTP id M2004020219292614959 for ; Mon, 02 Feb 2004 19:29:26 -0800 From mhammond at skippinet.com.au Mon Feb 2 22:39:10 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon Feb 2 22:39:31 2004 Subject: [Distutils] Distutils windows binaries... In-Reply-To: Message-ID: > Thanks for the code snippet I knew how to do it but wasn't > sure if that was > the only way to give the 'bdist_wininst' behaviour? Is there > not a function > interface that allows me to do it explicity within my code > say by calling a > different function than the basic setup() function?? The > documentation on > any of the other function seems to be all but non-existent. Last time I looked at the code, no. Use the source, luke ;) I agree this would be nice, and would not require much refactoring of distutils mainline code. > The documentation seems to imply that you can specify *.c > file for extension > modules with some compiler details but that indicates a need > to compile the > module to me...there don't seem to be any options that allow > you to indicate > *.dll(or *.pyd) files. Right, I see what you mean. distutils generally wants you to specify the .c file, and does expect to be able to build the .c file. However, the binary packages include only the compiled module. > For example I am not sure if distutils supports > Borland C++ Builder and I have several extensions written and > compiled with > it that I would like to package up. I am now looking at > moving them across > to MSVC which will mean a MAJOR code revamp but at present I > don't want to > re-compile the extension everytime I make a distro. There are a number of potential problems you can face distributing modules built with a different compiler; specifically, Python makes a number of assumptions that the C runtime lib used by Python itself is the same as the extension. But assuming you know all that and understand the implications, the best approach is to probably create your own subclass of install_data. Your finalize_options method can call the base class, then just copy your .pyd in. The win32all distutils script does: class my_install_data(install_data): def finalize_options(self): install_data.finalize_options(self) ... # my custom stuff, referencing self.install_dir ... dist = setup(name="pywin32", ... cmdclass = { 'install_data': my_install_data, }, ... > I was just about to look at py2exe until I saw your other e-mail...doh > nevermind...it would just be nice as when distributing a > module putting an > approriate icon on it would be useful...from a commercial > point of view For commercial apps, I believe that using py2exe + inno is a good way to go. Via the py2exe project, we have the know-how to update the icon in the executable, but noone has done it for distutils yet. Mark From Paul.Moore at atosorigin.com Tue Feb 3 04:45:07 2004 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Tue Feb 3 04:45:14 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) Message-ID: <16E1010E4581B049ABC51D4975CEDB8803060DDB@UKDCX001.uk.int.atosorigin.com> From: Keith Jackson [mailto:krjackson@lbl.gov] > A single S/MIME email from you or Jack would totally suffice for me for > the short term. That way I could look in the archive, verify the sig, > and know that the hashes are valid. (Assuming you and Jack aren't > really black hats. :) Ironically, that message just came through with an "invalid digital signature" warning. I've no idea what Outlook (yes, I know, so sue me) considers in making this judgement, but I no longer trust anything you say, in case you are not who you say you are :-) On a more serious note, this demonstrates why I don't trust digital signatures much. Unless this really *was* someone else masquerading as Keith, what do I do? I've never seen a genuinely hacked download, to my knowledge, but I *have* seen warnings and errors from invalid signatures. So ignoring signature errors is the correct approach, based on the evidence I have encountered! I'm not trying to argue the case, just to demonstrate how the world looks from the POV of security-naive people like me... Paul. From mal at egenix.com Tue Feb 3 05:01:01 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 3 05:00:32 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8803060DDB@UKDCX001.uk.int.atosorigin.com> References: <16E1010E4581B049ABC51D4975CEDB8803060DDB@UKDCX001.uk.int.atosorigin.com> Message-ID: <401F715D.6060402@egenix.com> Moore, Paul wrote: > From: Keith Jackson [mailto:krjackson@lbl.gov] > >>A single S/MIME email from you or Jack would totally suffice for me > > for > >>the short term. That way I could look in the archive, verify the sig, >>and know that the hashes are valid. (Assuming you and Jack aren't >>really black hats. :) > > > Ironically, that message just came through with an "invalid digital > signature" warning. I've no idea what Outlook (yes, I know, so sue me) > considers in making this judgement, but I no longer trust anything you > say, in case you are not who you say you are :-) FWIW, the PSF will start creating a web of trust which should allow you to trust signatures if you see them on the web without actually knowing the person owning the signature. > On a more serious note, this demonstrates why I don't trust digital > signatures much. Unless this really *was* someone else masquerading as > Keith, what do I do? I've never seen a genuinely hacked download, to my > knowledge, but I *have* seen warnings and errors from invalid > signatures. > So ignoring signature errors is the correct approach, based on the > evidence I have encountered! > > I'm not trying to argue the case, just to demonstrate how the world > looks > from the POV of security-naive people like me... Perhaps distutils should simply start to add MD5 or SHA hash sums of the created archives to the meta-data which gets uploaded to e.g. PyPI. That way, the user can easily see whether a mirror has the correct packages or not. Better than nothing, I'd say, and easy to implement even without having to go through all the PKI stuff :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 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/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Paul.Moore at atosorigin.com Tue Feb 3 05:08:38 2004 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Tue Feb 3 05:08:44 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) Message-ID: <16E1010E4581B049ABC51D4975CEDB8802C09C3C@UKDCX001.uk.int.atosorigin.com> From: M.-A. Lemburg [mailto:mal@egenix.com] >> I'm not trying to argue the case, just to demonstrate how the >> world looks from the POV of security-naive people like me... > Perhaps distutils should simply start to add MD5 or SHA hash > sums of the created archives to the meta-data which gets uploaded > to e.g. PyPI. That way, the user can easily see whether a mirror > has the correct packages or not. Better than nothing, I'd say, > and easy to implement even without having to go through all the > PKI stuff :-) That sounds sensible. Everything needed is part of Python, no requirements on the user, some level of check for those that care. I can't see a downside... Paul. From kde-transl-request at chemia.polsl.gliwice.pl Tue Feb 3 12:51:32 2004 From: kde-transl-request at chemia.polsl.gliwice.pl (kde-transl-request@chemia.polsl.gliwice.pl) Date: Tue Feb 3 12:58:42 2004 Subject: [Distutils] (no subject) Message-ID: <200402031751.i13HpWE30186@mer.chemia.polsl.gliwice.pl> Subject: Your mail to kde-transl-request@chemia.polsl.gliwice.pl In-Reply-To: <200402031751.i13HpTr30181@mer.chemia.polsl.gliwice.pl>, from distutils-sig@python.org Reply-To: kde-transl-approval@chemia.polsl.gliwice.pl This pre-recorded message is being sent in response to your recent email to kde-transl-request@chemia.polsl.gliwice.pl . All routine administrative requests (including subscriptions and unsubscriptions) concerning this mailing list are handled by an automated server. Please read this message carefully to find the information relevant to you. SUBSCRIBING =========== To subscribe to kde-transl, send the following in the body (not the subject line) of an email message to "Majordomo@chemia.polsl.gliwice.pl ": subscribe kde-transl This will subscribe the account from which you send the message to the kde-transl list. If you wish to subscribe another address instead (such as a local redistribution list), you can use a command of the form: subscribe kde-transl other-address@your_site.your_net UNSUBSCRIBING ============= To unsubscribe from kde-transl, send the following in the body (not the subject line) of an email message to "Majordomo@chemia.polsl.gliwice.pl ": unsubscribe kde-transl This will unsubscribe the account from which you send the message. If you are subscribed with some other address, you'll have to send a command of the following form instead: unsubscribe kde-transl other-address@your_site.your_net If you don't know what address you are subscribed with, you can send the following command to see who else is on the list (assuming that information isn't designated "private" by the owner of the list): who kde-transl If you want to search non-private lists at this server, you can do that by sending a command like: which string This will return a list of all entries on all lists that contain "string". HELP ==== To find out more about the automated server and the commands it understands, send the following command to "Majordomo@chemia.polsl.gliwice.pl ": help If you feel you need to reach a human, send email to: kde-transl-approval@chemia.polsl.gliwice.pl From theller at python.net Tue Feb 3 14:27:21 2004 From: theller at python.net (Thomas Heller) Date: Tue Feb 3 14:27:41 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: (Jeremy Hylton's message of "Mon, 2 Feb 2004 17:22:29 -0500") References: Message-ID: "Jeremy Hylton" writes: > Mark Hammond wrote: >> Not sure what you mean here? I did find it strange that I could not >> setup the compiler as I would for any other project on the planet >> (ie, vie the env vars that the compiler itself supports), but that >> was pronounced to be a feature of distutils, so I dropped it. > Let's not drop it. When I asked about this feature years ago, I dropped it > because people told me that real Windows users would never want this > feature. IIRC, you asked for this feature because you had a misconfigured VC 6 installation - probably because you never ran the gui after installing the compiler. > Presumably that only reason I was asking was that I was a wayward > Unix developer in Windows land. You, on the other hand, can make some claim > to being a real Windows user. > > A patch to honor environment variables when they are set would help > developers and, presumably, hurt no one. (No real Windows user would set an > environment variable anyway.) I'm not sure I'm in the position to pronounce on this, but: If someone comes up with a patch that does this, I have nothing against it. But I'm not prepared to support and/or debug configurations the users may have which are very different from my own. If I understand Mark correctly, the MSVC 7 GUI doesn't pick up the enviroment vars itself - this is (one of?) the difficultiy I see. Thomas From theller at python.net Tue Feb 3 14:35:39 2004 From: theller at python.net (Thomas Heller) Date: Tue Feb 3 14:36:00 2004 Subject: [Distutils] Distutils windows binaries... In-Reply-To: (Phil Hornby's message of "Mon, 2 Feb 2004 09:00:46 -0000") References: Message-ID: "Phil Hornby" writes: > Okay, I love what I can do with distutils in windows - i.e. create a binary > distribution of a module/package/etc > > But I have a few questions: > > If I write a script to generate all the details of the distribution - files > list, etc - how do I force the script to make it into a binary distro? Do I > modify the arguement list passed to the script to 'fake' that it was called > with this? Cos I may well just want to run a script and have that as default > behaviour. > > I have seen that there is the facility to build extension modules into the > distro by actually building them from source - is it recommended to do it > this way - what about including pre-built extensions? I have tried adding > them to the 'data_files' option and it seems to work - although by default > they don't end up where I would expect. Has anyone else played with that? You can customize distutils to do *anything* you want by subclassing. The basic functionality, however, assumes you are distributing python modules, scripts, and extensions. And distutils actually is the easiest way imo to also *build* the extensions. IIRC, you can also use the borland compiler to build the extensions - see the output of 'python setup.py build_ext --help-compiler'. > > I know you can change the bitmap displayed during the install but can you > change the icon that is displayed for the *.exe that is generated? You can change the icon of the Lib/site-packages/distutils/command/wininst.exe with any tool of your choice, *before* building the installer. Thomas From krjackson at lbl.gov Tue Feb 3 14:39:40 2004 From: krjackson at lbl.gov (Keith Jackson) Date: Tue Feb 3 14:39:52 2004 Subject: [Distutils] PGP keys required? (Re: PEP 243) In-Reply-To: <401F715D.6060402@egenix.com> References: <16E1010E4581B049ABC51D4975CEDB8803060DDB@UKDCX001.uk.int.atosorigin.com> <401F715D.6060402@egenix.com> Message-ID: On Feb 3, 2004, at 2:01 AM, M.-A. Lemburg wrote: > Perhaps distutils should simply start to add MD5 or SHA hash > sums of the created archives to the meta-data which gets uploaded > to e.g. PyPI. That way, the user can easily see whether a mirror > has the correct packages or not. Better than nothing, I'd say, > and easy to implement even without having to go through all the > PKI stuff :-) I'm all in favor of associating hashes with all packages that get uploaded. My real question is how do we prevent a black hat from uploading a new version of M2Crypto, or PyOpenSSL that has been trojaned. As long as they changed the hash values, and I haven't cached them locally, I'd have no way of knowing. I can point to real examples of this happening in the open-source world. It would be fine with me if we could come up with a scheme where only package authors and the PyPI people need to deal with PKI. As part of the upload I could sign a copy of the SHA1 hash value for the package. This could be a detached PGP sig, an S/MIME sig, I don't care, although I think PGP would probably be best for our community. The PyPI could have a key, and then do signing BoF's at OSCON and PyCon, etc. I don't think this should be mandatory today, but I would hate to see us design a system that wouldn't support rudimentary security. I think we do it so only the hashes are used for now by actual users. That way we avoid any export laws and other such nonsense. All the PGP stuff could be done at the cli, or as part of the auto submission process. --keith From postmaster at mail.unina.it Tue Feb 3 17:06:00 2004 From: postmaster at mail.unina.it (postmaster@mail.unina.it) Date: Tue Feb 3 17:03:21 2004 Subject: [Distutils] Inflex scan report [0203230623666] Message-ID: <200402032206.i13M62ne023706@mail.unina.it> This email has been sent to you from an email content scanning filter located on the server [python.org]. If you have any queries relating to this email, please direct them to postmaster. Report Details ----------------------------------------------- Administrator Email Reply Address: postmaster Email sent to: messano@unina.it Inflex ID: 0203230623666 Report Details ----------------------------------------------- AntiVirus Results... SWEEP virus detection utility Version 3.78, February 2004 [Linux/Intel] Includes detection for 87441 viruses, trojans and worms Copyright (c) 1989,2004 Sophos Plc, www.sophos.com System time 23:06:01, System date 03 February 2004 Command line qualifiers are: -archive -all -rec -sc IDE directory is: /usr/local/sav Using IDE file rirc-a.ide Using IDE file randex-y.ide Using IDE file dumaru-k.ide Using IDE file dumaru-y.ide Using IDE file dloaderl.ide Using IDE file inorb.ide Using IDE file mmdloada.ide Using IDE file eyeveg-b.ide Using IDE file sdbot-dc.ide Using IDE file bagle-a.ide Using IDE file stawin-a.ide Using IDE file agobot-p.ide Using IDE file mimail-q.ide Using IDE file mimail-s.ide Using IDE file divix-a.ide Using IDE file mydoom-a.ide Using IDE file mydoom-b.ide Using IDE file gaggle-b.ide Using IDE file inor-c.ide Using IDE file proxin-a.ide Using IDE file sdbot-w.ide Using IDE file flopcopy.ide Quick Sweeping 00:02 ergymth.pif >>> Virus 'W32/MyDoom-A' found in file /usr/local/inflex/tmp/inf_0203230623666/unpacked/ergymth.pif 00:02 _headers_ 00:02 textfile0 00:02 textfile1 00:02 textfile2 5 files swept in 2 seconds. 1 virus was discovered. 1 file out of 5 was infected. Please send infected samples to Sophos for analysis. For advice consult www.sophos.com, email support@sophos.com or telephone +44 1235 559933 End of Sweep. File NAME/TYPE Scan Results 0203230623666 from:distutils-sig@python.org to: messano@unina.itType scanning off. Name scanning off. Text scanning off. END OF MESSAGE. End. . From robin at jessikat.fsnet.co.uk Wed Feb 4 03:53:31 2004 From: robin at jessikat.fsnet.co.uk (Robin Becker) Date: Wed Feb 4 03:54:07 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: References: Message-ID: In article , Thomas Heller writes ..... >> >> A patch to honor environment variables when they are set would help >> developers and, presumably, hurt no one. (No real Windows user would set an >> environment variable anyway.) > >I'm not sure I'm in the position to pronounce on this, but: If someone >comes up with a patch that does this, I have nothing against it. But >I'm not prepared to support and/or debug configurations the users may >have which are very different from my own. > this seems a bit harsh to me; I understand the part about being unable to debug, but surely this software is supposed to be a bit more robust. It is after all the product of more than one person and is now in the standard distro. Even M$ gives us VCVARS32.BAT so they presumably believe in that. I don't buy the argument about having to use the gui to set stuff up as distutils is a script/command line tool. I suppose we now face more difficult times with both MSC7/6 as the 'standard', but isn't that why distutils should consult the host python to determine which is preferable. >If I understand Mark correctly, the MSVC 7 GUI doesn't pick up the >enviroment vars itself - this is (one of?) the difficultiy I see. > >Thomas > > >_______________________________________________ >Distutils-SIG maillist - Distutils-SIG@python.org >http://mail.python.org/mailman/listinfo/distutils-sig > -- Robin Becker From mal at egenix.com Wed Feb 4 04:03:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 4 04:02:53 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: References: Message-ID: <4020B557.9080702@egenix.com> Robin Becker wrote: > In article , Thomas Heller > writes > ..... > >>>A patch to honor environment variables when they are set would help >>>developers and, presumably, hurt no one. (No real Windows user would set an >>>environment variable anyway.) >> >>I'm not sure I'm in the position to pronounce on this, but: If someone >>comes up with a patch that does this, I have nothing against it. But >>I'm not prepared to support and/or debug configurations the users may >>have which are very different from my own. >> > > this seems a bit harsh to me; I understand the part about being unable > to debug, but surely this software is supposed to be a bit more robust. > It is after all the product of more than one person and is now in the > standard distro. Even M$ gives us VCVARS32.BAT so they presumably > believe in that. I don't buy the argument about having to use the gui to > set stuff up as distutils is a script/command line tool. I suppose we > now face more difficult times with both MSC7/6 as the 'standard', but > isn't that why distutils should consult the host python to determine > which is preferable. > >>If I understand Mark correctly, the MSVC 7 GUI doesn't pick up the >>enviroment vars itself - this is (one of?) the difficultiy I see. I'm not sure I can follow you guys here: distutils is a command line tools, so why should we worry about the GUI of the compiler ? Indeed, the freely available C++ compiler in the .NET SDK should be enough to get distutils working with C extensions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 04 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/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From phil.hornby at accutest.co.uk Wed Feb 4 06:06:44 2004 From: phil.hornby at accutest.co.uk (Phil Hornby) Date: Wed Feb 4 06:11:03 2004 Subject: [Distutils] Distutils windows binaries... Message-ID: Thomas, > You can customize distutils to do *anything* you want by subclassing. > The basic functionality, however, assumes you are distributing python > modules, scripts, and extensions. And distutils actually is the easiest > way imo to also *build* the extensions. Generally I build and test my modules individually or do releases through an automated into our build/release management system that is very simple and as such using distutils wouldn't fit in very easily/well. > IIRC, you can also use the borland compiler to build the extensions - > see the output of 'python setup.py build_ext --help-compiler'. Thanks I had just noticed that...but as I am trying to move away from that compiler - and only have it on my machine for legacy reason it's not needed. >> >> I know you can change the bitmap displayed during the install but can you >> change the icon that is displayed for the *.exe that is generated? > > You can change the icon of the > Lib/site-packages/distutils/command/wininst.exe with any tool of your > choice, *before* building the installer. I would like to do this programatically instead of doing it manually. Anyone know of a python tool that can do that...or is that gonna have to be a project of my own? I am also interested to know why you stressed the *before* statement - surely I could change the icon on the produced *.exe? and as such after building the installer? Thanks... -- Phil "Requirements - what are they I just hack something together that does what I think they want" ;) From theller at python.net Wed Feb 4 10:58:47 2004 From: theller at python.net (Thomas Heller) Date: Wed Feb 4 10:59:10 2004 Subject: [Distutils] Distutils windows binaries... In-Reply-To: (Phil Hornby's message of "Wed, 4 Feb 2004 11:06:44 -0000") References: Message-ID: >>> I know you can change the bitmap displayed during the install but can you >>> change the icon that is displayed for the *.exe that is generated? >> >> You can change the icon of the >> Lib/site-packages/distutils/command/wininst.exe with any tool of your >> choice, *before* building the installer. > > I would like to do this programatically instead of doing it manually. Anyone > know of a python tool that can do that...or is that gonna have to be a > project of my own? I am also interested to know why you stressed the > *before* statement - surely I could change the icon on the produced *.exe? > and as such after building the installer? Well, the finished installer exe-file is actually wininst.exe plus an appended zip-archive. I haven't tried tools other than MSVC 6, which is able to edit resources in binary files (there are also others), but MSVC6 is confused by the appended zip-portion. I don't know of a Python tool which does this, but py2exe contains a compiled extension which updates the icon resources. You can probably either use this as is (it's the py2exe_util.pyd), or you use the source code and translate the calls into win32all or ctypes calls. Thomas From theller at python.net Wed Feb 4 11:18:02 2004 From: theller at python.net (Thomas Heller) Date: Wed Feb 4 11:18:29 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: (Robin Becker's message of "Wed, 4 Feb 2004 08:53:31 +0000") References: Message-ID: Robin Becker writes: > In article , Thomas Heller > writes > ..... >>> >>> A patch to honor environment variables when they are set would help >>> developers and, presumably, hurt no one. (No real Windows user would set an >>> environment variable anyway.) >> >>I'm not sure I'm in the position to pronounce on this, but: If someone >>comes up with a patch that does this, I have nothing against it. But >>I'm not prepared to support and/or debug configurations the users may >>have which are very different from my own. >> > > this seems a bit harsh to me; I understand the part about being unable > to debug, but surely this software is supposed to be a bit more robust. Yes, it was too harsh, and I apologize for that. I was concerned about backwards compatibility and such. > It is after all the product of more than one person and is now in the > standard distro. Even M$ gives us VCVARS32.BAT so they presumably > believe in that. I don't buy the argument about having to use the gui to > set stuff up as distutils is a script/command line tool. Most probably a misunderstanding: Nobody needs to use the compiler gui or ide with distutils. *But the ide has to be started at least once* after installing MSVC 6 to create all the registry entries that distutils reads. It took quite some time to find this out, and I worked on quite a lot of bug reports to SF and on c.l.p for this. I don't know whether 7.x requires it or not. > I suppose we now face more difficult times with both MSC7/6 as the > 'standard', but isn't that why distutils should consult the host > python to determine which is preferable. > So, please someone submit a patch to let distutils use the environment. And apologies again, Thomas From phil.hornby at accutest.co.uk Wed Feb 4 12:09:43 2004 From: phil.hornby at accutest.co.uk (Phil Hornby) Date: Wed Feb 4 12:14:06 2004 Subject: [Distutils] Distutils windows binaries... In-Reply-To: Message-ID: Thomas, Thanks for the info....IT WORKS!! import py2exe.py2exe_util py2exe.py2exe_util.update_icon( U'wininst.exe', U'myicon.ico', 1 ) the little code snippet above will change the ico for a *.exe but deletes any other resources. This includes the attached zip archive in the produced installers... so my assumption is that the archive is appended as a resource. So my guess is that I will have to modify the exe pre- building the distro package. I may do it by making a temporary copy of the wininst.exe before adding the zip archive and modify this temporary version - so as not to change the version in the main python dir. I haven't done much testing with it - including whether the modified installer work but the ico is modified happily - the one potential issue I could see is if the more resources exist within the installer other than the basic installer icon as this code delete's all reasources in the file. When I have a working sample - that doesn't need py2exe installed - I will make it available by posting here - incase you want to put the functionality into the official version. -- Phil "Requirements - what are they I just hack something together that does what I think they want" ;) >>>> I know you can change the bitmap displayed during the install but can you >>>> change the icon that is displayed for the *.exe that is generated? >>> >>> You can change the icon of the >>> Lib/site-packages/distutils/command/wininst.exe with any tool of your >>> choice, *before* building the installer. >> >> I would like to do this programatically instead of doing it manually. Anyone >> know of a python tool that can do that...or is that gonna have to be a >> project of my own? I am also interested to know why you stressed the >> *before* statement - surely I could change the icon on the produced *.exe? >> and as such after building the installer? > > Well, the finished installer exe-file is actually wininst.exe plus an > appended zip-archive. I haven't tried tools other than MSVC 6, which is > able to edit resources in binary files (there are also others), but > MSVC6 is confused by the appended zip-portion. > > I don't know of a Python tool which does this, but py2exe contains a > compiled extension which updates the icon resources. You can probably > either use this as is (it's the py2exe_util.pyd), or you use the source > code and translate the calls into win32all or ctypes calls. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig From garth at utmail.to Wed Feb 4 12:27:05 2004 From: garth at utmail.to (G D) Date: Wed Feb 4 12:27:13 2004 Subject: [Distutils] Problem compiling Extensions on Win32 Message-ID: <200402041727.i14HR58x028762@rs4.luxsci.com> This is proably a dumb noobie question, but hopefully some of you have seen this type of thing before. I'm trying to compile a set of Extensions for a Zope app, I'm using the Python that came with Zope2.7RC2 which is Py 2.3.3 on a Windows system. After setting the system path to include the Zope bin and bin\include directories (where the Python.exe and the header files live), I attempt to compile the extensions by doing the following. python setup.py build -cmingw32 I get a hole bunch of undefined interface type errors (the computer's at home so I'm going by memory) similar to __Inf__PyString undefined, and it ends off with a line about WinMain@16 with that setup terminates. When I try the same thing with MSVC7 (from the .NET 1.1 SDK), I get an error message that Python was compiled with Visual C 6 and modules must be compiled with that compiler. The seemingly odd thing to me is when I try it with MSVC6 Std Ed (starting a new cmd prompt and loading the VC6 .bat file for environment), I get the same error message - which doesn't make sense. I'm a bit confused, is there something else to compiling under windows I'm missing? do I need to be in MSys (I've just been trying from cmd)? Any suggestions greatly appriecated, Cheers -Garth Northern.CA ===-- http://www.northern.ca Canada's Search Engine From theller at python.net Wed Feb 4 13:48:22 2004 From: theller at python.net (Thomas Heller) Date: Wed Feb 4 13:48:44 2004 Subject: [Distutils] Distutils windows binaries... In-Reply-To: (Phil Hornby's message of "Wed, 4 Feb 2004 17:09:43 -0000") References: Message-ID: "Phil Hornby" writes: > Thomas, > > Thanks for the info....IT WORKS!! > > import py2exe.py2exe_util > > py2exe.py2exe_util.update_icon( U'wininst.exe', U'myicon.ico', 1 ) > > the little code snippet above will change the ico for a *.exe but deletes > any other resources. The last parameter is a flag which specifies whether to delete existing resources or not. Setting it to 0 should keep them intact. > This includes the attached zip archive in the produced > installers... so my assumption is that the archive is appended as a > resource. No, it isn't. It it simply appended to the exe-file, look into bdist_wininst.py to see how it's done. Other resources present in wininst.exe are the dialogs needed for the gui. > So my guess is that I will have to modify the exe pre- building > the distro package. I may do it by making a temporary copy of the > wininst.exe before adding the zip archive and modify this temporary > version - so as not to change the version in the main python dir. I guess you can do it by subclassing the bdist_wininst class in bdist_wininst.py - read the sources. > I haven't done much testing with it - including whether the modified > installer work but the ico is modified happily - the one potential issue I > could see is if the more resources exist within the installer other than the > basic installer icon as this code delete's all reasources in the file. > > When I have a working sample - that doesn't need py2exe installed - I will > make it available by posting here - incase you want to put the functionality > into the official version. Cool. Thomas From theller at python.net Wed Feb 4 13:56:55 2004 From: theller at python.net (Thomas Heller) Date: Wed Feb 4 13:57:18 2004 Subject: [Distutils] Problem compiling Extensions on Win32 In-Reply-To: <200402041727.i14HR58x028762@rs4.luxsci.com> (G. D.'s message of "Wed, 04 Feb 2004 17:27:05 +0000") References: <200402041727.i14HR58x028762@rs4.luxsci.com> Message-ID: "G D" writes: > This is proably a dumb noobie question, but hopefully some of you have > seen this type of thing before. > > I'm trying to compile a set of Extensions for a Zope app, I'm using > the Python that came with Zope2.7RC2 which is Py 2.3.3 on a Windows > system. > > After setting the system path to include the Zope bin and bin\include > directories (where the Python.exe and the header files live), I > attempt to compile the extensions by doing the following. > > python setup.py build -cmingw32 > > I get a hole bunch of undefined interface type errors (the computer's > at home so I'm going by memory) similar to __Inf__PyString undefined, > and it ends off with a line about WinMain@16 with that setup > terminates. I know near to nothing about mingw, so I have no suggestion here. > When I try the same thing with MSVC7 (from the .NET 1.1 SDK), I get an > error message that Python was compiled with Visual C 6 and modules > must be compiled with that compiler. which is correct... > The seemingly odd thing to me is when I try it with MSVC6 Std Ed > (starting a new cmd prompt and loading the VC6 .bat file for > environment), I get the same error message - which doesn't make sense. We just had this issue - distutils doesn't pick up the usual environment variables. It only reads from the registry. Look into the sources for distutils/msvccompiler.py. On my machine, the directories are in the registry as values of the key HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Build System\Components\Platforms\Win32 (x86)\Directories Is this key present on your machine, and has it 'Include Dirs', 'Library Dirs', and 'Path Dirs' values? Thomas From phil.hornby at accutest.co.uk Wed Feb 4 15:45:58 2004 From: phil.hornby at accutest.co.uk (Phil Hornby) Date: Wed Feb 4 15:52:52 2004 Subject: [Distutils] Distutils windows binaries... In-Reply-To: Message-ID: >> Thanks for the info....IT WORKS!! >> >> import py2exe.py2exe_util >> > py2exe.py2exe_util.update_icon( U'wininst.exe', U'myicon.ico', 1 ) > > the little code snippet above will change the ico for a *.exe but deletes > any other resources. > > The last parameter is a flag which specifies whether to delete existing > resources or not. Setting it to 0 should keep them intact. Doing this the seems to not modify the right resource...or maybe I just need to work out exactly which resource it is that I need to mod... >> This includes the attached zip archive in the produced >> installers... so my assumption is that the archive is appended as a >> resource. > > No, it isn't. It it simply appended to the exe-file, look into > bdist_wininst.py to see how it's done. > > Other resources present in wininst.exe are the dialogs needed for the > gui. Okay I had seen what was done in with appending the data - I assumed that it was simply faking up an entry in the exe's resource table. >> So my guess is that I will have to modify the exe pre- building >> the distro package. I may do it by making a temporary copy of the >> wininst.exe before adding the zip archive and modify this temporary >> version - so as not to change the version in the main python dir. > > I guess you can do it by subclassing the bdist_wininst class in > bdist_wininst.py - read the sources. That was my plan... >> I haven't done much testing with it - including whether the modified >> installer work but the ico is modified happily - the one potential issue I >> could see is if the more resources exist within the installer other than the >> basic installer icon as this code delete's all reasources in the file. >> >> When I have a working sample - that doesn't need py2exe installed - I will >> make it available by posting here - incase you want to put the functionality >> into the official version. > > Cool. Although I think my first version will simply use the stuff from py2exe - testing for it's presence... this might be the best solution anyway - as why would I want to re-invent the wheel...;) -- Phil "Requirements - what are they I just hack something together that does what I think they want" ;) From mhammond at skippinet.com.au Wed Feb 4 19:15:14 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed Feb 4 19:17:10 2004 Subject: [Distutils] MSVC CRT woes Message-ID: <014b01c3eb7d$211c7ba0$0200a8c0@eden> One of our politicians famously uttered "life wasn't meant to be easy" - how right he was :) Let's assume I am trying to use distutils from Python 2.4 to package an installation for both Python 2.3 and Python 2.4 (or vice-versa - trying to use 2.3 distutils to package them both). As mentioned her previously, I want to do this so I can use the features in later versions of distutils (such as the post-install-script) to package extensions for earlier versions of Python. The installation script uses PyRun_SimpleFile. This takes a FILE *. The problem is that Python 2.3 and Python 2.4 use different runtime libraries. One of them is guaranteed to crash. This violates the Python rule that Python and its extensions must use the same CRTL. I see 2 choices: * Avoid PyRun_SimpleFile, by reading the file ourself, and using PyRun_SimpleString. This should work, but is fragile, as we are still breaking that rule. * Provide 2 different wininst.exe stubs, one for MSVC6 and one for MSVC7. distutils hardcodes the knowledge of what one to use for what version. However, the problem is that this will mean people building distutils to ship will always need *both* VC6 and VC7 - VC6 just for that stub, and VC7 to build everything else. The first option is less work, and should work today, but is still naughty. Any thoughts? Mark. From mhammond at skippinet.com.au Wed Feb 4 19:24:41 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed Feb 4 19:24:57 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: Message-ID: <01af01c3eb7e$7330f1e0$0200a8c0@eden> > If I understand Mark correctly, the MSVC 7 GUI doesn't pick up the > enviroment vars itself - this is (one of?) the difficultiy I see. Nope, this isn't a problem. I have 2 specific problems: * Manually setting LIB/INCLUDE has no effect, as distutils overwrites these values with what it thinks they should be * MSVC7 doesn't seem to store its paths in the registry. MSVC7's GUI probably doesn't pick up the LIB/INCLUDE vars at startup time - but this is rarely an issue - the only time I expect to set or use these vars is when running from the command-line (which is exactly where distutils is run from :) I think there is a simple fix to keep most people happy. distutils can just *append* the existing env var value to the new value. I think it is acceptable to say distutils wont let you set these to change the location of standard libraries or headers, but will let you add new ones. Mark. From mal at egenix.com Wed Feb 4 19:28:45 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 4 19:48:14 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <014b01c3eb7d$211c7ba0$0200a8c0@eden> References: <014b01c3eb7d$211c7ba0$0200a8c0@eden> Message-ID: <40218E3D.1040805@egenix.com> Mark Hammond wrote: > One of our politicians famously uttered "life wasn't meant to be easy" - how > right he was :) > > Let's assume I am trying to use distutils from Python 2.4 to package an > installation for both Python 2.3 and Python 2.4 (or vice-versa - trying to > use 2.3 distutils to package them both). As mentioned her previously, I > want to do this so I can use the features in later versions of distutils > (such as the post-install-script) to package extensions for earlier versions > of Python. > > The installation script uses PyRun_SimpleFile. This takes a FILE *. The > problem is that Python 2.3 and Python 2.4 use different runtime libraries. > One of them is guaranteed to crash. This violates the Python rule that > Python and its extensions must use the same CRTL. > > I see 2 choices: > * Avoid PyRun_SimpleFile, by reading the file ourself, and using > PyRun_SimpleString. This should work, but is fragile, as we are still > breaking that rule. > * Provide 2 different wininst.exe stubs, one for MSVC6 and one for MSVC7. > distutils hardcodes the knowledge of what one to use for what version. > However, the problem is that this will mean people building distutils to > ship will always need *both* VC6 and VC7 - VC6 just for that stub, and VC7 > to build everything else. > > The first option is less work, and should work today, but is still naughty. > Any thoughts? Just to understand this: will this mean that you have to have VC7 in order to build extensions for Python 2.4 and onwards ? I think it is worthwhile (and have always argued that way) to have one distutils version which can create Python distributables for various Python versions, including as many older versions as possible. Does the move to VC7 mean that we'll break this strategy with Python 2.4 distutils ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 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/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mhammond at skippinet.com.au Wed Feb 4 20:04:44 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed Feb 4 20:05:01 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <40218E3D.1040805@egenix.com> Message-ID: <041901c3eb84$0b33a410$0200a8c0@eden> > Just to understand this: will this mean that you have to have VC7 > in order to build extensions for Python 2.4 and onwards ? Officially, I think it will. Unofficially, it will remain like it does today - it *may* work (depending on if you try and use Python API functions that use FILE objects). IIRC, there used to be a problem of you implemented objects, as the malloc/free pairs happened in different CRTLs, but I think that in recent versions the macro-magic means they do match) A Python API function "PyFile_OpenFile()" would also solve this issue, but obviously that wouldn't exist in 2.3 or earlier, so doesn't help this specific case. > I think it is worthwhile (and have always argued that way) to have one > distutils version which can create Python distributables for various > Python versions, including as many older versions as possible. I believe that is the intent. There is one other small issue I had trying to do this for win32all, but I will address that later. > Does the move to VC7 mean that we'll break this strategy with > Python 2.4 distutils ? Yes, unless we do as outlined in my mail. Mark. From mdehoon at ims.u-tokyo.ac.jp Wed Feb 4 20:29:51 2004 From: mdehoon at ims.u-tokyo.ac.jp (Michiel Jan Laurens de Hoon) Date: Wed Feb 4 20:25:53 2004 Subject: [Distutils] Problem compiling Extensions on Win32 In-Reply-To: <200402041727.i14HR58x028762@rs4.luxsci.com> References: <200402041727.i14HR58x028762@rs4.luxsci.com> Message-ID: <40219C8F.3060700@ims.u-tokyo.ac.jp> G D wrote: > python setup.py build -cmingw32 > > I get a hole bunch of undefined interface type errors (the computer's at home > so I'm going by memory) similar to __Inf__PyString undefined, and it ends off > with a line about WinMain@16 with that setup terminates. If these are linking errors, the problem might be that you don't have a gcc-style Python library. See http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/software/python/cygwin.html for details on how to get one. > I'm a bit confused, is there something else to compiling under windows I'm > missing? do I need to be in MSys (I've just been trying from cmd)? Usually I run this from Cygwin's command prompt (using Windows' Python), which works fine. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon From R.Liebscher at gmx.de Thu Feb 5 02:54:20 2004 From: R.Liebscher at gmx.de (=?iso-8859-1?Q?Ren=E9?= Liebscher) Date: Thu Feb 5 02:54:53 2004 Subject: [Distutils] Problem compiling Extensions on Win32 References: <200402041727.i14HR58x028762@rs4.luxsci.com> <40219C8F.3060700@ims.u-tokyo.ac.jp> Message-ID: <4021F6AC.103B5B54@gmx.de> Michiel Jan Laurens de Hoon schrieb: > > G D wrote: > > > python setup.py build -cmingw32 > > > > I get a hole bunch of undefined interface type errors (the computer's at home > > so I'm going by memory) similar to __Inf__PyString undefined, and it ends off > > with a line about WinMain@16 with that setup terminates. > > If these are linking errors, the problem might be that you don't have a > gcc-style Python library. See > http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/software/python/cygwin.html > for details on how to get one. > > >... > ... > > --Michiel. This is the same what you can find in the documentation http://python.org/doc/current/inst/tweak-flags.html#SECTION000622000000000000000 But nobody seems to read it. Maybe the compiler class should check for libpython??.a and print a warning with a link to the documentation. --Rene From Paul.Moore at atosorigin.com Thu Feb 5 04:30:50 2004 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Thu Feb 5 04:30:54 2004 Subject: [Distutils] MSVC CRT woes Message-ID: <16E1010E4581B049ABC51D4975CEDB8803060DE0@UKDCX001.uk.int.atosorigin.com> From: Mark Hammond >> Just to understand this: will this mean that you have to have VC7 >> in order to build extensions for Python 2.4 and onwards ? > Officially, I think it will. Unofficially, it will remain like it does > today - it *may* work (depending on if you try and use Python API functions > that use FILE objects). IIRC, there used to be a problem of you implemented > objects, as the malloc/free pairs happened in different CRTLs, but I think > that in recent versions the macro-magic means they do match) I believe that mingw will build extensions which work with Python 2.3 and 2.4, because mingw supports both MSVC runtimes. You still have to build the extension using distutils from the appropriate Python version (ie, you need 2 Python versions installed). > A Python API function "PyFile_OpenFile()" would also solve this issue, but > obviously that wouldn't exist in 2.3 or earlier, so doesn't help this > specific case. According to Martin von Loewis, this is a lost cause - mixing runtimes is never OK, even if you don't use "dangerous" functions (like ones which use FILE*). However, in practical terms, I've never generated a problem (although I haven't tried very hard). >> I think it is worthwhile (and have always argued that way) to have one >> distutils version which can create Python distributables for various >> Python versions, including as many older versions as possible. > I believe that is the intent. There is one other small issue I had trying > to do this for win32all, but I will address that later. >> Does the move to VC7 mean that we'll break this strategy with >> Python 2.4 distutils ? > Yes, unless we do as outlined in my mail. I may be misunderstanding what is being discussed here, but I believe that with the move to VC7, you will need the following to build extensions compatible with both Python 2.3 and 2.4: 1. Installed copies of both Python 2.3 and 2.4. 2. EITHER MSVC 6 and 7 (both versions) OR mingw But I am probably missing something, as once you have the 2 versions of Python installed, I don't see the value in using a single shared distutils, rather than the one that comes with each Python. teaching-my-grandmother-to-suck-eggs-ly y'rs Paul. From mhammond at skippinet.com.au Thu Feb 5 04:45:01 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu Feb 5 04:45:21 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8803060DE0@UKDCX001.uk.int.atosorigin.com> Message-ID: <1dea01c3ebcc$bbf7a290$0200a8c0@eden> > > A Python API function "PyFile_OpenFile()" would also solve > > this issue, but obviously that wouldn't exist in 2.3 or > > earlier, so doesn't help this specific case. > > According to Martin von Loewis, this is a lost cause - mixing > runtimes is > never OK, even if you don't use "dangerous" functions (like > ones which use > FILE*). However, in practical terms, I've never generated a > problem (although > I haven't tried very hard). Yes, hence I never pursued it. "Although practicality beats purity" seems to apply, but I don't care enough to push it. > >> Does the move to VC7 mean that we'll break this strategy with > >> Python 2.4 distutils ? > > > Yes, unless we do as outlined in my mail. > > I may be misunderstanding what is being discussed here, but I > believe that with > the move to VC7, you will need the following to build > extensions compatible with > both Python 2.3 and 2.4: > > 1. Installed copies of both Python 2.3 and 2.4. > 2. EITHER MSVC 6 and 7 (both versions) OR mingw Yes, that is true for all practical intent, if your installation has extension modules. However, for a pure-python distribution, you need *no* compilers installed. In that case, we still have a problem - at the moment, the installation is guaranteed to fail for either Python 2.3 and before, or for 2.4, depending on which CRTL was used to build wininst.exe. To clarfify, I am talking about only how wininst.exe interacts with Python, not extension building related issues (even though they are similar). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2476 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040205/d7801e21/winmail.bin From Paul.Moore at atosorigin.com Thu Feb 5 04:54:04 2004 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Thu Feb 5 04:54:06 2004 Subject: [Distutils] MSVC CRT woes Message-ID: <16E1010E4581B049ABC51D4975CEDB8803060DE1@UKDCX001.uk.int.atosorigin.com> From: Mark Hammond >> 1. Installed copies of both Python 2.3 and 2.4. >> 2. EITHER MSVC 6 and 7 (both versions) OR mingw > Yes, that is true for all practical intent, if your installation > has extension modules. However, for a pure-python distribution, you > need *no* compilers installed. In that case, we still have a problem > - at the moment, the installation is guaranteed to fail for either > Python 2.3 and before, or for 2.4, depending on which CRTL was used > to build wininst.exe. > To clarify, I am talking about only how wininst.exe interacts with > Python, not extension building related issues (even though they are > similar). Ah. I follow. In that case, yes I agree that practicality should beat purity, and whatever works would make sense. My feeling is that reading the file into a string and using the Py...RunString function is the sensible option here. After all (as I posted in python-dev) OLEAUT32.DLL uses MSVCRT.DLL, and works happily with MSVC7-compiled DLLs (at least it had better!!!), so there is at least *some* indication that DLLs can interact with EXEs which use a different CRT (as long as sufficient care is taken). Paul. From mal at egenix.com Thu Feb 5 04:59:42 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 5 04:59:17 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8803060DE0@UKDCX001.uk.int.atosorigin.com> References: <16E1010E4581B049ABC51D4975CEDB8803060DE0@UKDCX001.uk.int.atosorigin.com> Message-ID: <4022140E.6030809@egenix.com> Moore, Paul wrote: > From: Mark Hammond > >>>Does the move to VC7 mean that we'll break this strategy with >>>Python 2.4 distutils ? > > >>Yes, unless we do as outlined in my mail. > > > I may be misunderstanding what is being discussed here, but I believe that with > the move to VC7, you will need the following to build extensions compatible with > both Python 2.3 and 2.4: > > 1. Installed copies of both Python 2.3 and 2.4. > 2. EITHER MSVC 6 and 7 (both versions) OR mingw > > But I am probably missing something, as once you have the 2 versions of Python > installed, I don't see the value in using a single shared distutils, rather than > the one that comes with each Python. The latter would mean having to support 3-4 different distutils versions in your setup code. We already support 3-4 different Python versions (at Python and C level) and would like, if at all possible, to continue building all packages with one distutils version - the one in CVS which is the most up-to-date. That said, I think that including two wininst versions, one compiled with VC6, the other with VC7, would solve this problem nicely. You'd still have to have VC6/7 for compiling C extensions, but at least generating pure Python distutils wininst packages would remain possible. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 05 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/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mhammond at skippinet.com.au Thu Feb 5 05:14:34 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu Feb 5 05:14:48 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <4022140E.6030809@egenix.com> Message-ID: <1f1901c3ebd0$db2cb110$0200a8c0@eden> > The latter would mean having to support 3-4 different distutils > versions in your setup code. We already support 3-4 different Python > versions (at Python and C level) and would like, if at all possible, > to continue building all packages with one distutils version - the > one in CVS which is the most up-to-date. Just to throw one more minor spanner in the works, I believe I will be able to provide a patch that means you must *build* your extension with the Python version that the version targets - but can create a binary distribution, for any Python version, using a single distutils version (assuming it was previously built correctly) I agree that in the future we should also allow you to build your extensions using the most recent, but that is far less critical when you consider other users - if someone other than the primary packager wants to build your package, they probably don't have the 'latest' distutils available to them. > That said, I think that including two wininst versions, one > compiled with VC6, the other with VC7, would solve this problem > nicely. You'd still have to have VC6/7 for compiling C extensions, > but at least generating pure Python distutils wininst packages > would remain possible. Keeping the 'practicallity beats purity' theme, I agree. It means that whoever builds (and checks into CVS) wininst.exe must has *both* MSVC6 and MSVC7, but there is a good chance they will anyway. Is there any reason wininst.exe is not itself built using distutils? Mark. From theller at python.net Thu Feb 5 05:28:39 2004 From: theller at python.net (Thomas Heller) Date: Thu Feb 5 05:29:06 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <4022140E.6030809@egenix.com> (M.'s message of "Thu, 05 Feb 2004 10:59:42 +0100") References: <16E1010E4581B049ABC51D4975CEDB8803060DE0@UKDCX001.uk.int.atosorigin.com> <4022140E.6030809@egenix.com> Message-ID: <3c9pddm0.fsf@python.net> "M.-A. Lemburg" writes: > That said, I think that including two wininst versions, one > compiled with VC6, the other with VC7, would solve this problem > nicely. You'd still have to have VC6/7 for compiling C extensions, > but at least generating pure Python distutils wininst packages > would remain possible. Yes, I think that's the best option. I will make this change as soon as I have time (I'm not *actually* using 2.4 already). Thomas From phil.hornby at accutest.co.uk Thu Feb 5 05:26:40 2004 From: phil.hornby at accutest.co.uk (Phil Hornby) Date: Thu Feb 5 05:31:02 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <1f1901c3ebd0$db2cb110$0200a8c0@eden> Message-ID: >> That said, I think that including two wininst versions, one >> compiled with VC6, the other with VC7, would solve this problem >> nicely. You'd still have to have VC6/7 for compiling C extensions, >> but at least generating pure Python distutils wininst packages >> would remain possible. > > Keeping the 'practicallity beats purity' theme, I agree. It means that > whoever builds (and checks into CVS) wininst.exe must has *both* MSVC6 and > MSVC7, but there is a good chance they will anyway. > > Is there any reason wininst.exe is not itself built using distutils? my assumption on the later is purely that if it was the user would HAVE to have a compiler installed - but if they are writing pure python extensions they *should* not need this as they are not likely to have it. But maybe adding the functionality to force a build if building a C extension is a worthwhile thing?? Just to add my two pence to the debate... -- Phil "Requirements - what are they I just hack something together that does what I think they want" ;) From mal at egenix.com Thu Feb 5 05:31:49 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 5 05:31:25 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <1f1901c3ebd0$db2cb110$0200a8c0@eden> References: <1f1901c3ebd0$db2cb110$0200a8c0@eden> Message-ID: <40221B95.4090006@egenix.com> Mark Hammond wrote: >>The latter would mean having to support 3-4 different distutils >>versions in your setup code. We already support 3-4 different Python >>versions (at Python and C level) and would like, if at all possible, >>to continue building all packages with one distutils version - the >>one in CVS which is the most up-to-date. > > Just to throw one more minor spanner in the works, I believe I will be able > to provide a patch that means you must *build* your extension with the > Python version that the version targets - but can create a binary > distribution, for any Python version, using a single distutils version > (assuming it was previously built correctly) That would be ideal. > I agree that in the future we should also allow you to build your extensions > using the most recent, but that is far less critical when you consider other > users - if someone other than the primary packager wants to build your > package, they probably don't have the 'latest' distutils available to them. True, but at least I can point at a place where to download and install it (not the CVS one, but latest released one). I think that's a reasonable thing to ask from users if they want to build wininst packages that are different from the ones we distribute. From source installations (still) work rather nicely across all distutils versions - at least on Unix platforms which is where people care about source installations. Windows folks are happy with the wininst installer, so it's a non-issue for those. >>That said, I think that including two wininst versions, one >>compiled with VC6, the other with VC7, would solve this problem >>nicely. You'd still have to have VC6/7 for compiling C extensions, >>but at least generating pure Python distutils wininst packages >>would remain possible. > > Keeping the 'practicallity beats purity' theme, I agree. It means that > whoever builds (and checks into CVS) wininst.exe must has *both* MSVC6 and > MSVC7, but there is a good chance they will anyway. > > Is there any reason wininst.exe is not itself built using distutils? No idea :-) That one is for Thomas to answer. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 05 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/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From theller at python.net Thu Feb 5 05:31:26 2004 From: theller at python.net (Thomas Heller) Date: Thu Feb 5 05:31:48 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8803060DE1@UKDCX001.uk.int.atosorigin.com> (Paul Moore's message of "Thu, 5 Feb 2004 09:54:04 -0000") References: <16E1010E4581B049ABC51D4975CEDB8803060DE1@UKDCX001.uk.int.atosorigin.com> Message-ID: "Moore, Paul" writes: > After all (as I posted in python-dev) OLEAUT32.DLL uses MSVCRT.DLL, and > works happily with MSVC7-compiled DLLs (at least it had better!!!), so > there is at least *some* indication that DLLs can interact with EXEs > which use a different CRT (as long as sufficient care is taken). That doesn't matter. OLEAUT32 probably allocates and frees memory using functions on MSVCRT.DLL, independent from what the exe is using. And the exe should better not allocate with MSVCRT.DLL and free this with MSVCR70.DLL. Thomas From theller at python.net Thu Feb 5 05:34:02 2004 From: theller at python.net (Thomas Heller) Date: Thu Feb 5 05:34:26 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: <01af01c3eb7e$7330f1e0$0200a8c0@eden> (Mark Hammond's message of "Thu, 5 Feb 2004 11:24:41 +1100") References: <01af01c3eb7e$7330f1e0$0200a8c0@eden> Message-ID: "Mark Hammond" writes: [Thomas] >> If I understand Mark correctly, the MSVC 7 GUI doesn't pick up the >> enviroment vars itself - this is (one of?) the difficultiy I see. > > Nope, this isn't a problem. I have 2 specific problems: > > * Manually setting LIB/INCLUDE has no effect, as distutils overwrites these > values with what it thinks they should be > * MSVC7 doesn't seem to store its paths in the registry. > > MSVC7's GUI probably doesn't pick up the LIB/INCLUDE vars at startup time - > but this is rarely an issue - the only time I expect to set or use these > vars is when running from the command-line (which is exactly where distutils > is run from :) > > I think there is a simple fix to keep most people happy. distutils can just > *append* the existing env var value to the new value. I think it is > acceptable to say distutils wont let you set these to change the location of > standard libraries or headers, but will let you add new ones. So there's no need to read the entries set in MSVC7 itself (for which you have uploaded a patch) ? Thomas From mal at egenix.com Thu Feb 5 05:36:02 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 5 05:35:38 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <3c9pddm0.fsf@python.net> References: <16E1010E4581B049ABC51D4975CEDB8803060DE0@UKDCX001.uk.int.atosorigin.com> <4022140E.6030809@egenix.com> <3c9pddm0.fsf@python.net> Message-ID: <40221C92.5090505@egenix.com> Thomas Heller wrote: > "M.-A. Lemburg" writes: > > >>That said, I think that including two wininst versions, one >>compiled with VC6, the other with VC7, would solve this problem >>nicely. You'd still have to have VC6/7 for compiling C extensions, >>but at least generating pure Python distutils wininst packages >>would remain possible. > > > Yes, I think that's the best option. I will make this change as soon as > I have time Great :-) > (I'm not *actually* using 2.4 already). Same here. We are building 2.4 versions of our packages for testing purposes every now and then, but only on Linux where we don't have the libc vs. glibc problem (anymore). For Linux the UCS4 vs. UCS2 build (ie. Redhat vs. the rest of the world) problem is a much more serious one, but that's a different topic. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 05 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/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From theller at python.net Thu Feb 5 05:44:30 2004 From: theller at python.net (Thomas Heller) Date: Thu Feb 5 05:44:55 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <1f1901c3ebd0$db2cb110$0200a8c0@eden> (Mark Hammond's message of "Thu, 5 Feb 2004 21:14:34 +1100") References: <1f1901c3ebd0$db2cb110$0200a8c0@eden> Message-ID: "Mark Hammond" writes: > Is there any reason wininst.exe is not itself built using distutils? At that time distutils couldn't build exe files, and since I had the workspace anyway I didn't care. IIRC, Rene Liebscher posted a script to build wininst with distutils. Thomas From phil.hornby at accutest.co.uk Thu Feb 5 06:31:36 2004 From: phil.hornby at accutest.co.uk (Phil Hornby) Date: Thu Feb 5 06:35:57 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: Message-ID: Thomas, Hmm this doesn't seem to have made it to the list but just incase it turns up in a bit...ignore it...I have got something working without a need to change the exe... > Could you explicity add an icon as the apps icon - as when I have looked at the sources there isn't one - so it is > hard for me to write code to replace it - my earlier thread - if it doesn't explicitly exist as I need to know the > resource id to change it... > > I will try to put something together for you when I have some time...but I only have MSVC7.1 so I can't give you a > project for MSVC6. -- Phil "Requirements - what are they I just hack something together that does what I think they want" ;) From R.Liebscher at gmx.de Thu Feb 5 07:36:59 2004 From: R.Liebscher at gmx.de (=?iso-8859-1?Q?Ren=E9?= Liebscher) Date: Thu Feb 5 07:37:21 2004 Subject: [Distutils] MSVC CRT woes References: <1f1901c3ebd0$db2cb110$0200a8c0@eden> Message-ID: <402238EB.8190A596@gmx.de> Thomas Heller schrieb: > > "Mark Hammond" writes: > > > Is there any reason wininst.exe is not itself built using distutils? > > At that time distutils couldn't build exe files, and since I had the > workspace anyway I didn't care. > > IIRC, Rene Liebscher posted a script to build wininst with distutils. See http://mail.python.org/pipermail/distutils-sig/2001-April/002329.html But it is probably not up to date. Rene Liebscher From phil.hornby at accutest.co.uk Thu Feb 5 05:44:43 2004 From: phil.hornby at accutest.co.uk (Phil Hornby) Date: Thu Feb 5 11:11:41 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <40221C92.5090505@egenix.com> Message-ID: >>>That said, I think that including two wininst versions, one >>>compiled with VC6, the other with VC7, would solve this problem >>>nicely. You'd still have to have VC6/7 for compiling C extensions, >>>but at least generating pure Python distutils wininst packages >>>would remain possible. >> >> >> Yes, I think that's the best option. I will make this change as soon as >> I have time > > Great :-) Thomas, Could you explicity add an icon as the apps icon - as when I have looked at the sources there isn't one - so it is hard for me to write code to replace it - my earlier thread - if it doesn't explicitly exist as I need to know the resource id to change it... I will try to put something together for you when I have some time...but I only have MSVC7.1 so I can't give you a project for MSVC6. -- Phil "Requirements - what are they I just hack something together that does what I think they want" ;) From virus.manager at st.com Thu Feb 5 11:17:49 2004 From: virus.manager at st.com (virus.manager@st.com) Date: Thu Feb 5 11:17:54 2004 Subject: [Distutils] Virus Alert Message-ID: <20040205161749.49FF3F370@zeta.dmz-eu.st.com> The mail message (file: file.pif) you sent to contains a virus. (on zeta) From ruby-talk-admin at ruby-lang.org Thu Feb 5 13:21:29 2004 From: ruby-talk-admin at ruby-lang.org (ruby-talk-admin@ruby-lang.org) Date: Thu Feb 5 13:21:35 2004 Subject: [Distutils] Fml status report (ruby-talk ML) References: <20040205182112.BE16B3F486@hydrogen.ruby-lang.org> Message-ID: <200402060321.FMLAAB17551.ruby-talk@ruby-lang.org> your mail is too big --ruby-talk@ruby-lang.org, Be Seeing You! ************************************************************ Help: Unsubscribe: If you have any questions or problems, please contact ruby-talk-admin@ruby-lang.org or send e-mail with the body "help"(without quotes) to ruby-talk-ctl@ruby-lang.org (here is the automatic reply, so more preferable) e.g. on a Unix Machine (shell prompt)% echo "help" |Mail ruby-talk-ctl@ruby-lang.org ************************************************************ From theller at python.net Thu Feb 5 14:52:18 2004 From: theller at python.net (Thomas Heller) Date: Thu Feb 5 14:52:42 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: (Phil Hornby's message of "Thu, 5 Feb 2004 10:44:43 -0000") References: Message-ID: "Phil Hornby" writes: > Thomas, > > Could you explicity add an icon as the apps icon - as when I have looked at > the sources there isn't one - so it is hard for me to write code to replace > it - my earlier thread - if it doesn't explicitly exist as I need to know > the resource id to change it... I would have added one if I would have found one that is really free to use legally. I have to admint that I don't care too much about the icon so I did not search very hard (if at all ;-). > I will try to put something together for you when I have some time...but I > only have MSVC7.1 so I can't give you a project for MSVC6. One problem you will face (and that is maybe an additional argument against making the icon changeable at runtime, when the distribution is built), is that the ...UpdateResource() functions from the win32 api are only available on NT/2000/XP, not Win95/98/Me. At least when Microsoft's unicows.dll is not available. And IMO unicows.dll license restrictions are not 'compatible' with the Python license to allow redistribution with Python or distutils. Thomas From mal at egenix.com Thu Feb 5 14:59:06 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 5 14:58:45 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: References: Message-ID: <4022A08A.8090006@egenix.com> Thomas Heller wrote: > "Phil Hornby" writes: > > >>Thomas, >> >>Could you explicity add an icon as the apps icon - as when I have looked at >>the sources there isn't one - so it is hard for me to write code to replace >>it - my earlier thread - if it doesn't explicitly exist as I need to know >>the resource id to change it... > > > I would have added one if I would have found one that is really free to > use legally. I have to admint that I don't care too much about the icon > so I did not search very hard (if at all ;-). You should be able to use the snake icon that we use for the Python installer (basically the same as the favicon.ico we have on python.org). I think it's even included somewhere in the distribution... right under PC/pycon.ico. >>I will try to put something together for you when I have some time...but I >>only have MSVC7.1 so I can't give you a project for MSVC6. > > One problem you will face (and that is maybe an additional argument > against making the icon changeable at runtime, when the distribution is > built), is that the ...UpdateResource() functions from the win32 api are > only available on NT/2000/XP, not Win95/98/Me. At least when > Microsoft's unicows.dll is not available. And IMO unicows.dll license > restrictions are not 'compatible' with the Python license to allow > redistribution with Python or distutils. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 05 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/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From theller at python.net Thu Feb 5 15:28:21 2004 From: theller at python.net (Thomas Heller) Date: Thu Feb 5 15:28:45 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <4022A08A.8090006@egenix.com> (M.'s message of "Thu, 05 Feb 2004 20:59:06 +0100") References: <4022A08A.8090006@egenix.com> Message-ID: <7jz19spm.fsf@python.net> "M.-A. Lemburg" writes: > Thomas Heller wrote: >> "Phil Hornby" writes: >> >>>Thomas, >>> >>>Could you explicity add an icon as the apps icon - as when I have looked at >>>the sources there isn't one - so it is hard for me to write code to replace >>>it - my earlier thread - if it doesn't explicitly exist as I need to know >>>the resource id to change it... >> I would have added one if I would have found one that is really free >> to use legally. I have to admint that I don't care too much about >> the icon so I did not search very hard (if at all ;-). > > You should be able to use the snake icon that we use for the > Python installer (basically the same as the favicon.ico we > have on python.org). I think it's even included somewhere in > the distribution... right under PC/pycon.ico. That looks the same (or very similar) to Python23\py.ico, which is associated with .py files. IMO for an installer (even if it installs Python modules) the usual computer picture with a disc or a disc box beneath it is more appropriate. If you look at the default py2exe icon you will notice that I'm very creative and good making custom icons ;-), so that's not an option. Thomas From mhammond at skippinet.com.au Thu Feb 5 15:45:14 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu Feb 5 15:46:15 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: Message-ID: <457e01c3ec28$f52e6010$0200a8c0@eden> > > I think there is a simple fix to keep most people happy. > distutils can just > > *append* the existing env var value to the new value. I think it is > > acceptable to say distutils wont let you set these to > change the location of > > standard libraries or headers, but will let you add new ones. > > So there's no need to read the entries set in MSVC7 itself (for which > you have uploaded a patch) ? :) Well, that would work I guess. I see no reason we can't support both the "GUI config" and "environment config", but if you felt it appropriate to support only the environment variables, it wouldn't really upset me. But I point out again that the way things stand at the moment, *neither* work with MSVC7.1 Mark. From theller at python.net Thu Feb 5 16:01:02 2004 From: theller at python.net (Thomas Heller) Date: Thu Feb 5 16:01:28 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: <457e01c3ec28$f52e6010$0200a8c0@eden> (Mark Hammond's message of "Fri, 6 Feb 2004 07:45:14 +1100") References: <457e01c3ec28$f52e6010$0200a8c0@eden> Message-ID: <3c9p9r75.fsf@python.net> "Mark Hammond" writes: >> > I think there is a simple fix to keep most people happy. distutils >> > can just *append* the existing env var value to the new value. I >> > think it is acceptable to say distutils wont let you set these to >> > change the location of standard libraries or headers, but will let >> > you add new ones. >> >> So there's no need to read the entries set in MSVC7 itself (for which >> you have uploaded a patch) ? > > :) Well, that would work I guess. I see no reason we can't support both > the "GUI config" and "environment config", but if you felt it appropriate to > support only the environment variables, it wouldn't really upset me. I would find it strange if a naive setup script would use different include and lib directories depending on whether win32all is installed or not. IIRC, distutils need to read the registry was the reason that the _winreg module was added to the Python core. Maybe its time to add a distutils_util compiled extension for windows specific features (do I need a smiley here or not - not sure) ? > But I point out again that the way things stand at the moment, *neither* > work with MSVC7.1 > > Mark. Thomas From theller at python.net Thu Feb 5 16:18:26 2004 From: theller at python.net (Thomas Heller) Date: Thu Feb 5 16:18:52 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <014b01c3eb7d$211c7ba0$0200a8c0@eden> (Mark Hammond's message of "Thu, 5 Feb 2004 11:15:14 +1100") References: <014b01c3eb7d$211c7ba0$0200a8c0@eden> Message-ID: "Mark Hammond" writes: > One of our politicians famously uttered "life wasn't meant to be easy" - how > right he was :) > > Let's assume I am trying to use distutils from Python 2.4 to package an > installation for both Python 2.3 and Python 2.4 (or vice-versa - trying to > use 2.3 distutils to package them both). As mentioned her previously, I > want to do this so I can use the features in later versions of distutils > (such as the post-install-script) to package extensions for earlier versions > of Python. > > The installation script uses PyRun_SimpleFile. This takes a FILE *. The > problem is that Python 2.3 and Python 2.4 use different runtime libraries. > One of them is guaranteed to crash. This violates the Python rule that > Python and its extensions must use the same CRTL. > > I see 2 choices: > * Avoid PyRun_SimpleFile, by reading the file ourself, and using > PyRun_SimpleString. This should work, but is fragile, as we are still > breaking that rule. > * Provide 2 different wininst.exe stubs, one for MSVC6 and one for MSVC7. > distutils hardcodes the knowledge of what one to use for what version. > However, the problem is that this will mean people building distutils to > ship will always need *both* VC6 and VC7 - VC6 just for that stub, and VC7 > to build everything else. > > The first option is less work, and should work today, but is still naughty. > Any thoughts? Since wininst.exe dynamically loads the Python dll (even different versions), it is already fairly limited in the Python api it can use. Avoiding the call to PyRun_SimpleFile is still an option. Isn't it fun to break the rules ;-) ? Thomas From theller at python.net Thu Feb 5 16:29:21 2004 From: theller at python.net (Thomas Heller) Date: Thu Feb 5 16:45:46 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: <46f501c3ec2d$0840be10$0200a8c0@eden> (Mark Hammond's message of "Fri, 6 Feb 2004 08:14:20 +1100") References: <46f501c3ec2d$0840be10$0200a8c0@eden> Message-ID: "Mark Hammond" writes: >> I would find it strange if a naive setup script would use different >> include and lib directories depending on whether win32all is installed >> or not. > > I agree. > >> IIRC, distutils need to read the registry was the reason that the >> _winreg module was added to the Python core. >> >> Maybe its time to add a distutils_util compiled extension for windows >> specific features (do I need a smiley here or not - not sure) ? > > I think that exposing SHGetSpecialFolderPath() would be a valuable addition > to the Python runtime, and I guess that inside distutils would be a > reasonable place for it. It is already in wininst.exe, as you probably know, but unusable from the 'outside'. Same for code to create shortcuts, do you think that would be useful as well? Thomas From mal at egenix.com Thu Feb 5 16:51:56 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 5 16:51:35 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <7jz19spm.fsf@python.net> References: <4022A08A.8090006@egenix.com> <7jz19spm.fsf@python.net> Message-ID: <4022BAFC.4090801@egenix.com> Thomas Heller wrote: >>>>Could you explicity add an icon as the apps icon - as when I have looked at >>>>the sources there isn't one - so it is hard for me to write code to replace >>>>it - my earlier thread - if it doesn't explicitly exist as I need to know >>>>the resource id to change it... > > >>>I would have added one if I would have found one that is really free >>>to use legally. I have to admint that I don't care too much about >>>the icon so I did not search very hard (if at all ;-). >> >>You should be able to use the snake icon that we use for the >>Python installer (basically the same as the favicon.ico we >>have on python.org). I think it's even included somewhere in >>the distribution... right under PC/pycon.ico. > > > That looks the same (or very similar) to Python23\py.ico, which is > associated with .py files. > > IMO for an installer (even if it installs Python modules) the usual > computer picture with a disc or a disc box beneath it is more > appropriate. > > If you look at the default py2exe icon you will notice that I'm very > creative and good making custom icons ;-), so that's not an option. You could take one of these: http://www-kp3.gsi.de/www/img/eit/eit_summary.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 05 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/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mhammond at skippinet.com.au Thu Feb 5 17:23:11 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu Feb 5 17:23:41 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: Message-ID: <4a5301c3ec36$abb7bb80$0200a8c0@eden> > Since wininst.exe dynamically loads the Python dll (even different > versions), it is already fairly limited in the Python api it can use. > Avoiding the call to PyRun_SimpleFile is still an option. > > Isn't it fun to break the rules ;-) ? I did find a couple of other issues with breaking these rules: * PyRun_SimpleFile does not allow you to specify the "filename", so tracebacks indicate "". To get a filename means using additional "compile" functions too. * redirection of stdout/stderr don't work. wininst.exe sets *its* stdout/stderr OK, but Python itself is using a *different* stdout/stderr, so the reopen has no effect. Multiple exes may turn out to be less hassle in the long run (except for the person who needs to build wininst_vc6.exe and wininst_vc7.exe) And re the other thread about MSVC7 directories: I will update the patch to falling back to the registry to try and locate this directory - this seems like a reasonable approach, and should work in almost all cases. Mark. From mhammond at skippinet.com.au Thu Feb 5 16:14:20 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu Feb 5 17:27:17 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: <3c9p9r75.fsf@python.net> Message-ID: <46f501c3ec2d$0840be10$0200a8c0@eden> > I would find it strange if a naive setup script would use different > include and lib directories depending on whether win32all is installed > or not. I agree. > IIRC, distutils need to read the registry was the reason that the > _winreg module was added to the Python core. > > Maybe its time to add a distutils_util compiled extension for windows > specific features (do I need a smiley here or not - not sure) ? I think that exposing SHGetSpecialFolderPath() would be a valuable addition to the Python runtime, and I guess that inside distutils would be a reasonable place for it. Mark. From mhammond at skippinet.com.au Thu Feb 5 18:16:58 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu Feb 5 18:17:14 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: Message-ID: <4cbc01c3ec3e$27e06250$0200a8c0@eden> > It is already in wininst.exe, as you probably know, but unusable from > the 'outside'. Same for code to create shortcuts, do you think that > would be useful as well? I think there would be a case for moving *all* "module functions into a single distutils extension module - this would simplify the installation executable, and also open possibilities for other similar utilities. Mark. From garth at utmail.to Fri Feb 6 03:24:15 2004 From: garth at utmail.to (G D) Date: Fri Feb 6 03:24:18 2004 Subject: [Distutils] Problem compiling Extensions on Win32 Message-ID: <200402060824.i168OFit027197@rs4.luxsci.com> On February 4, 2004, Thomas Heller wrote: > We just had this issue - distutils doesn't pick up the usual environment > variables. It only reads from the registry. Look into the sources for > distutils/msvccompiler.py. On my machine, the directories are in the > registry as values of the key > > HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Build System\Components\Platforms\Win32 (x86)\Directories > > Is this key present on your machine, and has it 'Include Dirs', 'Library > Dirs', and 'Path Dirs' values? You were correct, having installed VC6 only to compile this module from the commandline I hadn't even opened up the VisualStudio... It appears the only thing in the registry is "HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Build System\Components\Platforms\Win32 (x86)\Tools" before you open VisualStudio. Once open the registry fills with everything accept Directories which appear in the registry on closing VisualStudio. Adding my Includes in VisualStudio, I was able to get through the first couple of modules without problem, it died later on when the copiler was passed a -Wall parameter (a bug perhaps?): C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -IC:\!OSS\Zope-2.7.0-rc2\bin\include -IC:\!OSS\Zope-2.7.0-rc2\bin\P C /Tcsrc/python-Levenshtein-0.7/Levenshtein.c /Fobuild\temp.win32-2.3\Release\sr c/python-Levenshtein-0.7/Levenshtein.obj -Wall Command line error D2021 : invalid numeric argument '/Wall' error: command '"C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe"' fail ed with exit status 2 I manually executed that compiler command line without the -Wall and the module built and then I was able to complete the compiling by reissuing 'python setup.py build' Thanks again for your help -Garth Northern.CA ===-- http://www.northern.ca Canada's Search Engine From theller at python.net Fri Feb 6 05:58:07 2004 From: theller at python.net (Thomas Heller) Date: Fri Feb 6 05:58:33 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <4a5301c3ec36$abb7bb80$0200a8c0@eden> (Mark Hammond's message of "Fri, 6 Feb 2004 09:23:11 +1100") References: <4a5301c3ec36$abb7bb80$0200a8c0@eden> Message-ID: "Mark Hammond" writes: >> Since wininst.exe dynamically loads the Python dll (even different >> versions), it is already fairly limited in the Python api it can use. >> Avoiding the call to PyRun_SimpleFile is still an option. >> >> Isn't it fun to break the rules ;-) ? > > I did find a couple of other issues with breaking these rules: > * PyRun_SimpleFile does not allow you to specify the "filename", so > tracebacks indicate "". To get a filename means using additional > "compile" functions too. > > * redirection of stdout/stderr don't work. wininst.exe sets *its* > stdout/stderr OK, but Python itself is using a *different* stdout/stderr, so > the reopen has no effect. > > Multiple exes may turn out to be less hassle in the long run (except for the > person who needs to build wininst_vc6.exe and wininst_vc7.exe) Ok, doesn't sound like too much fun anymore. I'll take the multi exe approach. > And re the other thread about MSVC7 directories: I will update the patch to > falling back to the registry to try and locate this directory - this seems > like a reasonable approach, and should work in almost all cases. Tim Peters reported that MSVC7 cannot be installed on win98, so this limits the variations that have to be supported. Thomasa From theller at python.net Fri Feb 6 06:00:11 2004 From: theller at python.net (Thomas Heller) Date: Fri Feb 6 06:00:41 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: <4cbc01c3ec3e$27e06250$0200a8c0@eden> (Mark Hammond's message of "Fri, 6 Feb 2004 10:16:58 +1100") References: <4cbc01c3ec3e$27e06250$0200a8c0@eden> Message-ID: <8yjg8ock.fsf@python.net> "Mark Hammond" writes: >> It is already in wininst.exe, as you probably know, but unusable from >> the 'outside'. Same for code to create shortcuts, do you think that >> would be useful as well? > > I think there would be a case for moving *all* "module functions into a > single distutils extension module - this would simplify the installation > executable, and also open possibilities for other similar utilities. This could be a part of a new distutils package, required to build the installers. But the installers, at run-time, cannot depend on it. Thomas From theller at python.net Fri Feb 6 06:05:10 2004 From: theller at python.net (Thomas Heller) Date: Fri Feb 6 06:06:01 2004 Subject: [Distutils] Problem compiling Extensions on Win32 In-Reply-To: <200402060824.i168OFit027197@rs4.luxsci.com> (G. D.'s message of "Fri, 06 Feb 2004 08:24:15 +0000") References: <200402060824.i168OFit027197@rs4.luxsci.com> Message-ID: <4qu48o49.fsf@python.net> "G D" writes: > On February 4, 2004, Thomas Heller wrote: > >> We just had this issue - distutils doesn't pick up the usual environment >> variables. It only reads from the registry. Look into the sources for >> distutils/msvccompiler.py. On my machine, the directories are in the >> registry as values of the key >> >> HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Build System\Components\Platforms\Win32 (x86)\Directories >> >> Is this key present on your machine, and has it 'Include Dirs', 'Library >> Dirs', and 'Path Dirs' values? > > You were correct, having installed VC6 only to compile this module > from the commandline I hadn't even opened up the VisualStudio... It > appears the only thing in the registry is > "HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Build > System\Components\Platforms\Win32 (x86)\Tools" before you open > VisualStudio. Once open the registry fills with everything accept > Directories which appear in the registry on closing VisualStudio. Python 2.3.3 (but not 2.3.2 or earlier) should have displayed a warning when it finds these incomplete registry entries: self.warn("It seems you have Visual Studio 6 installed, " "but the expected registry settings are not present.\n" "You must at least run the Visual Studio GUI once " "so that these entries are created.") > Adding my Includes in VisualStudio, I was able to get through the > first couple of modules without problem, it died later on when the > copiler was passed a -Wall parameter (a bug perhaps?): distutils doesn't pass -Wall to the MSVC compiler. A bug in the setup script? Thomas From vse at srasys.co.in Fri Feb 6 07:50:34 2004 From: vse at srasys.co.in (V.Selvam) Date: Fri Feb 6 07:49:49 2004 Subject: [Distutils] need help on distrbuting in the user's path Message-ID: <002101c3ecaf$d01dc630$0fa8a8c0@selvam> Hi all, I am new for the python - distutils. I am creating distribution for the windows platform. I want to get user's path option and put all my python file(modules and packages) in to the same path at the installation run time. Can any one help me in that?? Thanks in advance Regards V.Selvam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040206/8b80fe0c/attachment.html From andreas at schuldei.org Fri Feb 6 09:13:31 2004 From: andreas at schuldei.org (Andreas Schuldei) Date: Fri Feb 6 09:13:41 2004 Subject: [Distutils] installing scripts to /usr/sbin? Message-ID: <20040206141328.GG24531@lukas.schuldei.com> how can i install python progs to /usr/sbin? i manage to install them to /usr/bin just fine using scripts=['client/bofh.py',... in my setup.py. I would wish for a setup option sbin_scripts... if this is a mailinglist, i am not subscribed. please cc me. From pearu at cens.ioc.ee Fri Feb 6 12:43:43 2004 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Fri Feb 6 12:43:49 2004 Subject: [Distutils] installing scripts to /usr/sbin? In-Reply-To: <20040206141328.GG24531@lukas.schuldei.com> Message-ID: On Fri, 6 Feb 2004, Andreas Schuldei wrote: > how can i install python progs to /usr/sbin? i manage to install > them to /usr/bin just fine using > scripts=['client/bofh.py',... > in my setup.py. > I would wish for a setup option sbin_scripts... Have you tried using scripts = ['/usr/sbin/client/bofh.py... ? Pearu From theller at python.net Fri Feb 6 15:08:59 2004 From: theller at python.net (Thomas Heller) Date: Fri Feb 6 15:09:26 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <4022BAFC.4090801@egenix.com> (M.'s message of "Thu, 05 Feb 2004 22:51:56 +0100") References: <4022A08A.8090006@egenix.com> <7jz19spm.fsf@python.net> <4022BAFC.4090801@egenix.com> Message-ID: "M.-A. Lemburg" writes: [about icons for bdist_wininst installers] > You could take one of these: > > http://www-kp3.gsi.de/www/img/eit/eit_summary.html > Na, I don't really like them. Thomas From mhammond at skippinet.com.au Fri Feb 6 18:29:09 2004 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri Feb 6 18:29:24 2004 Subject: [Distutils] MSVC7 directories In-Reply-To: <8yjg8ock.fsf@python.net> Message-ID: <072a01c3ed09$05a2f4c0$0200a8c0@eden> > > I think there would be a case for moving *all* "module > > functions into a single distutils extension module - this would > > simplify the installation > > executable, and also open possibilities for other similar utilities. > > This could be a part of a new distutils package, required to build the > installers. But the installers, at run-time, cannot depend on it. Doh! Maybe the same module sourcecode could be built both as a stand-alone module, and also statically included in the installation exe. That way we can almost still keep it fun :) Mark. From hanlon at galesburg.net Fri Feb 6 01:26:36 2004 From: hanlon at galesburg.net (Hanlon) Date: Sat Feb 7 00:16:53 2004 Subject: [Distutils] 15 mens and 72 womans die from AIW. In-Reply-To: References: Message-ID: <7GL8F57FIDCA76D6@galesburg.net> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040206/6deb43dc/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: fish.gif Type: image/gif Size: 5077 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040206/6deb43dc/fish.gif From sandeepd at persistent.co.in Sun Feb 8 08:58:52 2004 From: sandeepd at persistent.co.in (sandeepd@persistent.co.in) Date: Sun Feb 8 08:58:46 2004 Subject: [Distutils] Blocked delivery of your email to faculty@persistent.co.in Message-ID: <200402081358.i18Dwrhf005055@smtp.pspl.co.in> BLOCKED DELIVERY OF YOUR EMAIL TO faculty@persistent.co.in Your email has been stopped for reasons stated at the bottom of this mail. If your message is HTML/RichText and wrongly reported as SPAM below send the email again in plain-text format. If your message is reported to have virus, please check your system for virii and clean it up. If you still think that your message is free of all the above, please report it to postmaster@persistent.co.in or sysads@persistent.co.in. Email was blocked due to the presence of a virus Comment: Virus detected in the mail /unpacked/document.zip - Win32/Mydoom.A worm /unpacked/document.pif - Win32/Mydoom.A worm End. From 7rgcbmxahy at eri.u-tokyo.ac.jp Sun Feb 8 16:03:24 2004 From: 7rgcbmxahy at eri.u-tokyo.ac.jp (Marian Moore) Date: Sun Feb 8 15:03:42 2004 Subject: [Distutils] This is a VERY different affiliate program Message-ID: <28n-$tbjr7h-h-1$-k1ub83b@unay0153> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040208/db7b4edd/attachment.html From sandeepd at persistent.co.in Sun Feb 8 16:53:46 2004 From: sandeepd at persistent.co.in (sandeepd@persistent.co.in) Date: Sun Feb 8 16:53:54 2004 Subject: [Distutils] Blocked delivery of your email to ashish_gupta@persistent.co.in Message-ID: <200402082153.i18Lrl7R005723@smtp.pspl.co.in> BLOCKED DELIVERY OF YOUR EMAIL TO ashish_gupta@persistent.co.in Your email has been stopped for reasons stated at the bottom of this mail. If your message is HTML/RichText and wrongly reported as SPAM below send the email again in plain-text format. If your message is reported to have virus, please check your system for virii and clean it up. If you still think that your message is free of all the above, please report it to postmaster@persistent.co.in or sysads@persistent.co.in. Email was blocked due to the presence of a virus Comment: Virus detected in the mail /unpacked/udlauv.pif - Win32/Mydoom.A worm End. From postmaster at it.net.au Mon Feb 9 07:34:23 2004 From: postmaster at it.net.au (MIMEDefang) Date: Mon Feb 9 07:41:31 2004 Subject: [Distutils] MIMEDefang Notification Message-ID: <200402092034.i19CYBKV014080@talen.it.net.au> An e-mail you sent with message-id was modified by our mail scanning software. The recipients were: Here are the details of the modification: F-Secure Anti-Virus for Linux version 4.50 build 2111 Copyright (c) 1999-2003 F-Secure Corporation. All Rights Reserved. ./Work/msg-18545-13.pif: Infected: W32/Mydoom.A@mm [F-Prot] ./Work/msg-18545-13.pif: Infected: I-Worm.Mydoom.a [AVP] 2 files scanned 1 file infected F-Secure Anti-Virus for Linux version 4.50 build 2111 Copyright (c) 1999-2003 F-Secure Corporation. All Rights Reserved. ./Work/msg-18545-13.pif: Infected: W32/Mydoom.A@mm [F-Prot] ./Work/msg-18545-13.pif: Infected: I-Worm.Mydoom.a [AVP] 2 files scanned 1 file infected From phil.hornby at accutest.co.uk Mon Feb 9 10:44:41 2004 From: phil.hornby at accutest.co.uk (Phil Hornby) Date: Mon Feb 9 10:49:10 2004 Subject: [Distutils] How about this for an Icon?? Message-ID: Okay...I have tried to be creative and create an icon for use on a default wininst.exe.... What do you think?? -- Phil "Requirements - what are they I just hack something together that does what I think they want" ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: pydist.ico Type: image/x-icon Size: 766 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040209/da7b9411/pydist.bin From mal at egenix.com Mon Feb 9 11:00:50 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 9 11:00:49 2004 Subject: [Distutils] How about this for an Icon?? In-Reply-To: References: Message-ID: <4027AEB2.9070703@egenix.com> Phil Hornby wrote: > Okay...I have tried to be creative and create an icon for use on a default > wininst.exe.... > > What do you think?? Very nice :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 09 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/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From theller at python.net Mon Feb 9 11:39:51 2004 From: theller at python.net (Thomas Heller) Date: Mon Feb 9 11:40:12 2004 Subject: [Distutils] How about this for an Icon?? In-Reply-To: (Phil Hornby's message of "Mon, 9 Feb 2004 15:44:41 -0000") References: Message-ID: "Phil Hornby" writes: > Okay...I have tried to be creative and create an icon for use on a default > wininst.exe.... > > What do you think?? Very cool. Nitpicking: The end of the Python's tail, just right beneath the disk drive, looks a little bit like a checkmark instead of the tail, but that might be only for me. Thomas From phil.hornby at accutest.co.uk Mon Feb 9 11:56:59 2004 From: phil.hornby at accutest.co.uk (Phil Hornby) Date: Mon Feb 9 12:01:29 2004 Subject: [Distutils] Picky Picky... Message-ID: Thomas, Okay I have tried to modify the tail a little... I hope that it is now a little less tick-like... My other idea was a Python-in-a-box...but I prefered this... -- Phil "Requirements - what are they I just hack something together that does what I think they want" ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: pydist.ico Type: image/x-icon Size: 766 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040209/4a8cbc02/pydist.bin From mdehoon at ims.u-tokyo.ac.jp Mon Feb 9 23:50:58 2004 From: mdehoon at ims.u-tokyo.ac.jp (Michiel Jan Laurens de Hoon) Date: Mon Feb 9 23:52:01 2004 Subject: [Distutils] Problem compiling Extensions on Win32 In-Reply-To: <4021F6AC.103B5B54@gmx.de> References: <200402041727.i14HR58x028762@rs4.luxsci.com> <40219C8F.3060700@ims.u-tokyo.ac.jp> <4021F6AC.103B5B54@gmx.de> Message-ID: <40286332.9070002@ims.u-tokyo.ac.jp> >>>python setup.py build -cmingw32 >>> >>>I get a hole bunch of undefined interface type errors (the computer's at home >>>so I'm going by memory) similar to __Inf__PyString undefined, and it ends off >>>with a line about WinMain@16 with that setup terminates. >> > This is [..] what you can find in the documentation > http://python.org/doc/current/inst/tweak-flags.html#SECTION000622000000000000000 > > But nobody seems to read it. Maybe the compiler class should check for > libpython??.a and print a warning with a link > to the documentation. > Another possibility would be to include the appropriate libpython??.a with the Windows version of Python, in order to make developing C extensions easier for open-source developers that are using gcc instead of Microsoft's compiler. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon From tcm-users-request at cs.utwente.nl Tue Feb 10 01:42:24 2004 From: tcm-users-request at cs.utwente.nl (tcm-users-request@cs.utwente.nl) Date: Tue Feb 10 01:42:29 2004 Subject: [Distutils] Your mail to tcm-users-request@listserv.cs.utwente.nl In-Reply-To: <200402100641.i1A6fv223708@netlx010.civ.utwente.nl>, from distutils-sig@python.org Message-ID: <200402100642.i1A6gOht009805@utrhcs.cs.utwente.nl> This pre-recorded message is being sent in response to your recent email to tcm-users-request@listserv.cs.utwente.nl. All routine administrative requests (including subscriptions and unsubscriptions) concerning this mailing list are handled by an automated server. Please read this message carefully to find the information relevant to you. SUBSCRIBING =========== To subscribe to tcm-users, send the following in the body (not the subject line) of an email message to "Majordomo@listserv.cs.utwente.nl": subscribe tcm-users This will subscribe the account from which you send the message to the tcm-users list. If you wish to subscribe another address instead (such as a local redistribution list), you can use a command of the form: subscribe tcm-users other-address@your_site.your_net UNSUBSCRIBING ============= To unsubscribe from tcm-users, send the following in the body (not the subject line) of an email message to "Majordomo@listserv.cs.utwente.nl": unsubscribe tcm-users This will unsubscribe the account from which you send the message. If you are subscribed with some other address, you'll have to send a command of the following form instead: unsubscribe tcm-users other-address@your_site.your_net If you don't know what address you are subscribed with, you can send the following command to see who else is on the list (assuming that information isn't designated "private" by the owner of the list): who tcm-users If you want to search non-private lists at this server, you can do that by sending a command like: which string This will return a list of all entries on all lists that contain "string". HELP ==== To find out more about the automated server and the commands it understands, send the following command to "Majordomo@listserv.cs.utwente.nl": help If you feel you need to reach a human, send email to: tcm-users-approval@listserv.cs.utwente.nl From piet at cs.uu.nl Tue Feb 10 11:41:28 2004 From: piet at cs.uu.nl (piet@cs.uu.nl) Date: Tue Feb 10 12:01:31 2004 Subject: [Distutils] test Message-ID: The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment. -------------- next part -------------- A non-text attachment was scrubbed... Name: body.pif Type: application/octet-stream Size: 22528 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040211/0c5134c0/body-0001.obj From Kuser-admin at kde.gr.jp Wed Feb 11 05:04:20 2004 From: Kuser-admin at kde.gr.jp (Kuser-admin@kde.gr.jp) Date: Wed Feb 11 05:04:28 2004 Subject: [Distutils] You distutils-sig@python.org are not member (Kuser ML) References: <20040211100415.081AC1F83DC@mail.kde.gr.jp> Message-ID: <200402111904.FMLAAB26512.Kuser@kde.gr.jp> ?????????????? ????????????? ??????????????????????????? guide ???????? Kuser-ctl@kde.gr.jp ????????????? From postmaster at snv.jussieu.fr Wed Feb 11 11:34:37 2004 From: postmaster at snv.jussieu.fr (postmaster@snv.jussieu.fr) Date: Wed Feb 11 11:35:46 2004 Subject: [Distutils] ALERTE - Vous avez envoye un mail avec virus Message-ID: <200402111634.i1BGYbVC014098@drum.snv.jussieu.fr> A L E R T E - V I R U S Notre solution anti-virus de messagerie a notamment detecte : W32/MyDoom-A virus dans votre message envoye au(x) destinataire(s) suivant(s) : -> Nous vous conseillons d'installer ou de mettre a jour votre logiciel anti-virus. Informations et explication du fonctionnement de notre filtrage : http://antivirus.snv.jussieu.fr Pour information, voici les en-tetes de votre message : ------------------------- BEGIN HEADERS ----------------------------- From: distutils-sig@python.org To: tomgeri@newmail.net Subject: Mail Transaction Failed Date: Wed, 11 Feb 2004 17:35:32 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_17E2EB62.E7905303" X-Priority: 3 X-MSMail-Priority: Normal -------------------------- END HEADERS ------------------------------ From mats at laplaza.org Mon Feb 9 17:04:52 2004 From: mats at laplaza.org (Mats Wichmann) Date: Fri Feb 13 01:19:31 2004 Subject: [Distutils] installing scripts to /usr/sbin? In-Reply-To: <20040206141328.GG24531@lukas.schuldei.com> Message-ID: <5.1.0.14.1.20040209150203.0263fe68@mail.laplaza.org> At 03:13 PM 2/6/2004 +0100, Andreas Schuldei wrote: >how can i install python progs to /usr/sbin? i manage to install >them to /usr/bin just fine using > scripts=['client/bofh.py',... >in my setup.py. >I would wish for a setup option sbin_scripts... A piece of unsolicited advice: don't. /usr/bin, /usr/sbin and their ilk should be left to the operating system vendor. /opt or /usr/local can be used for add-on software, depending on how pedantic you want to be about following the guidelines of whatever operating system you're using. From andreas at schuldei.org Fri Feb 13 05:33:47 2004 From: andreas at schuldei.org (Andreas Schuldei) Date: Fri Feb 13 05:34:00 2004 Subject: [Distutils] installing scripts to /usr/sbin? In-Reply-To: <5.1.0.14.1.20040209150203.0263fe68@mail.laplaza.org> References: <20040206141328.GG24531@lukas.schuldei.com> <5.1.0.14.1.20040209150203.0263fe68@mail.laplaza.org> Message-ID: <20040213103345.GD6435@lukas.schuldei.com> * Mats Wichmann (mats@laplaza.org) [040213 07:19]: > At 03:13 PM 2/6/2004 +0100, Andreas Schuldei wrote: > >how can i install python progs to /usr/sbin? i manage to install > >them to /usr/bin just fine using > > scripts=['client/bofh.py',... > >in my setup.py. > >I would wish for a setup option sbin_scripts... > > A piece of unsolicited advice: don't. > /usr/bin, /usr/sbin and their ilk should > be left to the operating system vendor. > > /opt or /usr/local can be used for add-on > software, depending on how pedantic you > want to be about following the guidelines > of whatever operating system you're using. as a debian developer (who is unfortunatly a python novice) i am the operating system vendor. (c: From Alexandre.Fayolle at logilab.fr Fri Feb 13 05:36:28 2004 From: Alexandre.Fayolle at logilab.fr (Alexandre) Date: Fri Feb 13 05:36:46 2004 Subject: [Distutils] installing scripts to /usr/sbin? In-Reply-To: <20040213103345.GD6435@lukas.schuldei.com> References: <20040206141328.GG24531@lukas.schuldei.com> <5.1.0.14.1.20040209150203.0263fe68@mail.laplaza.org> <20040213103345.GD6435@lukas.schuldei.com> Message-ID: <20040213103628.GC31381@crater.logilab.fr> On Fri, Feb 13, 2004 at 11:33:47AM +0100, Andreas Schuldei wrote: > * Mats Wichmann (mats@laplaza.org) [040213 07:19]: > > At 03:13 PM 2/6/2004 +0100, Andreas Schuldei wrote: > > >how can i install python progs to /usr/sbin? i manage to install > > >them to /usr/bin just fine using > > > scripts=['client/bofh.py',... > > >in my setup.py. > > >I would wish for a setup option sbin_scripts... > > > > A piece of unsolicited advice: don't. > > /usr/bin, /usr/sbin and their ilk should > > be left to the operating system vendor. > > > > /opt or /usr/local can be used for add-on > > software, depending on how pedantic you > > want to be about following the guidelines > > of whatever operating system you're using. > > as a debian developer (who is unfortunatly a python novice) i am > the operating system vendor. (c: If you're making a Debian package, then why don't you move the scripts in debian/rules ? This sounds like the simplest thing to do. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Advanced computing - Python - Customized trainings - Consulting - XML Informatique avanc?e - Python - Formations sur-mesure - Conseil - XML -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040213/0f8b44fc/attachment.bin From slash at dotnetslash.net Fri Feb 13 08:13:51 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Fri Feb 13 08:13:59 2004 Subject: [Distutils] installing scripts to /usr/sbin? In-Reply-To: <20040213103628.GC31381@crater.logilab.fr> References: <20040206141328.GG24531@lukas.schuldei.com> <5.1.0.14.1.20040209150203.0263fe68@mail.laplaza.org> <20040213103345.GD6435@lukas.schuldei.com> <20040213103628.GC31381@crater.logilab.fr> Message-ID: <20040213131351.GA4880@dotnetslash.net> On Fri, Feb 13, 2004 at 11:36:28AM +0100, Alexandre wrote: > On Fri, Feb 13, 2004 at 11:33:47AM +0100, Andreas Schuldei wrote: > > > A piece of unsolicited advice: don't. > > > /usr/bin, /usr/sbin and their ilk should > > > be left to the operating system vendor. > > > > > > /opt or /usr/local can be used for add-on > > > software, depending on how pedantic you > > > want to be about following the guidelines > > > of whatever operating system you're using. > > > > as a debian developer (who is unfortunatly a python novice) i am > > the operating system vendor. (c: > > If you're making a Debian package, then why don't you move the scripts > in debian/rules ? This sounds like the simplest thing to do. Because Distutils should be able to do Debian packages natively? -- Mark W. Alexander slash@dotnetslash.net From Alexandre.Fayolle at logilab.fr Fri Feb 13 09:35:29 2004 From: Alexandre.Fayolle at logilab.fr (Alexandre) Date: Fri Feb 13 09:35:49 2004 Subject: [Distutils] installing scripts to /usr/sbin? In-Reply-To: <20040213131351.GA4880@dotnetslash.net> References: <20040206141328.GG24531@lukas.schuldei.com> <5.1.0.14.1.20040209150203.0263fe68@mail.laplaza.org> <20040213103345.GD6435@lukas.schuldei.com> <20040213103628.GC31381@crater.logilab.fr> <20040213131351.GA4880@dotnetslash.net> Message-ID: <20040213143529.GE31381@crater.logilab.fr> On Fri, Feb 13, 2004 at 08:13:51AM -0500, Mark W. Alexander wrote: > On Fri, Feb 13, 2004 at 11:36:28AM +0100, Alexandre wrote: > > If you're making a Debian package, then why don't you move the scripts > > in debian/rules ? This sounds like the simplest thing to do. > > Because Distutils should be able to do Debian packages natively? I'm not sure that this is assertion is true. And even if it were, the fact is that Distutils is not able to do so. If you need help in building a Debian package, or a python tool please ask. I'll be happy to help. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Advanced computing - Python - Customized trainings - Consulting - XML -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040213/fc65a2a9/attachment.bin From mats at laplaza.org Fri Feb 13 11:15:16 2004 From: mats at laplaza.org (Mats Wichmann) Date: Fri Feb 13 11:33:28 2004 Subject: [Distutils] installing scripts to /usr/sbin? In-Reply-To: <20040213143529.GE31381@crater.logilab.fr> References: <20040213131351.GA4880@dotnetslash.net> <20040206141328.GG24531@lukas.schuldei.com> <5.1.0.14.1.20040209150203.0263fe68@mail.laplaza.org> <20040213103345.GD6435@lukas.schuldei.com> <20040213103628.GC31381@crater.logilab.fr> <20040213131351.GA4880@dotnetslash.net> Message-ID: <5.1.0.14.1.20040213091001.00aa3f38@mail.laplaza.org> >> Because Distutils should be able to do Debian packages natively? > >I'm not sure that this is assertion is true. And even if it were, the >fact is that Distutils is not able to do so. > >If you need help in building a Debian package, or a python tool please ask. >I'll be happy to help. I do, although it's offtopic for distutils (sorry). I'd like to develop a patch which enables the python-rpm extension to the Debiant rpm package, so I can forward it to the rpm maintainer. I have complex reasons for needing this (well not that complex; a Debian system happens to be the host for a set of rpm packages for which I want to enable fetching via yum. yum-arch requires the python rpm extension.) He's had a number of requests for this, but doesn't know python. Meanwhile, I don't know the debian packaging system, and my pass at it didn't work out right at all. Any takers? Mats From jjgodftredsen at 12move.dk Mon Feb 16 04:13:36 2004 From: jjgodftredsen at 12move.dk (Jjgodftredsen) Date: Mon Feb 16 10:13:42 2004 Subject: [Distutils] 50! Novarg.b fast remover. In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040216/aedbe7ab/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: fish.gif Type: image/gif Size: 5077 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040216/aedbe7ab/fish.gif From Mike.Olson at fourthought.com Mon Feb 16 15:50:12 2004 From: Mike.Olson at fourthought.com (Michael Olson) Date: Mon Feb 16 15:50:16 2004 Subject: [Distutils] Error in build_clib Message-ID: The version of distutils that comes with python 2.3 has a bug in the build_clib command. Both of the command line options --build-clib and --build-temp need to be defined with a "=" after them to allow the user to specify the directory that should be used. Mike ------------------------------------------------------------------------ ----------------- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 Fourthought, Inc. http://Fourthought.com PO Box 270590, http://4Suite.org Louisville, CO 80027-5009, USA XML strategy, XML tools, knowledge management From 038lnt at mpe-garching.mpg.de Tue Feb 17 04:30:23 2004 From: 038lnt at mpe-garching.mpg.de (Patrick Tucker) Date: Tue Feb 17 09:32:30 2004 Subject: [Distutils] Google affiliate program is the best there is Message-ID: <48915$ab$92538w$950mr@383.za> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040217/3d5c2c60/attachment-0001.html From suzette_kimball at usgs.gov Wed Feb 18 11:07:15 2004 From: suzette_kimball at usgs.gov (suzette_kimball@usgs.gov) Date: Wed Feb 18 11:07:19 2004 Subject: [Distutils] information Message-ID: something is going wrong -------------- next part -------------- A non-text attachment was scrubbed... Name: shower.zip Type: application/x-zip-compressed Size: 0 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040218/7cbdc2e0/shower.bin From robert at softincubator.com Thu Feb 19 05:50:27 2004 From: robert at softincubator.com (robert@softincubator.com) Date: Thu Feb 19 05:50:29 2004 Subject: [Distutils] Re: zvzmtwpkplmslevcj In-Reply-To: <200402191050.i1JAoDId015958@host15.apollohosting.com> References: <200402191050.i1JAoDId015958@host15.apollohosting.com> Message-ID: <200402191050.i1JAoRIv016081@host15.apollohosting.com> This is an autoresponder. I'll never see your message. From theller at python.net Fri Feb 20 09:56:06 2004 From: theller at python.net (Thomas Heller) Date: Fri Feb 20 09:56:07 2004 Subject: [Distutils] Picky Picky... In-Reply-To: (Phil Hornby's message of "Mon, 9 Feb 2004 16:56:59 -0000") References: Message-ID: "Phil Hornby" writes: > Thomas, > > Okay I have tried to modify the tail a little... I hope that it is now a > little less tick-like... Yes, it is better imo. Question to the distutils developers: Should this be used as the default icon for installers created by bdist_wininst? Or has this to wait until there's a way to change the icon when building the installer? Thomas From theller at python.net Fri Feb 20 10:13:07 2004 From: theller at python.net (Thomas Heller) Date: Fri Feb 20 10:13:07 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <4022140E.6030809@egenix.com> (M.'s message of "Thu, 05 Feb 2004 10:59:42 +0100") References: <16E1010E4581B049ABC51D4975CEDB8803060DE0@UKDCX001.uk.int.atosorigin.com> <4022140E.6030809@egenix.com> Message-ID: "M.-A. Lemburg" writes: > That said, I think that including two wininst versions, one > compiled with VC6, the other with VC7, would solve this problem > nicely. You'd still have to have VC6/7 for compiling C extensions, > but at least generating pure Python distutils wininst packages > would remain possible. I'm currently working on this. distutils.msvccompiler.get_build_version() returns the MSVC version number as float, so I would suggest we name the wininst.exe according to this schema "wininst-%s.exe" % msvccompiler.get_build_version() wininst-6.0.exe and wininst-7.1.exe binaries would be provided with python (and distutils, if this is distributed separately again). Thomas From mal at egenix.com Fri Feb 20 10:31:45 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 20 10:31:47 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: References: <16E1010E4581B049ABC51D4975CEDB8803060DE0@UKDCX001.uk.int.atosorigin.com> <4022140E.6030809@egenix.com> Message-ID: <40362861.3010902@egenix.com> Thomas Heller wrote: > "M.-A. Lemburg" writes: > > >>That said, I think that including two wininst versions, one >>compiled with VC6, the other with VC7, would solve this problem >>nicely. You'd still have to have VC6/7 for compiling C extensions, >>but at least generating pure Python distutils wininst packages >>would remain possible. > > > I'm currently working on this. > > distutils.msvccompiler.get_build_version() returns the MSVC version > number as float, so I would suggest we name the wininst.exe according to > this schema > "wininst-%s.exe" % msvccompiler.get_build_version() > > wininst-6.0.exe and wininst-7.1.exe binaries would be provided with > python (and distutils, if this is distributed separately again). Sounds right to me. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 20 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/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From phil.hornby at accutest.co.uk Fri Feb 20 10:46:47 2004 From: phil.hornby at accutest.co.uk (Phil Hornby) Date: Fri Feb 20 10:46:53 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: Message-ID: > I'm currently working on this. > > distutils.msvccompiler.get_build_version() returns the MSVC version > number as float, so I would suggest we name the wininst.exe according to > this schema > "wininst-%s.exe" % msvccompiler.get_build_version() > > wininst-6.0.exe and wininst-7.1.exe binaries would be provided with > python (and distutils, if this is distributed separately again). > > Thomas Sounds like a plan to me... Phil From theller at python.net Fri Feb 20 12:59:25 2004 From: theller at python.net (Thomas Heller) Date: Fri Feb 20 12:59:27 2004 Subject: [Distutils] MSVC CRT woes In-Reply-To: <40362861.3010902@egenix.com> (M.'s message of "Fri, 20 Feb 2004 16:31:45 +0100") References: <16E1010E4581B049ABC51D4975CEDB8803060DE0@UKDCX001.uk.int.atosorigin.com> <4022140E.6030809@egenix.com> <40362861.3010902@egenix.com> Message-ID: "M.-A. Lemburg" writes: > Thomas Heller wrote: >> "M.-A. Lemburg" writes: >> >>>That said, I think that including two wininst versions, one >>>compiled with VC6, the other with VC7, would solve this problem >>>nicely. You'd still have to have VC6/7 for compiling C extensions, >>>but at least generating pure Python distutils wininst packages >>>would remain possible. >> I'm currently working on this. >> distutils.msvccompiler.get_build_version() returns the MSVC version >> number as float, so I would suggest we name the wininst.exe according to >> this schema >> "wininst-%s.exe" % msvccompiler.get_build_version() >> wininst-6.0.exe and wininst-7.1.exe binaries would be provided with >> python (and distutils, if this is distributed separately again). > > Sounds right to me. Just for the record: get_build_version() returns the integer '6' for VC6, and the float '7.1' for VC7.1, so the filenames will be 'wininst-6.exe' and 'wininst-7.1.exe'. Thomas From paul at prescod.net Sat Feb 21 22:10:51 2004 From: paul at prescod.net (Paul Prescod) Date: Sat Feb 21 22:14:06 2004 Subject: [Distutils] data_files and sdist Message-ID: <40381DBB.3060908@prescod.net> Is there a deep reason that the sdist command does not include data_file files by default? Paul Prescod From mal at egenix.com Sun Feb 22 05:32:37 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 22 05:32:40 2004 Subject: [Distutils] data_files and sdist In-Reply-To: <40381DBB.3060908@prescod.net> References: <40381DBB.3060908@prescod.net> Message-ID: <40388545.90902@egenix.com> Paul Prescod wrote: > Is there a deep reason that the sdist command does not include data_file > files by default? AFAIK, the files which are included by sdist are defined by the MANIFEST -- seems reasonable to me. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 22 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 paul at prescod.net Sun Feb 22 11:53:01 2004 From: paul at prescod.net (Paul Prescod) Date: Sun Feb 22 11:54:18 2004 Subject: [Distutils] data_files and sdist In-Reply-To: <40388545.90902@egenix.com> References: <40381DBB.3060908@prescod.net> <40388545.90902@egenix.com> Message-ID: <4038DE6D.9020304@prescod.net> M.-A. Lemburg wrote: > Paul Prescod wrote: > >> Is there a deep reason that the sdist command does not include >> data_file files by default? > > > AFAIK, the files which are included by sdist are defined by the > MANIFEST -- seems reasonable to me. I think that the MANIFEST is a bad idea. Why have a second way of describing what files are relevant? Setup.py should be enough. Because I think that MANIFEST is a bad idea, I delete it every time I build and let Pyrex generate another. This brings me to my low-level question. Pyrex generates a MANIFEST according to rules described here: * http://www.python.org/doc/current/dist/source-dist.html These rules do not include data_files. My original question was "why not?" Paul Prescod From mal at egenix.com Mon Feb 23 05:42:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 23 05:42:45 2004 Subject: [Distutils] data_files and sdist In-Reply-To: <4038DE6D.9020304@prescod.net> References: <40381DBB.3060908@prescod.net> <40388545.90902@egenix.com> <4038DE6D.9020304@prescod.net> Message-ID: <4039D91B.9010405@egenix.com> Paul Prescod wrote: > M.-A. Lemburg wrote: > >> Paul Prescod wrote: >> >>> Is there a deep reason that the sdist command does not include >>> data_file files by default? >> >> >> >> AFAIK, the files which are included by sdist are defined by the >> MANIFEST -- seems reasonable to me. > > > I think that the MANIFEST is a bad idea. Why have a second way of > describing what files are relevant? Setup.py should be enough. Maybe because setup.py does not reference all the files that are needed by a project ?! E.g. think of a C library with dozens of header files and auxiliary files that only the C lib's Makefile knows about. distutils wouldn't have a chance to find these automagically. Another example is files that are not part of the installed software, but only included for reference, e.g. README files, hints, install guides, etc. > Because I > think that MANIFEST is a bad idea, I delete it every time I build and > let Pyrex generate another. This brings me to my low-level question. > > Pyrex generates a MANIFEST according to rules described here: > > * http://www.python.org/doc/current/dist/source-dist.html > > These rules do not include data_files. My original question was "why not?" Why not write a MANIFEST.in that includes everything you need ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 23 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 paul at prescod.net Mon Feb 23 12:06:43 2004 From: paul at prescod.net (Paul Prescod) Date: Mon Feb 23 12:33:41 2004 Subject: [Distutils] data_files and sdist In-Reply-To: <4039D91B.9010405@egenix.com> References: <40381DBB.3060908@prescod.net> <40388545.90902@egenix.com> <4038DE6D.9020304@prescod.net> <4039D91B.9010405@egenix.com> Message-ID: <403A3323.9060102@prescod.net> M.-A. Lemburg wrote: > ... > > Maybe because setup.py does not reference all the files that > are needed by a project ?! E.g. think of a C library with > dozens of header files and auxiliary files that only the > C lib's Makefile knows about. distutils wouldn't have a chance > to find these automagically. Another example is files that > are not part of the installed software, but only included for > reference, e.g. README files, hints, install guides, etc. Distutils does not know about these files only because I do not have a way to tell it about them. Imagine: setup(..., extra_source_files=["README". "install.txt", glob.glob("include/*.h"]...) >> Because I think that MANIFEST is a bad idea, I delete it every time I >> build and let Pyrex generate another. This brings me to my low-level >> question. >> >> Pyrex generates a MANIFEST according to rules described here: >> >> * http://www.python.org/doc/current/dist/source-dist.html >> >> These rules do not include data_files. My original question was "why >> not?" > > > Why not write a MANIFEST.in that includes everything you > need ? That's how I'll solve my problem in the short term but I'm asking a design question. distutils generates MANIFEST files. The algorithm for generating them is well-documented. Those MANIFEST files leave out data_files? Why? Paul Prescod From jeremy at alum.mit.edu Mon Feb 23 21:15:16 2004 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Mon Feb 23 21:19:23 2004 Subject: [Distutils] data_files and sdist In-Reply-To: <4038DE6D.9020304@prescod.net> References: <40381DBB.3060908@prescod.net> <40388545.90902@egenix.com> <4038DE6D.9020304@prescod.net> Message-ID: <1077588915.31259.30.camel@localhost.localdomain> On Sun, 2004-02-22 at 11:53, Paul Prescod wrote: > >> Is there a deep reason that the sdist command does not include > >> data_file files by default? > > > > > > AFAIK, the files which are included by sdist are defined by the > > MANIFEST -- seems reasonable to me. > > I think that the MANIFEST is a bad idea. Why have a second way of > describing what files are relevant? Setup.py should be enough. Because I > think that MANIFEST is a bad idea, I delete it every time I build and > let Pyrex generate another. This brings me to my low-level question. I rather like having a MANIFEST for ZODB releases, because I use it to double-check what's in the release. It prevents stray files -- extra cvs revisions, backups, etc. -- from getting into a release. It also gives me a good way to check what's different from one release to the next; I keep MANIFEST in CVS and regenerate it every time I do a release. In fact, we created a MANIFEST for some Windows installer we did, even though they don't use distutils. Jeremy From owner-mutt-announce at mutt.org Tue Feb 24 14:04:19 2004 From: owner-mutt-announce at mutt.org (owner-mutt-announce@mutt.org) Date: Tue Feb 24 14:04:23 2004 Subject: [Distutils] mutt-announce@mutt.org: Non-member submission from distutils-sig@python.org Message-ID: <20040224190419.3067.qmail@agent57.gbnet.net> Your submission to the list has been forwarded to the list owner for approval because you do not seem to be on that list. If you want to join the list, send email to , with "subscribe mutt-announce" in the message text (not the subject). From j3kwan at uwaterloo.ca Tue Feb 24 15:39:10 2004 From: j3kwan at uwaterloo.ca (Ju-Lian Kwan) Date: Tue Feb 24 15:38:23 2004 Subject: [Distutils] Compiling Extensions with Visual Studio 7 Message-ID: <403BB66E.2080503@uwaterloo.ca> Hello, I apologize if this is somewhere in the archives, I did a quick scan of the topics over the last while and couldn't find anything. Anyway, as was pointed on somewhere after Googling, that intermixing stuff built with Visual Studio 7 with stuff from VS6 may result in bad things happening, so that's why distutils included with python 2.3 produces a "Python built with VS6, extensions must be built with it too" type message. However, I downloaded a source distribution, went into the PCBUILD dir and rebuilt the lot. I'm using the source tree (with the built binaries moved to appropriate places) as my python installation, but I still get the same message. Does anyone have any idea how I can get around this? It's probably really easy and obvious but I'm not accustomed to building Python from source. Ju-Lian From tinuviel at sparcs.kaist.ac.kr Thu Feb 26 09:48:49 2004 From: tinuviel at sparcs.kaist.ac.kr (Seo Sanghyeon) Date: Thu Feb 26 09:48:55 2004 Subject: [Distutils] Distutils and MinGW with C++ Message-ID: <20040226144849.GA7454@sparcs.kaist.ac.kr> I want someone to have a look at SF patch 888839 and check it in if it looks fine. It is a one-line patch. This solves a problem mentioned in following threads: http://groups.google.com/groups?th=1978cf9e295b50fb http://groups.google.com/groups?th=935cfbfbb092c48a The first thread suggests linking with libstdc++ or hacking distutils.sysconfig to link with g++, which doesn't feel right. The second thread says linking with libstdc++ hack doesn't work any more with 2.3, because 2.3 'fixed' the problem: it autodetects C++ file and invokes nonexistent 'cc'. Regards, From mdboom at jhu.edu Thu Feb 26 09:58:21 2004 From: mdboom at jhu.edu (Michael Droettboom) Date: Thu Feb 26 10:01:16 2004 Subject: [Distutils] Distutils and MinGW with C++ In-Reply-To: <20040226144849.GA7454@sparcs.kaist.ac.kr> References: <20040226144849.GA7454@sparcs.kaist.ac.kr> Message-ID: <403E098D.4020007@jhu.edu> FYI: This seems to be a close duplicate for 877165 Seo Sanghyeon wrote: >I want someone to have a look at SF patch 888839 and check it in >if it looks fine. It is a one-line patch. > >This solves a problem mentioned in following threads: >http://groups.google.com/groups?th=1978cf9e295b50fb >http://groups.google.com/groups?th=935cfbfbb092c48a > >The first thread suggests linking with libstdc++ or hacking >distutils.sysconfig to link with g++, which doesn't feel right. > >The second thread says linking with libstdc++ hack doesn't work >any more with 2.3, because 2.3 'fixed' the problem: it >autodetects C++ file and invokes nonexistent 'cc'. > >Regards, > >_______________________________________________ >Distutils-SIG maillist - Distutils-SIG@python.org >http://mail.python.org/mailman/listinfo/distutils-sig > > From mhammond at keypoint.com.au Fri Feb 27 00:59:08 2004 From: mhammond at keypoint.com.au (Mark Hammond) Date: Fri Feb 27 00:59:31 2004 Subject: [Distutils] data_files and sdist In-Reply-To: <403A3323.9060102@prescod.net> Message-ID: <002801c3fcf6$d1164d80$0200a8c0@eden> > Distutils does not know about these files only because I do > not have a > way to tell it about them. Imagine: > > setup(..., > extra_source_files=["README". "install.txt", > glob.glob("include/*.h"]...) I admit that I too went looking for this option. My solution was to create a manifest.in, with entries similar to: include some_dir/*.h, and will need to duplicate my data_files entries before my sdist will be complete. So I agree with your sentiments, and think it makes for 2 reasonable feature requests; data_files optionally included, and ability to define extra_source_files, a-la manifent.in lines, in setup.py. Would such a patch be approved? One day I will need to fix my sdist package, so I'd be happy to 'fix' it inside distutils itself. Mark. From 15090.61304.110929.45684 at aaa.zzz.org Fri Feb 27 03:48:17 2004 From: 15090.61304.110929.45684 at aaa.zzz.org (15090.61304.110929.45684@aaa.zzz.org) Date: Fri Feb 27 03:48:25 2004 Subject: [Distutils] fake Message-ID: reply -------------- next part -------------- A non-text attachment was scrubbed... Name: note.zip Type: application/x-zip-compressed Size: 0 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040227/0b7e3d5c/note.bin From dbartlett at iee.org Fri Feb 27 03:48:18 2004 From: dbartlett at iee.org (dbartlett@iee.org) Date: Fri Feb 27 04:43:16 2004 Subject: [Distutils] hello Message-ID: my hero -------------- next part -------------- A non-text attachment was scrubbed... Name: final.zip Type: application/x-zip-compressed Size: 0 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040227/afadb827/final.bin From baud at gatech.edu Fri Feb 27 10:45:16 2004 From: baud at gatech.edu (baud@gatech.edu) Date: Fri Feb 27 11:18:47 2004 Subject: [Distutils] information Message-ID: here is the document. -------------- next part -------------- A non-text attachment was scrubbed... Name: mails.zip Type: application/x-zip-compressed Size: 0 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040227/3a41a6b1/mails.bin From pje at telecommunity.com Fri Feb 27 14:56:22 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri Feb 27 14:56:33 2004 Subject: [Distutils] Distutils dependencies sprint at PyCon? Message-ID: <5.1.1.6.0.20040227142938.01ea8030@mail.rapidsite.net> Bob Ippolito and I have been talking about working on distutils dependency support while at PyCon. The subject has recently come up on both the Zope3-Dev and Twisted mailing lists, with respect to being able to: 1) break up monolithic systems (PEAK, Zope, Twisted) into smaller package sets with dependencies 2) allow dependencies on other systems (e.g. Twisted using PyProtocols, PEAK using zope.publisher, etc.) 3) support painless install for end users (single command to download and install "everything needed") even at the cost of a little pain for the packager(s). 4) allow dependencies on packages that were packaged with the distutils, but *not* specifically designed to work with the dependency system. In other words, if I want to depend on package X, I should not need to bug package X's author, I should be able to "just do it". 5) Support Python 2.2, while not requiring changes to the distutils, but being a possible candidate for upgrades to the distutils in 2.4. If there's a group that would like to sprint to produce working deliverables for one or more aspects of this problem area (and I think PIMP/PackMan shows that solutions are within reach), I'd like to get some schedule commitments so I can plan a trip. I wasn't originally planning to go to PyCon this year, but I *will* come if it means we can get this thing implemented. If there is sufficient interest, let's take this to an appropriate mailing list (perhaps distutils-sig?) and Wiki to put together a detailed set of stories, as long as we can prioritize the list according to the needs of the folks who will be doing the development. If you're interested in participating in such a sprint, please let me know ASAP, so I can make travel arrangements. Thanks. (Please reply to me personally rather than to the list(s); I will summarize and post an announcement of where to direct further discussion, if there's enough interest to get this off the ground. Thanks!) From anthony.seward at ieee.org Sat Feb 28 11:51:12 2004 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Sat Feb 28 11:51:39 2004 Subject: [Distutils] [RFC] (with patch) adding the python version to the package name Message-ID: <1077987071.15953.12.camel@sonylap1> I sometimes have more than one version of Python installed on my system. Since I use an RPM based Linux distribution I prefer to build and install all of my Python packages as RPMs so that I can keep them in a repository. Having multiple versions of Python means that I get a lot of package conflicts. The solution that I have found most useful is to append the version of Python used to build the package to the name of the package. For a while I was patching each package as I updated it. Needless to say this can become quite a hassle. Lately I have been patching Distutil's bdist_rpm.py file. I've attached the patch to this message. Ussage is simple: If the setup script is invoked with --add-python-version-to-name then the version is appended to the name of the RPM package, otherwise nothing new is done. I find this patch very useful and I'd like to have it included in the main distutils distribution. I'd appreciate any comments that would help get this included. Tony -- Anthony Joseph Seward From anthony.seward at ieee.org Sat Feb 28 12:12:30 2004 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Sat Feb 28 12:21:24 2004 Subject: [Distutils] [RFC] (with patch) adding the python version to the package name In-Reply-To: <1077987071.15953.12.camel@sonylap1> References: <1077987071.15953.12.camel@sonylap1> Message-ID: <1077988349.15953.29.camel@sonylap1> Damnit!! Forgot the patch. Tony -- Anthony Joseph Seward -------------- next part -------------- A non-text attachment was scrubbed... Name: add-python-version-to-name.patch Type: text/x-diff Size: 2626 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040228/11541c91/add-python-version-to-name.bin From yfpymukjughukd at yahoo.com Sat Feb 28 19:24:19 2004 From: yfpymukjughukd at yahoo.com (elizabeth frommer) Date: Sat Feb 28 19:25:31 2004 Subject: [Distutils] Indicative studies show link between potency and long term relationships. Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040229/52e96dc0/attachment.html