[Python-3000] 2.6.1 and 3.0
Barry Warsaw
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!).
I'm still planning the last Python 3.0 release candidate for this
Wednesday.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSSIgu3EjvBPtnXfVAQKzGgP/XH2szIZdG9nvZTI2M9iWXuz/tBwH6ncd
Kv70ATpttQEg/bmuRp5nSmg1p7hxSmTqu9waq4qdc07IPa+ofTngbunUKkTrbZoo
E/r72dGw29pou7B6NVh/g5Db8Tl0yNJBd6vmpEUbCvUDBpljqgxCdj0uw/RiDluj
5Ek2biim7ww=
=twyi
-----END PGP SIGNATURE-----
_______________________________________________
Python-3000 mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: http://mail.python.org/mailman/options/python-3000/python-3000-garchive-63646%40googlegroups.com
Facundo Batista
> 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/
Nick Coghlan
> 2008/11/17 Barry Warsaw <ba...@python.org>:
>
>> 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 | ncog...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
Victor Stinner
> 2008/11/17 Barry Warsaw <ba...@python.org>:
> > 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
Christian Heimes
> -----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?
Christian
Barry Warsaw
Hash: SHA1
On Nov 18, 2008, at 5:03 AM, Facundo Batista wrote:
> 2008/11/17 Barry Warsaw <ba...@python.org>:
>
>> 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-----
Barry Warsaw
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-----
Christian Heimes
> 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.
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
Christian
"Martin v. Löwis"
>
> 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
"Martin v. Löwis"
> 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
Stephen J. Turnbull
> 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.
"Martin v. Löwis"
> > 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
Stephen J. Turnbull
> 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.
Facundo Batista
> 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
Michael Foord
>> > 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
> Pytho...@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/
Sidnei da Silva
<ste...@xemacs.org> 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
Stephen J. Turnbull
> 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!
Barry Warsaw
Hash: SHA1
On Nov 18, 2008, at 9:52 AM, Christian Heimes wrote:
> Barry Warsaw wrote:
>> 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.
>
> 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
Timed releases have a lot of advantages, and I would like to see if we
can adopt them and realize these benefits. What I like most about
them is that everyone knows what's happening when and can coordinate
efforts. Developers will know automatically (no reminders or alarms)
when the next release is happening, so they can schedule what they
want to do more easily. Release experts can block out the appropriate
time on their schedules and plan more efficiently. Downstream
consumers have a better idea of when updates are available and can
lobby for certain critical bugs to be fixed in a timely and
predictable manner.
I think 6 months is too long between releases -- it might as well not
be timed. It sounds like the Windows side is a bit of a pain, and
since we're all busy, one month is probably too soon. That's why I
proposed bi-monthly.
I really want our releases to be predictable. I don't think we have
to worry about nothing getting committed to the trees in 2 months time.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSSQspHEjvBPtnXfVAQIfwwP8DzaIge8b1rL9/zACiwZ5nOn9S5d+ng+p
zjSSvDKgfxX5kEMfUQQuJgI6GIOPvUm0wsmdZnH5f5AD86/1Qz1ugsBkHXO6BWWl
LEI2jNjsIU9m1icQkQSnENxJoI5BFFA9upewT1zwo9md4cErzQLiK+WQrblu1hXE
GKaxW0Xrva4=
=ZI9e
-----END PGP SIGNATURE-----
Barry Warsaw
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 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 :)
True. If the rc's are actually tested and help avoid embarrassment
I'm all for them. If it's just extra work that few will test, then
let's skip them and just do brown bag releases if necessary.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSSQuGHEjvBPtnXfVAQJCfwQAky+ORhR0LaoZ0nevGBkEkl5LZbP0+A4a
p0puGCnxuY6DVqx38dJUPLqt+wle+Zw9QX4PhhaalbTWyOQScKQk0p0CxagLnTeG
GvlyTQLUM9RxFzolnzcY8mU8ewGnCJp16d7TR40AmMZ/geV/xMDzxL+tPKwiq/5p
C4j+VmFHnMU=
=EGqf
Barry Warsaw
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-----
Steve Holden
>> > 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.
>
available? It's not like Beaujolais Nouveau, with people racing to be
the first to get a new release installed. Particularly since the final
release is usually just the re-tagged release candidate.
Or are the complainers Python developers who know what goes on behind
the scenes?
> 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? I
ask this in hopes that you aren't a potential single point of failure in
the release process.
...]
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
"Martin v. Löwis"
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
"Martin v. Löwis"
> 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
"Martin v. Löwis"
> 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
"Martin v. Löwis"
> 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?
"Martin v. Löwis"
> 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
Barry Warsaw
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-----
Barry Warsaw
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 nooooo rc4!
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSScZWXEjvBPtnXfVAQKpQAQAi9Q8rfgcCVXmQ2tIqaiAVKOQHDPQdfhF
lyDWHg+6i2EGrbs0Jju5GB9YML1yNga3X85zfQSedu6mgpA4dV6NvW988N3Wp4oG
ztDGT7yLxwYe4Wy606FF6lxSlXSvXQRLc/Nf1qgn8dDGskQKO2LZ+fUHW0BIWDBN
RFAuZqzdWQY=
=9Z8w
Giovanni Bajo
> 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 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, and Python's needs
do not seem so weird to require a custom MSI generator. I'm sure the
Python Software Foundation would easily get a free license of one of the
good commercial MSI installer generators.
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.
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com
"Martin v. Löwis"
> 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
Elliot Murphy
>> 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:
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/
"Martin v. Löwis"
> 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.
"Martin v. Löwis"
> 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).
Michael Foord
>> 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.
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
> Pytho...@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
Joseph Armbruster
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?
Regards,
Martin
_______________________________________________
"Martin v. Löwis"
> http://www.advancedinstaller.com/feats-list.html
So how much effort would it be to create a Python installer?
Could you kindly provide one?
Giovanni Bajo
> > 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
Christian Heimes
> 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
"Martin v. Löwis"
> 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
Giovanni Bajo
> > 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
Giovanni Bajo
> > 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
"Martin v. Löwis"
> 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 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.
Regards,
Martin
"Martin v. Löwis"
> 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
Giovanni Bajo
> > 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
"Martin v. Löwis"
> 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
Gregory P. Smith
-gps
Pytho...@python.org
Regards,
Martin
_______________________________________________
Python-Dev mailing list
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
Suraj Barkale
>
> 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
> >
>
> 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.
>
I would suggest using WiX Toolset (http://wix.sourceforge.net/) as it is open
source and supports almost all features of "Advanced Installer". AFAIK the
Visual Studio & MS Office teams use WiX for their installers. It also relies on
XML files to specify the MSI content.
Regards,
Suraj