Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
On gio, 2008-11-27 at 00:29 +0100, Martin v. Löwis wrote: So, deducing from your reply, this merge module is a thing that allows to install the CRT (and other shared components)? Correct. More generally, a merge module is a something like an MSI library (.a). It includes a set of files and snippets of an installation procedure for them. OK. One question: why CRT doesn't get installed as regular files near to the python executable? That's how I usually ship it, but maybe Python has some special need. Another option is to contact the Advanced Installer vendor and ask for a free license for the Python Software Foundation. This would mean that everybody in the world would still be able to build an installer without CRT, and only PSF would build the official one with CRT bundled. I personally don't see this as a show-stopper (does anyone ever build the .msi besides Martin?). I personally don't have any interest to spend any time on an alternative technology. The current technology works fine for me, and I understand it fully. Everybody in the world is able to build an installer today, also. However, I won't stop anybody else from working a switch to a different technology, either. I proposed an alternatives because I read you saying: The tricky part really is when it breaks (which it does more often than not), in which case you need to understand msi.py, for which you need to understand MSI. Which means that maybe everybody *has tools* to build an installer today, but only a few people have the required knowledge to really do releases on Windows. So I believe that switching to an alternative that doesn't require full understanding of MSI and msi.py would probably low the barrier and allow more people to help you out. -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Giovanni Bajo wrote: On gio, 2008-11-27 at 00:29 +0100, Martin v. Löwis wrote: So, deducing from your reply, this merge module is a thing that allows to install the CRT (and other shared components)? Correct. More generally, a merge module is a something like an MSI library (.a). It includes a set of files and snippets of an installation procedure for them. OK. One question: why CRT doesn't get installed as regular files near to the python executable? That's how I usually ship it, but maybe Python has some special need. When installing for all users, pythonxy.dll goes into system32. This, in turn, requires the CRT to be installed globally (which meant into system32 for VS6 and VS7.1, but means using SxS for VS 2008). It's necessary to install it into system32 so that PythonCOM can find it (alternatively, we could now also making it an SxS assembly). VS2008 adds another twist: assembly manifests. As a consequence of this technology, if Python 2.6 is installed just for me on Windows Vista (i.e. the CRT is next to the executable), it just won't work, because the extension modules (.pyd) can't find the CRT. I proposed an alternatives because I read you saying: The tricky part really is when it breaks (which it does more often than not), in which case you need to understand msi.py, for which you need to understand MSI. Which means that maybe everybody *has tools* to build an installer today, but only a few people have the required knowledge to really do releases on Windows. So I believe that switching to an alternative that doesn't require full understanding of MSI and msi.py would probably low the barrier and allow more people to help you out. I remain skeptical. You replace the need to learn MSI with the need to learn this tool, and not only to work around the limitations of MSI, but also around the limitations of the tool you have chosen. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
I am not at all a windows person but I have used http://www.dennisbareis.com/makemsi.htm in the past to automate editing and tweaking some MSI files for testing. It can also be used to generate new ones. It looks like it would still require something to generate its own input description. Regardless, just wanted to offer the link so people are aware that it exists. I have no opinion on what actually gets used so long as its automated. -gps On Thu, Nov 27, 2008 at 7:24 AM, Martin v. Löwis [EMAIL PROTECTED]wrote: Giovanni Bajo wrote: On gio, 2008-11-27 at 00:29 +0100, Martin v. Löwis wrote: So, deducing from your reply, this merge module is a thing that allows to install the CRT (and other shared components)? Correct. More generally, a merge module is a something like an MSI library (.a). It includes a set of files and snippets of an installation procedure for them. OK. One question: why CRT doesn't get installed as regular files near to the python executable? That's how I usually ship it, but maybe Python has some special need. When installing for all users, pythonxy.dll goes into system32. This, in turn, requires the CRT to be installed globally (which meant into system32 for VS6 and VS7.1, but means using SxS for VS 2008). It's necessary to install it into system32 so that PythonCOM can find it (alternatively, we could now also making it an SxS assembly). VS2008 adds another twist: assembly manifests. As a consequence of this technology, if Python 2.6 is installed just for me on Windows Vista (i.e. the CRT is next to the executable), it just won't work, because the extension modules (.pyd) can't find the CRT. I proposed an alternatives because I read you saying: The tricky part really is when it breaks (which it does more often than not), in which case you need to understand msi.py, for which you need to understand MSI. Which means that maybe everybody *has tools* to build an installer today, but only a few people have the required knowledge to really do releases on Windows. So I believe that switching to an alternative that doesn't require full understanding of MSI and msi.py would probably low the barrier and allow more people to help you out. I remain skeptical. You replace the need to learn MSI with the need to learn this tool, and not only to work around the limitations of MSI, but also around the limitations of the tool you have chosen. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
I always wondered why it was necessary to write msi.py in the first place. Maintaining it is surely a big effort and requires understanding of a dark library which a few people have (IMO it's a much higher effort than setting up automated tests in a bunch of VM, which you said is not worth it). There are plenty of MSI installer generator programs Originally it was written because none of the MSI generator programs were capable of packaging Python. In particular, none was capable of creating 64-bit packages (which were first needed to create the Itanium packages). and Python's needs do not seem so weird to require a custom MSI generator. Python's needs are fairly weird, so I'm very skeptical that any other generator is capable of doing what msi.py does (or, if it was capable of doing that, that it was then any simpler than msi.py). The critical part is that you need a powerful way to specify what files to package (having to select them in a UI is unacceptable, as the set of files constantly changes - the current generator can cope with many types of file additions without needing any change). I'm sure the Python Software Foundation would easily get a free license of one of the good commercial MSI installer generators. Can you recommend a specific one? In addition, I'm also skeptical wrt. commercial setup tools. We had been using Wise for a while, and it was a management problem because the license was only available on a single machine - so it was difficult for anybody else to jump in and do a release. In short: if msi.py and the fact it breaks is part of the issue here, it's very easy to solve in my opinion. I'm very skeptical that this statement is actually true. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Martin v. Löwis wrote: I always wondered why it was necessary to write msi.py in the first place. Maintaining it is surely a big effort and requires understanding of a dark library which a few people have (IMO it's a much higher effort than setting up automated tests in a bunch of VM, which you said is not worth it). There are plenty of MSI installer generator programs Originally it was written because none of the MSI generator programs were capable of packaging Python. In particular, none was capable of creating 64-bit packages (which were first needed to create the Itanium packages). and Python's needs do not seem so weird to require a custom MSI generator. Python's needs are fairly weird, so I'm very skeptical that any other generator is capable of doing what msi.py does (or, if it was capable of doing that, that it was then any simpler than msi.py). The critical part is that you need a powerful way to specify what files to package (having to select them in a UI is unacceptable, as the set of files constantly changes - the current generator can cope with many types of file additions without needing any change). Wix is an msi creator (open source) that takes XML files as the input. It is also capable of creating 64bit installers. At Resolver Systems we use CPython scripts to generate the XML as input for Wix. It would still need *some* code therefore, but maybe simpler if someone wanted to do the work. :-) It would work well with the files being generated from an XML templating language like Mako which is what we will be switching to at Resolver Systems. http://wix.sourceforge.net/ Michael Foord I'm sure the Python Software Foundation would easily get a free license of one of the good commercial MSI installer generators. Can you recommend a specific one? In addition, I'm also skeptical wrt. commercial setup tools. We had been using Wise for a while, and it was a management problem because the license was only available on a single machine - so it was difficult for anybody else to jump in and do a release. In short: if msi.py and the fact it breaks is part of the issue here, it's very easy to solve in my opinion. I'm very skeptical that this statement is actually true. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Martin, What is the rationale behind using an MSI ? Has anyone attempted to create a Python installer using something a bit simpler, like NSIS [ http://nsis.sourceforge.net/Main_Page]? If not, what are the reasons? Joe On Wed, Nov 26, 2008 at 3:03 PM, Martin v. Löwis [EMAIL PROTECTED]wrote: I always wondered why it was necessary to write msi.py in the first place. Maintaining it is surely a big effort and requires understanding of a dark library which a few people have (IMO it's a much higher effort than setting up automated tests in a bunch of VM, which you said is not worth it). There are plenty of MSI installer generator programs Originally it was written because none of the MSI generator programs were capable of packaging Python. In particular, none was capable of creating 64-bit packages (which were first needed to create the Itanium packages). and Python's needs do not seem so weird to require a custom MSI generator. Python's needs are fairly weird, so I'm very skeptical that any other generator is capable of doing what msi.py does (or, if it was capable of doing that, that it was then any simpler than msi.py). The critical part is that you need a powerful way to specify what files to package (having to select them in a UI is unacceptable, as the set of files constantly changes - the current generator can cope with many types of file additions without needing any change). I'm sure the Python Software Foundation would easily get a free license of one of the good commercial MSI installer generators. Can you recommend a specific one? In addition, I'm also skeptical wrt. commercial setup tools. We had been using Wise for a while, and it was a management problem because the license was only available on a single machine - so it was difficult for anybody else to jump in and do a release. In short: if msi.py and the fact it breaks is part of the issue here, it's very easy to solve in my opinion. I'm very skeptical that this statement is actually true. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/josepharmbruster%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Wix is an msi creator (open source) that takes XML files as the input. It is also capable of creating 64bit installers. At Resolver Systems we use CPython scripts to generate the XML as input for Wix. It would still need *some* code therefore, but maybe simpler if someone wanted to do the work. :-) I had looked at WiX before, and found that it can't do out of the box what I want to do - I still would need to generate the input files, e.g. with a script (and I'm happy to hear that you can confirm that analysis). I also had quite some problems understanding it, and can understand msi.py much better (surprise, surprise). For a newcomer, my feeling is that learning WiX and learning msi.py is about the same effort - you really need to get MSI files. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Martin v. Löwis wrote: I'm sure the Python Software Foundation would easily get a free license of one of the good commercial MSI installer generators. Can you recommend a specific one? In addition, I'm also skeptical wrt. commercial setup tools. We had been using Wise for a while, and it was a management problem because the license was only available on a single machine - so it was difficult for anybody else to jump in and do a release. I've also had terrible times with installshield and other things in the past, but I've been very very pleased with WiX: http://wix.sourceforge.net/ Free, open source, and it gave me absolute control over how the MSI and MSM modules were built, using text files so I could store them in version control, spit out installers from our automated build, etc. The source format is XML (shrug), so on that project we even wrote a WiX parser to calculate SCons dependencies all the way through the MSM to the MSI, so that we could tell when a source file was changed what installers needed to be resigned and shipped to customers. It's really nice to be able to code review installer changes, and to have automated builds spit out .msi files alongside the .debs and .rpms and more. -- Elliot Murphy | https://launchpad.net/~statik/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
What is the rationale behind using an MSI ? Has anyone attempted to create a Python installer using something a bit simpler, like NSIS [http://nsis.sourceforge.net/Main_Page]? If not, what are the reasons? It's a lot of effort to look at any such tool (and I really mean a *lot* of effort - like a full week). That's why nobody did it. When I looked at MSI, I did it because it has a few unique features: - it supports 64-bit installers, which now is an absolute requirement (people really do want to use the AMD64 binaries) a shallow look at the feature list of NSIS suggest that NSIS would fail this requirement. - it supports installation through Windows Domain policy. I would be willing to drop this requirement, but I believe some users would not be happy. Nothing but MSI has this capability (by design of Windows Active Directory). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
I've had good results with Advanced Installer: http://www.advancedinstaller.com/feats-list.html So how much effort would it be to create a Python installer? Could you kindly provide one? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
On mer, 2008-11-26 at 21:03 +0100, Martin v. Löwis wrote: I'm sure the Python Software Foundation would easily get a free license of one of the good commercial MSI installer generators. Can you recommend a specific one? I've had good results with Advanced Installer: http://www.advancedinstaller.com/feats-list.html It does support 64-bit packages, and it uses a XML file as input. It supports Vista and UAC, per-user and per-machine install, registry modification, environment variables, upgrades/downgrades/side installs, online installs. And it's free as in beer. The commercial version has many more features, but I don't think Python needs them. But the basic idea is that this tool totally abstracts the MSI details. I know *nothing* of MSI but I'm fully able to use this tool and produce installers with more features than those I notice within Python's installer. -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Giovanni Bajo wrote: On mer, 2008-11-26 at 21:03 +0100, Martin v. Löwis wrote: I'm sure the Python Software Foundation would easily get a free license of one of the good commercial MSI installer generators. Can you recommend a specific one? I've had good results with Advanced Installer: http://www.advancedinstaller.com/feats-list.html It does support 64-bit packages, and it uses a XML file as input. It supports Vista and UAC, per-user and per-machine install, registry modification, environment variables, upgrades/downgrades/side installs, online installs. And it's free as in beer. The commercial version has many more features, but I don't think Python needs them. The free edition is missing at least one important feature: Merge Modules into your installation Create self-contained MSI packages, by including and configuring the required merge modules. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Merge Modules into your installation Create self-contained MSI packages, by including and configuring the required merge modules. Right. Still, if people want to go this route (I personally don't), I think it would be useful to build an installer from the free edition. You can then run Tools/msi/merge.py, which adds the CRT merge module into the MSI file (mostly as-is, except for discarding the ALLUSERS property from that merge module). Alternatively, for testing, you can just assume that the CRT is already installed. When we then have a script that generates a mostly-complete installer, I'm sure Giovanni would be happy to add support for the CRT merge module to see how the tool fares (my expectation is that it breaks, as I assume it just doesn't deal with the embedded ALLUSERS property correctly - merge.py really uses a bad hack here). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
On mer, 2008-11-26 at 23:38 +0100, Martin v. Löwis wrote: Merge Modules into your installation Create self-contained MSI packages, by including and configuring the required merge modules. Right. Still, if people want to go this route (I personally don't), I think it would be useful to build an installer from the free edition. You can then run Tools/msi/merge.py, which adds the CRT merge module into the MSI file (mostly as-is, except for discarding the ALLUSERS property from that merge module). Alternatively, for testing, you can just assume that the CRT is already installed. So, deducing from your reply, this merge module is a thing that allows to install the CRT (and other shared components)? I quickly googled but I'm not really into the msi slang, so I'm not sure I understood. When we then have a script that generates a mostly-complete installer, I'm sure Giovanni would be happy to add support for the CRT merge module to see how the tool fares (my expectation is that it breaks, as I assume it just doesn't deal with the embedded ALLUSERS property correctly - merge.py really uses a bad hack here). Another option is to contact the Advanced Installer vendor and ask for a free license for the Python Software Foundation. This would mean that everybody in the world would still be able to build an installer without CRT, and only PSF would build the official one with CRT bundled. I personally don't see this as a show-stopper (does anyone ever build the .msi besides Martin?). -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
On mer, 2008-11-26 at 22:54 +0100, Martin v. Löwis wrote: I've had good results with Advanced Installer: http://www.advancedinstaller.com/feats-list.html So how much effort would it be to create a Python installer? Could you kindly provide one? In my case, the biggest effort would be finding out what needs to be put within the installer. If you can give me a pointer to where the current build process reads the complete file list to put within the .msi (and their relative destination path), I can try and build a simple test installer, on which we can start doing some evaluations. -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
In my case, the biggest effort would be finding out what needs to be put within the installer. If you can give me a pointer to where the current build process reads the complete file list to put within the .msi (and their relative destination path), I can try and build a simple test installer, on which we can start doing some evaluations. The simplest approach might be to look at what it actually installs. If you want to read the specifcation: it's in Tools/msi/msi.py:add_files. directory.add_file takes a file, and optionally a source file (which defaults to the respective source directory). You also need to consider the features structure; there is a current feature at any point in time, and all components being added get added to the current feature. HTH, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 19, 2008, at 3:19 PM, Terry Reedy wrote: Let's try this for 3.0rc4 then. The current release is rc2. Skipping rc3 would confuse people'-) Yeah, my calendar was wrong, but the PEP (and more importantly... code!) was right :). There is no rc4! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSScZWXEjvBPtnXfVAQKpQAQAi9Q8rfgcCVXmQ2tIqaiAVKOQHDPQdfhF lyDWHg+6i2EGrbs0Jju5GB9YML1yNga3X85zfQSedu6mgpA4dV6NvW988N3Wp4oG ztDGT7yLxwYe4Wy606FF6lxSlXSvXQRLc/Nf1qgn8dDGskQKO2LZ+fUHW0BIWDBN RFAuZqzdWQY= =9Z8w -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
2008/11/18 Martin v. Löwis [EMAIL PROTECTED]: While I'm happy that Barry has automated his part to a high degree, my part is, unfortunately, much less automated. I could personally automate the build process a bit more, but part of it is also testing of the installers, which is manual. Martin, maybe we can help you with the installers testing. While I don't have a clue about compiling complex software in Windows (and also want to stay away from that), I have a virtualbox with a win xp in my workstation, so I could try an installer. Maybe you could put a wiki page somewhere with a small recipe about what to look when testing an installer, and then produce all the versions, upload to it, and alert us here. So we go, download one of them, try it, and then mark it as tested with our name (maybe we can look after two or three testers per installer). I don't know if this will be quicker, but surely will lower your workload regarding this, which is a good thing. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Martin v. Löwis wrote: While I'm happy that Barry has automated his part to a high degree, my part is, unfortunately, much less automated. I could personally automate the build process a bit more, but part of it is also testing of the installers, which is manual. Maybe you could delegate a lot of the testing to competent volunteers? That's not the issue - I don't mind spending that time. However, it means that several hours pass between starting the release process, and making the binaries available - during this time, users always complain why the Windows binaries are not released yet. With additional volunteers, availability of the binaries would lag even more behind the release announcement. Installer tests can definitely be automated, and there is also a Python API to the virtualbox VM. I wonder if it would be possible to automate testing all the installers in various scenarios - each running simultaneously in a VM. Michael [1] Doesn't Windows have a way to send synthetic GUI events to a program? There ought to be a way to really script that, as the Python installer process presumbly doesn't change much from release to release. I also need to involve different machines, e.g. XP machines and Vista machines, and machines that have Visual Studio installed and machines that don't. Plus, I need to log into each machine in different ways: as admin user and non-admin user. The automated GUI testing only really works for a logged-in user. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Michael Foord writes: Installer tests can definitely be automated, and there is also a Python API to the virtualbox VM. I wonder if it would be possible to automate testing all the installers in various scenarios - each running simultaneously in a VM. Now that would be an impressive tour de force! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 18, 2008, at 5:17 PM, Martin v. Löwis wrote: From my point of view bi-monthly release are too much. For a ?.?.1 release two months are fine because several issues are found by 3rd party authors. But after that a release every quarter is sufficient. * .1 release two months after the .0 release * .2, .3, .4 and .5 release every quarter * about here the next minor release gets out * .6 and further releases after 6 months when necessary In the past, we had been striving for releases every 6 month. This was already very difficult to achieve. While I'm happy that Barry has automated his part to a high degree, my part is, unfortunately, much less automated. I could personally automate the build process a bit more, but part of it is also testing of the installers, which is manual. Martin, I'm keen on figuring out a way to reduce your workload, and also to coordinate releases better between us. I /think/ with timed releases I can tag a little early and give you something to work on so that the actual release is a matter of fiddling web pages and sending an announcement. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSSQwbnEjvBPtnXfVAQIOuAP/fxzFpp886TordGNdd4tusqasL/VK2lpr wbhcfwh5TQbVhkhi9CVUFa7BNXCpgxG1nqWT9+ynSdNKIYKnK8kkjRE7FhEYantP TYkuRGI+2DznKjRBtVNXJq+JNktARWKhQwFkc0AmqooCYvhxqt9T5AkEgN4jRn4s YBLaex4g3rA= =Oi0b -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Martin, maybe we can help you with the installers testing. Thanks for the offer. See my other message, though - this is not the point. If everything goes well, offloading testing just means that I have to wait some time for the testers to come back, and do other stuff meanwhile. For the majority of alpha and beta releases, something went wrong each time. A file was forgotten to be included in the installer generator, causing it to be missing on the target system. I forgot to perform a manual build step, causing the installer to fail, and so on. Then I have to debug the problem, and restart the production process from scratch. Offloading to testers in this case would just mean that I wait much longer until I can release, and it might not be possible to complete the build within a single day. I don't know if this will be quicker, but surely will lower your workload regarding this, which is a good thing. Thanks again - but I do typically find the time to do the release (if not, it gets delayed by another day). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Installer tests can definitely be automated, and there is also a Python API to the virtualbox VM. I wonder if it would be possible to automate testing all the installers in various scenarios - each running simultaneously in a VM. I do use VMs, yes. However, they don't run on my workstation - which is 32-bit XP. It might be possible to automate it, but IMO, the effort of setting this up would be higher than the actual time spend in doing it manually, assuming we have no more than a dozen releases per year. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Martin, I'm keen on figuring out a way to reduce your workload, and also to coordinate releases better between us. I /think/ with timed releases I can tag a little early and give you something to work on so that the actual release is a matter of fiddling web pages and sending an announcement. Again - the work load is not so much an issue at the moment, and I expect it to be reduced even after 3.0 is finally released and 2.5 retired. I would indeed appreciate tighter coordination. Anthony's process differed from yours primarily in him waiting for the release announcements until the binaries are actually available. That might mean that a day or two might pass, but it did help to remove the feeling of working under tight deadlines. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 19, 2008, at 2:18 PM, Martin v. Löwis wrote: Martin, I'm keen on figuring out a way to reduce your workload, and also to coordinate releases better between us. I /think/ with timed releases I can tag a little early and give you something to work on so that the actual release is a matter of fiddling web pages and sending an announcement. Again - the work load is not so much an issue at the moment, and I expect it to be reduced even after 3.0 is finally released and 2.5 retired. I would indeed appreciate tighter coordination. Anthony's process differed from yours primarily in him waiting for the release announcements until the binaries are actually available. That might mean that a day or two might pass, but it did help to remove the feeling of working under tight deadlines. Let's try this for 3.0rc4 then. I think all it means is that I won't push the new pages or make the announcement until you verify that the Windows builds are ready and available. We can still use python- committers to coordinate when that will happen, and I'll still do all the release mechanics from my end as normal. It's okay if the announcement happens Friday or over the weekend. I will also try to get up early to do the release before my work day starts, to better coordinate with Euro time. So expect me on #python- dev tomorrow (my morning). Will that work for you? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSSRrAnEjvBPtnXfVAQJiDwP/ZcbHnwkvWligaP2a3OXEmZ30GZoG1NQn +Lj/j4YNANkhxZ4Vgg9gkMH3mQ+eTwWdqr1/VM3LTW+fFXhdtAaAG1NsvHAlkAE0 N+DgEOEv4aMuO6MZplv/1kh4WeFC7SsnEX7bLext0QZITdBaL65dUN8Kt8G/ZeTG w3lQ01nBFqY= =InnO -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
In which case why not just hold the release until all installers are available? That is how Anthony Baxter handled things, indeed, and I would appreciate if we would return to that procedure. Or are the complainers Python developers who know what goes on behind the scenes? No - typically outsiders, who report that the links are broken (if the links get updated and the files are missing), or that the links are old (if the links are not updated). I think these people also try to be helpful (in addition to being frustrated that the release announcement is meaningless to them, and that they have to poll the release page). With additional volunteers, availability of the binaries would lag even more behind the release announcement. I really appreciate the dedicated work you put in to the Windows installers (as I am sure many others do also), but I wouldn't want to saddle you with it indefinitely. How well is the procedure documented? IIRC, Christian Heimes did one of the alpha or beta releases, with what little documentation is available, so it's definitely doable. The tricky part really is when it breaks (which it does more often than not), in which case you need to understand msi.py, for which you need to understand MSI. IMO, the Microsoft is excellent (in being fairly precise), but the learning curve is high. The mechanical part of it can is completely automated - we produce daily MSI files in a buildbot slave (which may or may not work - I haven't checked in a while) I ask this in hopes that you aren't a potential single point of failure in the release process. I think several of the Windows people could jump in, not just Christian. That would be best done in a beta release or release candidate, since one does get things wrong the first time. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
I will also try to get up early to do the release before my work day starts, to better coordinate with Euro time. So expect me on #python-dev tomorrow (my morning). Will that work for you? If you delay the announcement until the binaries are ready, you should feel free to work on it whenever it suits you best, as far as I'm concerned (of course, to coordinate with Georg, you might still prefer to work during the European daylight). I'll be busy with lectures tomorrow most of the day, and can't start working on the installer before 14:00 UTC (which I think is 9:00 your time). Around what time would you expect to have the tag set? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Let's try this for 3.0rc4 then. The current release is rc2. Skipping rc3 would confuse people'-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
2008/11/17 Barry Warsaw [EMAIL PROTECTED]: Martin suggests, and I agree, that we should release Python 3.0 final and 2.6.1 at the same time. Makes sense to me. That would mean that Python 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!). 2.6.1 only two months after 2.6? Why so quickly? Anyway, I don't see any added value in the synchronization, so taking in consideration all the effort you're putting in these releases, I would just want to minimize your workload... which is easier to you? doing both at the same time or not? Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Facundo Batista wrote: 2008/11/17 Barry Warsaw [EMAIL PROTECTED]: Martin suggests, and I agree, that we should release Python 3.0 final and 2.6.1 at the same time. Makes sense to me. That would mean that Python 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!). 2.6.1 only two months after 2.6? Why so quickly? Anyway, I don't see any added value in the synchronization, so taking in consideration all the effort you're putting in these releases, I would just want to minimize your workload... which is easier to you? doing both at the same time or not? There have been several corrections made to the 2to3 conversion tool - it would be good to get those in developer's hands at the same time that 3.0 final becomes available. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Le Tuesday 18 November 2008 11:03:02 Facundo Batista, vous avez écrit : 2008/11/17 Barry Warsaw [EMAIL PROTECTED]: Martin suggests, and I agree, that we should release Python 3.0 final and 2.6.1 at the same time. Makes sense to me. That would mean that Python 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!). 2.6.1 only two months after 2.6? Why so quickly? Release Early, Release Often? I love release :-) I don't like waiting months to see the bugfixes applied everywhere. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 18, 2008, at 5:03 AM, Facundo Batista wrote: 2008/11/17 Barry Warsaw [EMAIL PROTECTED]: Martin suggests, and I agree, that we should release Python 3.0 final and 2.6.1 at the same time. Makes sense to me. That would mean that Python 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!). 2.6.1 only two months after 2.6? Why so quickly? Actually, I've wanted to do timed releases, though I think monthly is unrealistic. Maybe every two months is about the right time frame. Timed releases are nice because everybody then knows when a patch is due, from developers to downstream consumers. Anyway, I don't see any added value in the synchronization, so taking in consideration all the effort you're putting in these releases, I would just want to minimize your workload... which is easier to you? doing both at the same time or not? We're getting releases down to a science now! :) Actually the most painful part is updating the web site, so I plan adding some automation around that process too. OTOH, this is the first point release I'll be doing with the new script, so it'll be interesting to debug that process. As for synchronization, I think it's a good habit to get into, if my plan to do timed releases works out. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSSLShXEjvBPtnXfVAQL90QP/UfWRXr0esTim+DtQJs9Fd/+Lj9PpuBV6 UCB7pAwl8uf7qIAwjDkCsdg3VD/wxzmzuwDAB8T19PF5dNxsrKWdBEzhymVpLU8T cch0Vlaevm6Co/kDp8VhyoKlPs7LDhGkC2G04qDSOETo8Ci84rBOlWd7n1KvUrYZ 01Pn6eZHdqA= =k9FS -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 18, 2008, at 8:07 AM, Christian Heimes wrote: Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin suggests, and I agree, that we should release Python 3.0 final and 2.6.1 at the same time. Makes sense to me. That would mean that Python 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!). Should we release 2.6.1rc1, too? Do we need rc's for point releases? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSSLSyHEjvBPtnXfVAQJuMAP/cv59kjeFz5DxMk1hMrwXdNQvSs5Ge0lZ ICC4DeKmz0gXZ0+PoZc4Yi9HBAQ8g7ZfKptzIPnEUrg65wV8KS6OzcK5KX5aptvF Mqi+cmD3TPImsOEGoPnJUtlUZ7ZETrY2LSzdIIFqIE5yO1HBt3ohBcdM95+V2zQl zt0uV+F4fnw= =7N3R -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Barry Warsaw schrieb: On Nov 18, 2008, at 8:07 AM, Christian Heimes wrote: Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin suggests, and I agree, that we should release Python 3.0 final and 2.6.1 at the same time. Makes sense to me. That would mean that Python 2.6.1 should be ready on 03-Dec (well, if Python 3.0 is ready then!). Should we release 2.6.1rc1, too? Do we need rc's for point releases? I think we did them in the past. There probably never was a significant change between the rc and the final, but Murphy dictates that once you stop doing the rc, the final will be embarrassingly broken :) cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
From my point of view bi-monthly release are too much. For a ?.?.1 release two months are fine because several issues are found by 3rd party authors. But after that a release every quarter is sufficient. * .1 release two months after the .0 release * .2, .3, .4 and .5 release every quarter * about here the next minor release gets out * .6 and further releases after 6 months when necessary In the past, we had been striving for releases every 6 month. This was already very difficult to achieve. While I'm happy that Barry has automated his part to a high degree, my part is, unfortunately, much less automated. I could personally automate the build process a bit more, but part of it is also testing of the installers, which is manual. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Martin v. Löwis writes: While I'm happy that Barry has automated his part to a high degree, my part is, unfortunately, much less automated. I could personally automate the build process a bit more, but part of it is also testing of the installers, which is manual. Maybe you could delegate a lot of the testing to competent volunteers? That would be probably 2 times as much work the first couple of times, (you'd need to formalize your script for testing[1] and then check that the volunteers are understanding it correctly, etc) but if they are reliable you could turn that around a lot faster in the future. Footnotes: [1] Doesn't Windows have a way to send synthetic GUI events to a program? There ought to be a way to really script that, as the Python installer process presumbly doesn't change much from release to release. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
On Tue, Nov 18, 2008 at 11:55 PM, Stephen J. Turnbull [EMAIL PROTECTED] wrote: Footnotes: [1] Doesn't Windows have a way to send synthetic GUI events to a program? There ought to be a way to really script that, as the Python installer process presumbly doesn't change much from release to release. There's at least PyWinAuto[1], Watsup[2] and winGuiAuto[3]. [1] http://pywinauto.seleniumhq.org/ [2] http://www.tizmoi.net/watsup/intro.html [3] http://www.brunningonline.net/simon/blog/archives/winGuiAuto.py.html -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
While I'm happy that Barry has automated his part to a high degree, my part is, unfortunately, much less automated. I could personally automate the build process a bit more, but part of it is also testing of the installers, which is manual. Maybe you could delegate a lot of the testing to competent volunteers? That's not the issue - I don't mind spending that time. However, it means that several hours pass between starting the release process, and making the binaries available - during this time, users always complain why the Windows binaries are not released yet. With additional volunteers, availability of the binaries would lag even more behind the release announcement. [1] Doesn't Windows have a way to send synthetic GUI events to a program? There ought to be a way to really script that, as the Python installer process presumbly doesn't change much from release to release. I also need to involve different machines, e.g. XP machines and Vista machines, and machines that have Visual Studio installed and machines that don't. Plus, I need to log into each machine in different ways: as admin user and non-admin user. The automated GUI testing only really works for a logged-in user. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Martin v. Löwis writes: That's not the issue - I don't mind spending that time. However, it means that several hours pass between starting the release process, and making the binaries available - during this time, users always complain why the Windows binaries are not released yet. For several hours delay? Shame on the complainers! Ubuntu and MacPorts users have to wait days or weeks for installers. Debian stable users, years!wink My understanding was that the biggest problem with keeping to a 6-month cycle has always been that it's still a long enough time frame that people will rush to get an 80%-done project into the release just before deadline, causing extra reviewing effort for the senior committers and effort and delays for everyone for bug fixing. One month is probably short enough that people will be willing to submit things at a more appropriate stage in development. Still, it's the review and polishing-up effort that is the bottleneck, it seems to me. Not the installers. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
