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. Regard
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
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 o
> 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
> insta
> 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.
> Another
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
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 us
> 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
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:
h
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://ww
> 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.
> 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 -
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 w
> 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
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
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
> 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
>
-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
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/pyt
> 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 wh
> 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 - typicall
-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
> 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
> announce
> 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
> 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 majorit
-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 suffi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 18, 2008, at 12:46 PM, Georg Brandl wrote:
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 P
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 impressiv
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 dele
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 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.
> > 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
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 t
"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 de
> 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 qua
>> Should we release 2.6.1rc1, too?
>
> Do we need rc's for point releases?
We have been doing them in the past, a week before the release.
In this case, I could accept a waiver, given that the previous
release acts very well as a release candidate for this release.
Regards,
Martin
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
-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 wou
-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
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
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!).
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
42 matches
Mail list logo
