Hi,
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
.tgz - 13 MB .tar.bz2 - 11 MB .tar.xz - 8.6 MB
Georg
-On [20101205 12:19], Georg Brandl (g.brandl@gmx.net) wrote:
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
Given that xz is only provided since GNU Coreutils 7.1 and only in some newer BSD releases (if at all, I know FreeBSD 8 at least has it in the base, no idea about pkgsrc and such), I'd say you might want to provide tgz and tbz2 for another year before really stopping to provide other formats.
I mean, seriously, is providing some extra files in a particular compression format the biggest of our problems?
-- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The only trust in this world is that of steel...
Am 05.12.2010 13:33, schrieb Jeroen Ruigrok van der Werven:
-On [20101205 12:19], Georg Brandl (g.brandl@gmx.net) wrote:
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
Given that xz is only provided since GNU Coreutils 7.1 and only in some newer BSD releases (if at all, I know FreeBSD 8 at least has it in the base, no idea about pkgsrc and such), I'd say you might want to provide tgz and tbz2 for another year before really stopping to provide other formats.
That's why I said "in addition to".
I mean, seriously, is providing some extra files in a particular compression format the biggest of our problems?
It was just a thought I had while I watched the files upload through my rather slow link. I promise I won't disturb you again tackling our real big problems.
Georg
-On [20101205 13:58], Georg Brandl (g.brandl@gmx.net) wrote:
That's why I said "in addition to".
My mistake, read over that.
It was just a thought I had while I watched the files upload through my rather slow link. I promise I won't disturb you again tackling our real big problems.
There's no need to feel offended or attacked, since my response was not meant as such. My apologies if you felt it as such.
I just wondered why, in light of my having missed the "in addition to", we would need to move to xz only, given that disk space is relatively cheap as opposed to the real code, et cetera.
-- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Ain't gonna spend the rest of my Life, quietly fading away...
On Sun, Dec 5, 2010 at 14:58, Jeroen Ruigrok van der Werven <asmodai@in-nomine.org> wrote:
I just wondered why, in light of my having missed the "in addition to", we would need to move to xz only, given that disk space is relatively cheap as opposed to the real code, et cetera.
Because bandwidth is much more expensive than disk space?
Cheers,
Dirkjan
Am 05.12.2010 14:58, schrieb Jeroen Ruigrok van der Werven:
-On [20101205 13:58], Georg Brandl (g.brandl@gmx.net) wrote:
That's why I said "in addition to".
My mistake, read over that.
It was just a thought I had while I watched the files upload through my rather slow link. I promise I won't disturb you again tackling our real big problems.
There's no need to feel offended or attacked, since my response was not meant as such. My apologies if you felt it as such.
Yes, I know and I'm sorry for the harsh tone. It's just that when you're in the middle of doing a release, a perceived complaint that you're doing nothing of real worth feels a bit strange :)
Georg
-On [20101205 20:23], "Martin v. Löwis" (martin@v.loewis.de) wrote:
For those of us involved in the release process, every single file is a big problem, indeed. Seriously.
Correct me if wrong, but isn't rolling up a tgz, tbz2, or txz not a matter of repeating the same actions on a tarball you already have, namely merely compressing the resulting tarball that you already have. Easy enough to script/put in a Makefile.
Which only leaves generating hashes/sig files, uploading, and linking it on the site. All of which can be automated to a high degree.
So what exactly is the big problem here then?
-- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The fragrance always stays in the hand that gives the rose...
Am 05.12.2010 20:40, schrieb Jeroen Ruigrok van der Werven:
-On [20101205 20:23], "Martin v. Löwis" (martin@v.loewis.de) wrote:
For those of us involved in the release process, every single file is a big problem, indeed. Seriously.
Correct me if wrong, but isn't rolling up a tgz, tbz2, or txz not a matter of repeating the same actions on a tarball you already have, namely merely compressing the resulting tarball that you already have. Easy enough to script/put in a Makefile.
Which only leaves generating hashes/sig files, uploading, and linking it on the site. All of which can be automated to a high degree.
So what exactly is the big problem here then?
One problem is that it is not automated (at least not when I do it, nor is the creation of the release page automated).
The next problem is that, with so many files, it becomes just not feasible to test them all. As a consequence, you risk releasing broken files. For example, when Benjamin released both 2.7.1 and 3.1.3 on the same day, I had to produce 16 files. I lost track of what files where in what state, and broke some of them. I didn't test all installers I built.
The last problem is that the release page gets cluttered, confusing users as to what file they need to download for what purpose.
Regards, Martin
Le dimanche 05 décembre 2010 à 12:16 +0100, Georg Brandl a écrit :
Hi,
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
.tgz - 13 MB .tar.bz2 - 11 MB .tar.xz - 8.6 MB
It is likely that many non-GNU based platforms, such as commercial Unices, don't know about xz yet (not to mention old Debian / RHEL machines). So I would vote to continue providing .tar.bz2 and/or .tgz tarballs.
Regards
Antoine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/12/10 15:15, Antoine Pitrou wrote:
Le dimanche 05 décembre 2010 à 12:16 +0100, Georg Brandl a écrit :
Hi,
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
.tgz - 13 MB .tar.bz2 - 11 MB .tar.xz - 8.6 MB
It is likely that many non-GNU based platforms, such as commercial Unices, don't know about xz yet (not to mention old Debian / RHEL machines). So I would vote to continue providing .tar.bz2 and/or .tgz tarballs.
Providing XZ files *IN ADDITION* to gz/bz2 will increase the mindshare for the format. I am checking the webpage and installing the XZ tools just now :-).
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBTP4U7Zlgi5GaxT1NAQK0NAP+KCij3y/m5O8a9wioP2atPDjn8DFwWxxv 2uMQKBCQikGiVS5LRF6gE11jvJMRBnmaW6RI7HylP/WM7/KtGKx6Fl4MjRzzqKvQ yyk+vY1+RfQ5Oc1Q7vLTLKGTibSXUY59jfQo2I09nCXpkeMYSu4iuz7SSDPS/QUR b9eH+YhexgU= =j2ys -----END PGP SIGNATURE-----
On 07/12/2010 11:05, Jesus Cea wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/12/10 15:15, Antoine Pitrou wrote:
Le dimanche 05 décembre 2010 à 12:16 +0100, Georg Brandl a écrit :
Hi,
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
.tgz - 13 MB .tar.bz2 - 11 MB .tar.xz - 8.6 MB It is likely that many non-GNU based platforms, such as commercial Unices, don't know about xz yet (not to mention old Debian / RHEL machines). So I would vote to continue providing .tar.bz2 and/or .tgz tarballs. Providing XZ files *IN ADDITION* to gz/bz2 will increase the mindshare for the format. I am checking the webpage and installing the XZ tools just now :-).
That's not *our* job though.
Michael
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBTP4U7Zlgi5GaxT1NAQK0NAP+KCij3y/m5O8a9wioP2atPDjn8DFwWxxv 2uMQKBCQikGiVS5LRF6gE11jvJMRBnmaW6RI7HylP/WM7/KtGKx6Fl4MjRzzqKvQ yyk+vY1+RfQ5Oc1Q7vLTLKGTibSXUY59jfQo2I09nCXpkeMYSu4iuz7SSDPS/QUR b9eH+YhexgU= =j2ys -----END PGP SIGNATURE-----
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
--
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Sun, Dec 05, 2010 at 12:16:48PM +0100, Georg Brandl wrote:
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs.
Yes, it is necessary. People sometimes just expect it from an Open Source project. (At least, when someone is going to try it for the first time)
If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
+1.
I personally, have not downloaded any .xz compressed file yet. So, I would be curious to know about this new format, and if I see Python being provided in a such a novel format, I would be bit excited to try it too. :)
-- Senthil
Am 05.12.2010 16:56, schrieb Senthil Kumaran:
On Sun, Dec 05, 2010 at 12:16:48PM +0100, Georg Brandl wrote:
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs.
Yes, it is necessary. People sometimes just expect it from an Open Source project. (At least, when someone is going to try it for the first time)
Okay, I give up -- there seems to be a conspiracy of misunderstanding today :)
Georg
2010/12/5 Georg Brandl <g.brandl@gmx.net>:
Hi,
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
.tgz - 13 MB .tar.bz2 - 11 MB .tar.xz - 8.6 MB
tgz (and zip) are the most portable formats available, though. What does the site stats say about current usage?
(btw, someone mentioned bandwidth -- are we paying for bandwidth? what fraction of the python.org traffic is downloads?)
</F>
On Sun, Dec 5, 2010 at 12:02 PM, Fredrik Lundh <fredrik@pythonware.com> wrote:
(btw, someone mentioned bandwidth -- are we paying for bandwidth? what fraction of the python.org traffic is downloads?)
Even if the PSF isn't paying for bandwidth (and I don't know either way), users on the other end often are. This is understandable and real concern.
If providing this new format helps them, I'd be all for that.
-Fred
-- Fred L. Drake, Jr. <fdrake at acm.org> "A storm broke loose in my mind." --Albert Einstein
2010/12/5 Fred Drake <fdrake@acm.org>:
On Sun, Dec 5, 2010 at 12:02 PM, Fredrik Lundh <fredrik@pythonware.com> wrote:
(btw, someone mentioned bandwidth -- are we paying for bandwidth? what fraction of the python.org traffic is downloads?)
Even if the PSF isn't paying for bandwidth (and I don't know either way), users on the other end often are. This is understandable and real concern.
If providing this new format helps them, I'd be all for that.
Sure, I don't mind adding a new format -- I'd like to see more metrics before I convince myself that removing the lowest common denominator format is a good idea, though.
(and the difference is one MP3 or a short YouTube clip, so I'm not sure how real this issue is...)
</F>
Georg Brandl wrote:
Hi,
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
.tgz - 13 MB .tar.bz2 - 11 MB .tar.xz - 8.6 MB
I've never heard of the .xz format before, but if it provides better compression, then why not add it to the available options.
I'd also suggest a .zip file source format as alternative to the above. This is more common on Windows platforms.
BTW: The download page says: """ * Python 3.1.3 compressed source tarball (for Linux, Unix or OS X) * Python 3.1.3 bzipped source tarball (for Linux, Unix or OS X, more compressed) """ This sounds like the source tarball is not the right source distribution for Windows platforms.
And then there's a general issue with the user experience for first-time users of Python: there's a quick install guide missing on the download page.
I'll open a ticket for that.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Dec 05 2010)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
Am 05.12.2010 19:16, schrieb M.-A. Lemburg:
Georg Brandl wrote:
Hi,
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
.tgz - 13 MB .tar.bz2 - 11 MB .tar.xz - 8.6 MB
I've never heard of the .xz format before, but if it provides better compression, then why not add it to the available options.
Yes, I think it's best to just add it for now. I may do that for future 3.2 releases.
I'd also suggest a .zip file source format as alternative to the above. This is more common on Windows platforms.
BTW: The download page says: """ * Python 3.1.3 compressed source tarball (for Linux, Unix or OS X) * Python 3.1.3 bzipped source tarball (for Linux, Unix or OS X, more compressed) """ This sounds like the source tarball is not the right source distribution for Windows platforms.
Basically, it is good for all platforms, but most line-endings will be Unix line-endings in these files. Providing a .zip file with Windows line endings needs one more export/archive step from the source repo.
And then there's a general issue with the user experience for first-time users of Python: there's a quick install guide missing on the download page.
Not sure that is needed: those who download the installers will know what to do with them, and those who download the source should also know (otherwise README has a quick build and install section.)
Georg
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
Looking at download statistics, for the 2.7 release, in July, we had these numbers of downloads:
Python-2.7.tgz 32059 Python-2.7.tar.bz2 24986 python-2.7.msi 577240
In November, the numbers were
Python-2.7.tgz 24535 Python-2.7.tar.bz2 20797 python-2.7.msi 569328
Regards, Martin
Am 05.12.2010 20:39, schrieb "Martin v. Löwis":
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
Looking at download statistics, for the 2.7 release, in July, we had these numbers of downloads:
Python-2.7.tgz 32059 Python-2.7.tar.bz2 24986 python-2.7.msi 577240
In November, the numbers were
Python-2.7.tgz 24535 Python-2.7.tar.bz2 20797 python-2.7.msi 569328
OK, so the tgz is still more popular than the bz2 one, and that means it shouldn't go away.
I've decided to make tar.xz tarballs available for the remaining 3.2 prereleases; we'll see if anyone at all is interested in them.
As for the .zip version, I've not found any requests for a source download with Windows-specific newlines. I suppose that developers either check out directly from SVN, or have decompression programs and editors that can cope.
cheers, Georg
As for the .zip version, I've not found any requests for a source download with Windows-specific newlines. I suppose that developers either check out directly from SVN, or have decompression programs and editors that can cope.
Indeed, Windows users should be able to cope with the tgz just fine. Per svn:eol-style, the files that need to be CRLF are marked so, and should remain usable even with a Unix export. The C and Python files will have LF only, which VS and Python can deal with just fine. Only notepad would do nonsense when trying to open such a file.
Regards, Martin
On Sun, Dec 5, 2010 at 11:43, Georg Brandl <g.brandl@gmx.net> wrote:
Am 05.12.2010 20:39, schrieb "Martin v. Löwis":
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
Looking at download statistics, for the 2.7 release, in July, we had these numbers of downloads:
Python-2.7.tgz 32059 Python-2.7.tar.bz2 24986 python-2.7.msi 577240
In November, the numbers were
Python-2.7.tgz 24535 Python-2.7.tar.bz2 20797 python-2.7.msi 569328
OK, so the tgz is still more popular than the bz2 one, and that means it shouldn't go away.
Well, is it more popular because that is just what people are used to downloading or the first download link on the web page? Or is it because people fundamentally prefer tgz files over tar.bz2? Are there actual platforms that can't handle tar.bz2 but can handle tgz? I'm willing to bet it's because of the download link order and has nothing to do with actual preference (especially since we don't state file size on the download page).
Personally I don't know why we have both tgz and tar.bz2 other than tradition. I say trim it down to tar.bz2 for portability and move on to using a ustar-based tar.xz to be cutting edge and minimize download size overall while making it the first download option to make sure people notice it. I'd also vote for listing the file size on the download page, but that's just another step for release managers that I don't want to burden them with.
-Brett
I've decided to make tar.xz tarballs available for the remaining 3.2 prereleases; we'll see if anyone at all is interested in them.
As for the .zip version, I've not found any requests for a source download with Windows-specific newlines. I suppose that developers either check out directly from SVN, or have decompression programs and editors that can cope.
cheers, Georg
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Well, is it more popular because that is just what people are used to downloading or the first download link on the web page? Or is it because people fundamentally prefer tgz files over tar.bz2?
These questions are difficult to answer with the download stats alone. If you really want to know, we should setup a poll...
Are there actual platforms that can't handle tar.bz2 but can handle tgz?
That, in turn, is easy to answer: yes, there are. Certain Solaris releases had gzip available (even though /usr/bin/tar wouldn't know how to invoke it), but no bzip2 utility.
I'm willing to bet it's because of the download link order and has nothing to do with actual preference (especially since we don't state file size on the download page).
Not sure what page you are looking at; on
http://www.python.org/download/releases/2.7/
we do.
Personally I don't know why we have both tgz and tar.bz2 other than tradition. I say trim it down to tar.bz2 for portability and move on to using a ustar-based tar.xz to be cutting edge and minimize download size overall while making it the first download option to make sure people notice it. I'd also vote for listing the file size on the download page, but that's just another step for release managers that I don't want to burden them with.
You would also need to specify what page you refer to as "the download page".
Regards, Martin
On Sun, Dec 5, 2010 at 13:06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Well, is it more popular because that is just what people are used to downloading or the first download link on the web page? Or is it because people fundamentally prefer tgz files over tar.bz2?
These questions are difficult to answer with the download stats alone. If you really want to know, we should setup a poll...
I could if people care, but I don't anyone does.
Are there actual platforms that can't handle tar.bz2 but can handle tgz?
That, in turn, is easy to answer: yes, there are. Certain Solaris releases had gzip available (even though /usr/bin/tar wouldn't know how to invoke it), but no bzip2 utility.
If these are Solaris platforms we support then that's fine and we should keep tgz files, but if these are platforms we no longer care about then I say the lives of release managers should be simplified by cutting tgz files.
I'm willing to bet it's because of the download link order and has nothing to do with actual preference (especially since we don't state file size on the download page).
Not sure what page you are looking at; on
http://www.python.org/download/releases/2.7/
we do.
I was actually looking at that page, but the size specifics are below the download links and are only noticeable if you scroll far enough down. I doubt I am the only person who has made that mistake.
-Brett
Personally I don't know why we have both tgz and tar.bz2 other than tradition. I say trim it down to tar.bz2 for portability and move on to using a ustar-based tar.xz to be cutting edge and minimize download size overall while making it the first download option to make sure people notice it. I'd also vote for listing the file size on the download page, but that's just another step for release managers that I don't want to burden them with.
You would also need to specify what page you refer to as "the download page".
Regards, Martin
That, in turn, is easy to answer: yes, there are. Certain Solaris releases had gzip available (even though /usr/bin/tar wouldn't know how to invoke it), but no bzip2 utility.
If these are Solaris platforms we support then that's fine and we should keep tgz files, but if these are platforms we no longer care about then I say the lives of release managers should be simplified by cutting tgz files.
We haven't been really careful in determining what Solaris releases we support; PEP 11 lists no Solaris releases that are not supported anymore. I'd say anything since Solaris 9 (released 2002) needs to be supported. Unfortunately, I don't have any installation of that anymore, so I'm not sure whether it had bzip2 - I doubt it, but it is certainly possible to obtain a bzip2 binary from SunFreeware (or build it yourself from source).
Regards, Martin
Le dimanche 05 décembre 2010 à 13:11 -0800, Brett Cannon a écrit :
If these are Solaris platforms we support then that's fine and we should keep tgz files, but if these are platforms we no longer care about then I say the lives of release managers should be simplified by cutting tgz files.
I think we should actually cut bz2 files. Leave tgz for legacy platforms and users, and provide xz for much better compression.
(by the way, using GNU tar you don't have to specify the compression mode anymore: just do "tar xf ..." or "tar tf ..." and it will be autodetected)
Regards
Antoine.
On 12/5/2010 10:11 PM, Brett Cannon wrote:
On Sun, Dec 5, 2010 at 13:06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Well, is it more popular because that is just what people are used to downloading or the first download link on the web page? Or is it because people fundamentally prefer tgz files over tar.bz2?
These questions are difficult to answer with the download stats alone. If you really want to know, we should setup a poll...
I could if people care, but I don't anyone does.
Are there actual platforms that can't handle tar.bz2 but can handle tgz?
That, in turn, is easy to answer: yes, there are. Certain Solaris releases had gzip available (even though /usr/bin/tar wouldn't know how to invoke it), but no bzip2 utility.
If these are Solaris platforms we support then that's fine and we should keep tgz files, but if these are platforms we no longer care about then I say the lives of release managers should be simplified by cutting tgz files.
I'm willing to bet it's because of the download link order and has nothing to do with actual preference (especially since we don't state file size on the download page).
Not sure what page you are looking at; on
http://www.python.org/download/releases/2.7/
we do.
I was actually looking at that page, but the size specifics are below the download links and are only noticeable if you scroll far enough down. I doubt I am the only person who has made that mistake.
-Brett
Personally I don't know why we have both tgz and tar.bz2 other than tradition. I say trim it down to tar.bz2 for portability and move on to using a ustar-based tar.xz to be cutting edge and minimize download size overall while making it the first download option to make sure people notice it. I'd also vote for listing the file size on the download page, but that's just another step for release managers that I don't want to burden them with.
You would also need to specify what page you refer to as "the download page".
Surely this is all bike shedding. Will anyone fail to download Python because we don't offer a .xz foramt download? I sincerely doubt it. So what do we gain by such an addition to compensate for the increasing complexity to be faced during releases?
regards Steve
Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon 2011 Atlanta March 9-17 http://us.pycon.org/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On Sun, Dec 5, 2010 at 22:24, Steve Holden <steve@holdenweb.com> wrote:
On 12/5/2010 10:11 PM, Brett Cannon wrote:
On Sun, Dec 5, 2010 at 13:06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Well, is it more popular because that is just what people are used to downloading or the first download link on the web page? Or is it because people fundamentally prefer tgz files over tar.bz2?
These questions are difficult to answer with the download stats alone. If you really want to know, we should setup a poll...
I could if people care, but I don't anyone does.
Are there actual platforms that can't handle tar.bz2 but can handle tgz?
That, in turn, is easy to answer: yes, there are. Certain Solaris releases had gzip available (even though /usr/bin/tar wouldn't know how to invoke it), but no bzip2 utility.
If these are Solaris platforms we support then that's fine and we should keep tgz files, but if these are platforms we no longer care about then I say the lives of release managers should be simplified by cutting tgz files.
I'm willing to bet it's because of the download link order and has nothing to do with actual preference (especially since we don't state file size on the download page).
Not sure what page you are looking at; on
http://www.python.org/download/releases/2.7/
we do.
I was actually looking at that page, but the size specifics are below the download links and are only noticeable if you scroll far enough down. I doubt I am the only person who has made that mistake.
-Brett
Personally I don't know why we have both tgz and tar.bz2 other than tradition. I say trim it down to tar.bz2 for portability and move on to using a ustar-based tar.xz to be cutting edge and minimize download size overall while making it the first download option to make sure people notice it. I'd also vote for listing the file size on the download page, but that's just another step for release managers that I don't want to burden them with.
You would also need to specify what page you refer to as "the download page".
Surely this is all bike shedding.
I don't think so when we are trying to make getting a new release easier w.r.t. smaller source download.
Will anyone fail to download Python because we don't offer a .xz foramt download? I sincerely doubt it.
I do as well.
So what do we gain by such an addition to compensate for the increasing complexity to be faced during releases?
It only increases complexity if we don't cut one of the tar.bz2 or tgz source releases. But by offering a a tar.xz file we can give people a smaller download which saves everyone time and bandwidth which can matter if the downloader's Internet connection is slow and/or costly.
-Brett
regards Steve
Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon 2011 Atlanta March 9-17 http://us.pycon.org/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On Dec 05, 2010, at 11:15 PM, Brett Cannon wrote:
It only increases complexity if we don't cut one of the tar.bz2 or tgz source releases. But by offering a a tar.xz file we can give people a smaller download which saves everyone time and bandwidth which can matter if the downloader's Internet connection is slow and/or costly.
I mildly wonder about download scripts out there that have baked-in assumptions about the files that are available. It's not actually that hard to predict the url of a download file for a new release.
I can't imagine *adding* a download format is that much more complex, except perhaps for our users to try to figure out which file to grab, and even that's stretching it I think. But I would be okay with adding an .xz download for 3.2 and then re-evaluating the offerings for 3.3. It would be an interesting experiment to see how many .xz downloads we get (I hadn't even heard of the format until now).
-Barry
Am 06.12.2010 13:24, schrieb Barry Warsaw:
On Dec 05, 2010, at 11:15 PM, Brett Cannon wrote:
It only increases complexity if we don't cut one of the tar.bz2 or tgz source releases. But by offering a a tar.xz file we can give people a smaller download which saves everyone time and bandwidth which can matter if the downloader's Internet connection is slow and/or costly.
I mildly wonder about download scripts out there that have baked-in assumptions about the files that are available. It's not actually that hard to predict the url of a download file for a new release.
I can't imagine *adding* a download format is that much more complex, except perhaps for our users to try to figure out which file to grab, and even that's stretching it I think. But I would be okay with adding an .xz download for 3.2 and then re-evaluating the offerings for 3.3. It would be an interesting experiment to see how many .xz downloads we get (I hadn't even heard of the format until now).
One thing to consider is that distributions such as Gentoo will certainly switch to using the .xz, but mirror it. So even if it doesn't show up as a large download count on python.org, every user of these distributions can profit from the reduced download size.
Georg
Am 06.12.2010 13:24, schrieb Barry Warsaw:
I can't imagine *adding* a download format is that much more complex, except perhaps for our users to try to figure out which file to grab, and even that's stretching it I think. But I would be okay with adding an .xz download for 3.2 and then re-evaluating the offerings for 3.3. It would be an interesting experiment to see how many .xz downloads we get (I hadn't even heard of the format until now).
I like this idea. And, based on Brett's intuition, I would make the bzip2 link be the first. That alone could easily change the usage statistics in favor of bzip2.
Best regards, Łukasz
On Dec 5, 2010, at 9:55 PM, Brett Cannon wrote:
Well, is it more popular because that is just what people are used to downloading or the first download link on the web page? Or is it because people fundamentally prefer tgz files over tar.bz2?
I prefer tgz over tar.bz2 because my fingers are more used to typing gz* than bz*, and because it's more likely that gzip will be installed than bzip. But my habits were formed before bzip was even available.
I have chosen bzip over gzip in cases where I know that download bandwidth was limited but otherwise I use gzip.
Plus, Python comes with a gzip module. ;)
Are there actual platforms that can't handle tar.bz2 but can handle tgz?
I can test this tomorrow when I visit my client and type "bzip" into a box there, but I think the answer is "yes." This is a 3-4 year old Linux box where I had to install a number of packages just to get it to state where I could compile Emacs 23.x, since their package installer doesn't have a new enough Emacs version.
Short version: most of the users log into the Linux box to run pre-compiled chemistry applications. They aren't doing development on the machines.
If Python was only available in bzip then I would have to install bzip myself - which isn't hard - while I grumble that it's more work for me for little savings. After all, in these cases I'm at a large pharmaceutical company with plenty of bandwidth, so the savings of a few MB won't be noticeable.
They sure aren't going to have xz.
So, drop .tar.gz and I can still handle it.
Personally I don't know why we have both tgz and tar.bz2 other than tradition. I say trim it down to tar.bz2 for portability and move on to using a ustar-based tar.xz to be cutting edge and minimize download size overall while making it the first download option to make sure people notice it.
While I would say to drop the bz2 and make it an xz instead. *shrug* it's no big deal either which way.
If this is something you want to figure out, there's no need for a poll. This is near ideal case for A/B testing. Swap the two lines now and see what changes. And watch the referrer logs to identify which downloads come from that page.
Before today I had never even heard of .xz files. For others who haven't heard of it, it's based on the LZMA2 algorithm, which is a slight improvement on the LZMA algorithm which 7zip uses. It's been for about 2 years, and so I'm surprised to see that it's part of the GNU coreutils already.
Here's a short read about the history http://linuxgazette.net/162/lindholm.html with some numbers as well. It looks like the compression time is a lot longer than gzip. This page http://stephane.lesimple.fr/wiki/blog/lzop_vs_compress_vs_gzip_vs_bzip2_vs_l... recommends gzip if you want compression speed, and xz if you want smaller size.
Andrew
dalke@dalkescientific.com2010/12/5 "Martin v. Löwis" <martin@v.loewis.de>:
I wonder if it's still necessary to provide .tar.bz2 and .tgz source tarballs. If anything, it would be nice to provide .tar.xz in addition to .tar.bz2, which has a nicer compression ratio:
Looking at download statistics, for the 2.7 release, in July, we had these numbers of downloads:
Python-2.7.tgz 32059 Python-2.7.tar.bz2 24986 python-2.7.msi 577240
In November, the numbers were
Python-2.7.tgz 24535 Python-2.7.tar.bz2 20797 python-2.7.msi 569328
So source tarballs are <10% of the downloads (not very surprising; I guess most people use binary package managers if they want a runtime, and SVN if they want source). Sounds like people who are concerned about overall bandwidth use should look at optimizing the installer size instead :)
</F>
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
participants (16)
-
"Martin v. Löwis" -
Andrew Dalke -
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Dirkjan Ochtman -
Fred Drake -
Fredrik Lundh -
Georg Brandl -
Jeroen Ruigrok van der Werven -
Jesus Cea -
M.-A. Lemburg -
Michael Foord -
Senthil Kumaran -
Steve Holden -
Łukasz Langa