From pje at telecommunity.com Mon Jun 6 00:22:48 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 05 Jun 2005 18:22:48 -0400
Subject: [Catalog-sig] EasyInstall 0.4a1: now with PyPI autodownload
Message-ID: <5.1.1.6.0.20050605180352.02208810@mail.telecommunity.com>
I've just released a new version of EasyInstall, that supports automatic
package location via PyPI; installing a package can now be as simple as:
easy_install "SQLObject>=0.6"
There are many new options and features related to this; see the
EasyInstall home page for more information:
http://peak.telecommunity.com/DevCenter/EasyInstall
For the benefit of the PyPI maintainers, here is a summary of EasyInstall's
fairly minimal assumptions about PyPI's current behavior, assuming that
"base-url" is the root URL of the package index:
* Going to "base-url/SomePackage" produces an HTML page that either has
a title containing "Index of Packages" and links to zero or more pages for
specific versions, or else it is a single-version package page.
* Single-version package pages may have a home page and download URL
link, each of which occurs after '<th>Home Page' and '<th>Download URL'
respectively, if present.
* Going to "base-url/" (note trailing '/') produces an HTML page
containing links to all active versions of registered packages
* Links to package pages always have URLs of the form
"base-url/SomePackage/itsVersion" - i.e., exactly two path parts following
the base URL, with no query strings, parameters, fragments, etc.
EasyInstall should continue to work with PyPI if these assumptions continue
to hold. However, I'd also like to suggest that PyPI deprecate the use of
spaces and other non-alphanumeric characters (other than '-') in package
names, and move to a case-insensitive matching mechanism for package
names. (Currently, if a user types a package name in the wrong case,
EasyInstall downloads the full package list in order to do its own
case-insensitive search.)
By the way, EasyInstall does not rely solely on the download URL of a PyPI
entry, nor does it assume that the download URL is in fact the URL where
the package's source distribution is found. Instead, EasyInstall inspects
the URLs for whether the extension suggests an egg or source
distribution. If not, it retrieves the listed URL, and if it contains
HTML, it scans the HTML for links to egg or source distributions (again
identified by extension). It does this for both the home page and the
download URL, in case there is a usable download link on the package's home
page.
This approach was chosen to maximise the odds of successful downloading,
given the current contents of PyPI.
From ehs at pobox.com Tue Jun 7 20:01:50 2005
From: ehs at pobox.com (Ed Summers)
Date: Tue, 7 Jun 2005 13:01:50 -0500
Subject: [Catalog-sig] pypi xmlrpc
In-Reply-To: <42A5C4F6.7040702@colorstudy.com>
References: <20050607155229.GA12698@wdfs.graniteweb.com>
<42A5C4F6.7040702@colorstudy.com>
Message-ID: <c1122f7454794bc47240845e4b2062fc@pobox.com>
I heard a rumor (on here i think) that there was some xmlrpc support
added to pypi at pycon2005. Is there any documentation on the functions
you can call and the urls? Is the code available for perusal in svn or
cvs?
//Ed
From ianb at colorstudy.com Tue Jun 7 20:09:12 2005
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 07 Jun 2005 13:09:12 -0500
Subject: [Catalog-sig] pypi xmlrpc
In-Reply-To: <c1122f7454794bc47240845e4b2062fc@pobox.com>
References: <20050607155229.GA12698@wdfs.graniteweb.com> <42A5C4F6.7040702@colorstudy.com>
<c1122f7454794bc47240845e4b2062fc@pobox.com>
Message-ID: <42A5E2C8.7020102@colorstudy.com>
Ed Summers wrote:
> I heard a rumor (on here i think) that there was some xmlrpc support
> added to pypi at pycon2005. Is there any documentation on the functions
> you can call and the urls? Is the code available for perusal in svn or
> cvs?
They added what we gave them, which wasn't much ;) Here's the functions
currently available:
def echo(store,*args):
return args
def index(store,*args):
spec = { }
return store.query_packages( spec )
def search(store,*args):
term = args[0]
spec = { 'name' : term, 'summary' : term }
return store.query_packages( spec, andor='or' )
Usage:
>>> import xmlrpclib
>>> pypi = xmlrpclib.ServerProxy('http://python.org/pypi')
>>> pypi.search('pypi')
({'info': ['pypi', '2004-03-01', 'PyPI is the Python Package Index at
http://www.python.org/pypi'], 'cols': ['name', 'version', 'summary'],
'cols_d': {'version': 1, 'name': 0, 'summary': 2}}, {'info': ['pypi',
'2004-03-02', 'PyPI is the Python Package Index at
http://www.python.org/pypi'], 'cols': ['name', 'version', 'summary'],
'cols_d': {'version': 1, 'name': 0, 'summary': 2}}, {'info': ['pypi',
'2004-06-21', 'PyPI is the Python Package Index at
http://www.python.org/pypi'], 'cols': ['name', 'version', 'summary'],
'cols_d': {'version': 1, 'name': 0, 'summary': 2}}, {'info': ['pypi',
'2004-06-23', 'PyPI is the Python Package Index at
http://www.python.org/pypi'], 'cols': ['name', 'version', 'summary'],
'cols_d': {'version': 1, 'name': 0, 'summary': 2}}, {'info': ['pypi',
'2004-07-14', 'PyPI is the Python Package Index at
http://www.python.org/pypi'], 'cols': ['name', 'version', 'summary'],
'cols_d': {'version': 1, 'name': 0, 'summary': 2}})
I proposed some new functions in an email a week or two ago.
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
From walter at livinglogic.de Fri Jun 10 20:26:11 2005
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 10 Jun 2005 20:26:11 +0200
Subject: [Catalog-sig] PyPI upload problem
Message-ID: <42A9DB43.1020704@livinglogic.de>
I'm having problems with uploading Windows installer files (i.e.
those generated by "python setup.py bdist --formats=wininst") to PyPI.
I'm uploading the file through the web interface (from the URL
http://www.python.org/pypi?:action=files&name=ll-xist&version=2.10) not
via "python setup.py upload".
I get the following error:
----
Error...
There's been a problem with your request
exceptions.NameError: global name 'safe_zipnames' is not defined
----
Please CC any replies to me, as I'm not on the list.
Bye,
Walter D?rwald
From mauriceling at acm.org Mon Jun 20 01:12:04 2005
From: mauriceling at acm.org (Maurice Ling)
Date: Mon, 20 Jun 2005 09:12:04 +1000
Subject: [Catalog-sig] Another project idea (oldie but a goodie)
In-Reply-To: <200506200805.24540.richardjones@optushome.com.au>
References: <200506191019.18552.richardjones@optushome.com.au>
<200506191055.42669.richardjones@optushome.com.au>
<42B4D4E1.30609@acm.org>
<200506200805.24540.richardjones@optushome.com.au>
Message-ID: <42B5FBC4.7090705@acm.org>
Richard Jones wrote:
>[this is possibly heading off-topic for this list. I suggest follow-up
>questions be posted to the catalog-sig]
>
>On Sun, 19 Jun 2005 12:13 pm, Maurice Ling wrote:
>
>
>>>>PyPI, to me, lacks that download-and-install tool I've been mentioning.
>>>>So, I'll be 150% glad to have my tool to fill that gap.
>>>>
>>>>
>>>You'll be needing support from the web interface to achieve this - see
>>>Ian's proposal above. The beauty is that once the web interface supports
>>>queries, all of the download-related projects benefit (EasyInstall,
>>>Centipyde, Uraga, ...)
>>>
>>>
>>I can see where you are coming from. On the assumption that PyPI is
>>consistent (which is a set of assumptions), download-and-install related
>>projects (all can be seen as implementations of PEP262 one way or another)
>>can query PyPI through the proposed XML-RPC interface, download the stuffs
>>and install the package.
>>
>>
>
>Correct.
>
>
>
>
>>In order for that to happen, from the viewpoint of a
>>download-and-install project, the following set of assumptions must be met
>>in order not to reimplement PyPI in a way or another:
>>
>>1. each entry in PyPI must have a download URL, otherwise it is useless.
>>
>>
>
>Correct (well, useless to *you* but not necessarily useless overall ;).
>
>On the PyPI TODO is adding any uploaded files to the download_url list
>automatically, as currently these are only listed separately.
>
>
>
>
I do agree that it is useful for everyone, at least to know that there
is such a module in the world, if anything else. That is why, I
explicitly state that "from a viewpoint of a download-and-install
project". From that viewpoint, the question to ask when looking at a
download url is "where is the file to download?"
>>2. the download url must be a read downloadable file and a website where
>>you can search for downloads.
>>
>>
>
>I presume the "and" in that sentence was intended to be an "or"?
>
>
There are 2 errors in this sentence. It should read "the download url
must be a *real* downloadable file and *not* a website where you can
search for downloads."
>For answers to this and your subsequent points (3 and 4 on dependencies), I
>draw your attention again to the relevant PEPs that designed distutils and
>PyPI. The latest implemented meta-data PEP is:
>
> http://www.python.org/peps/pep-0314.html
>
>Since this work was only implemented in March this year our biggest problem is
>that of package maintainers moving over to the more strict definitions of
>download_url (ie. not some arbitrary URL, but something that must point
>directly at a file for the release -- this is not enforced, but probably
>should be) and actually supplying dependency information (requires, provides,
>obsoletes).
>
>
This will be great if it is implemented as stated. The toughest part of
it will be to ensure that the dependencies of a module matches another
module in PyPI.
Cheers
Maurice
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mauriceling.vcf
Type: text/x-vcard
Size: 334 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050620/fdd8d42d/mauriceling.vcf
From mauriceling at acm.org Mon Jun 20 01:41:07 2005
From: mauriceling at acm.org (Maurice Ling)
Date: Mon, 20 Jun 2005 09:41:07 +1000
Subject: [Catalog-sig] Another project idea (oldie but a goodie)
In-Reply-To: <200506200921.02708.richardjones@optushome.com.au>
References: <200506191019.18552.richardjones@optushome.com.au>
<200506200805.24540.richardjones@optushome.com.au>
<42B5FBC4.7090705@acm.org>
<200506200921.02708.richardjones@optushome.com.au>
Message-ID: <42B60293.2010304@acm.org>
>>The toughest part of
>>it will be to ensure that the dependencies of a module matches another
>>module in PyPI.
>>
>>
>
>I don't see it this way. As far as I'm concerned, you just have to say "The
>dependencies are X, Y and Z. I can download and install X and Z but you'll
>have to find Y for yourself." Enough irate (or motivated) users later, and
>someone will upload Y to PyPI :)
>
>
From a viewpoint of a human user, yes, that can be expected. We will in
fact expect the person to google for it if it is not in PyPI. From a
viewpoint of a tool, that may be too tricky.
Another thing in my radar is that package names may change. I was
reading an article on O'Reilly ONLamp.com, "Using PySOAP" by Cameron
Laird, written on 06/14/2001
(www.onlamp.com/pub/a/python/2001/06/14/pysoap.html). When reading it, I
realise that instead of PySOAP, it should be SOAPpy. Of course, I do not
know if SOAPpy was named as PySOAP back then, but you see my point......
>We can't hold things up just because PyPI isn't complete - that's going to
>take quite a while to happen. For now we just have to assume that we can't
>satisfy all dependencies by downloading and installing automatically.
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mauriceling.vcf
Type: text/x-vcard
Size: 334 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050620/b48a9957/mauriceling.vcf
From richardjones at optushome.com.au Mon Jun 20 02:50:53 2005
From: richardjones at optushome.com.au (Richard Jones)
Date: Mon, 20 Jun 2005 10:50:53 +1000
Subject: [Catalog-sig] Another project idea (oldie but a goodie)
In-Reply-To: <42B60293.2010304@acm.org>
References: <200506191019.18552.richardjones@optushome.com.au>
<200506200921.02708.richardjones@optushome.com.au>
<42B60293.2010304@acm.org>
Message-ID: <200506201050.54077.richardjones@optushome.com.au>
On Mon, 20 Jun 2005 09:41 am, Maurice Ling wrote:
> >>The toughest part of
> >>it will be to ensure that the dependencies of a module matches another
> >>module in PyPI.
> >
> >I don't see it this way. As far as I'm concerned, you just have to say
> > "The dependencies are X, Y and Z. I can download and install X and Z but
> > you'll have to find Y for yourself." Enough irate (or motivated) users
> > later, and someone will upload Y to PyPI :)
>
> From a viewpoint of a human user, yes, that can be expected. We will in
> fact expect the person to google for it if it is not in PyPI. From a
> viewpoint of a tool, that may be too tricky.
Presumably the tool is invoked by a user, and therefore user feedback is
possible?
> Another thing in my radar is that package names may change. I was
> reading an article on O'Reilly ONLamp.com, "Using PySOAP" by Cameron
> Laird, written on 06/14/2001
> (www.onlamp.com/pub/a/python/2001/06/14/pysoap.html). When reading it, I
> realise that instead of PySOAP, it should be SOAPpy. Of course, I do not
> know if SOAPpy was named as PySOAP back then, but you see my point......
This is something that I hope will be minimised by having the "authoritative"
name database in PyPI.
Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050620/d9a3d257/attachment.pgp
From pje at telecommunity.com Mon Jun 27 05:36:51 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 26 Jun 2005 23:36:51 -0400
Subject: [Catalog-sig] PyPI upload doesn't support eggs?
Message-ID: <5.1.1.6.0.20050626233332.020f7408@mail.telecommunity.com>
I can't seem to convince the "upload" command to send egg distributions to
PyPI. I'm using the CVS head version of "upload", and modified bdist_egg
to add the necessary information to distribution.dist_files, but attempting
to upload gives this response (using --show-response):
Submitting dist\setuptools-0.5a4-py2.3.egg to http://www.python.org/pypi
Upload failed (500): There's been a problem with your request
---------------------------------------------------------------------------
Erro
r...
There's been a problem with your request
exceptions.ValueError: invalid distribution file
-------------------------------
--------------------------------------------
Any suggestions?
From pje at telecommunity.com Mon Jun 27 06:05:02 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 27 Jun 2005 00:05:02 -0400
Subject: [Catalog-sig] [Distutils] PyPI upload doesn't support eggs?
In-Reply-To: <5.1.1.6.0.20050626233332.020f7408@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
I just tried doing the upload via the web interface, and got the same
error. It appears that PyPI doesn't support uploading eggs, which is
surprising because I could've sworn that the sprinters at PyCon said they
were putting eggs on the list of allowed filetypes. But I just found the
appropriate PyPI source code, and '.egg' isn't on the list of allowed file
extensions, so I'll go ahead and file an RFE for this.
At 11:36 PM 6/26/2005 -0400, Phillip J. Eby wrote:
>I can't seem to convince the "upload" command to send egg distributions to
>PyPI. I'm using the CVS head version of "upload", and modified bdist_egg
>to add the necessary information to distribution.dist_files, but attempting
>to upload gives this response (using --show-response):
>
>Submitting dist\setuptools-0.5a4-py2.3.egg to http://www.python.org/pypi
>Upload failed (500): There's been a problem with your request
>---------------------------------------------------------------------------
>Erro
>r...
>
>There's been a problem with your request
>
>exceptions.ValueError: invalid distribution file
>-------------------------------
>--------------------------------------------
>
>Any suggestions?
From rtomayko at gmail.com Mon Jun 27 10:30:05 2005
From: rtomayko at gmail.com (Ryan Tomayko)
Date: Mon, 27 Jun 2005 04:30:05 -0400
Subject: [Catalog-sig] .egg media type? (was: PyPI upload doesn't support
eggs?)
In-Reply-To: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
Message-ID: <273A8ED8-A991-44EE-802B-7EEDCBD95A9E@gmail.com>
On Jun 27, 2005, at 12:05 AM, Phillip J. Eby wrote:
> I just tried doing the upload via the web interface, and got the same
> error. It appears that PyPI doesn't support uploading eggs, which is
> surprising because I could've sworn that the sprinters at PyCon
> said they
> were putting eggs on the list of allowed filetypes. But I just
> found the
> appropriate PyPI source code, and '.egg' isn't on the list of
> allowed file
> extensions, so I'll go ahead and file an RFE for this.
On an almost related note, what should the MIME content/media type be
for serving egg files via HTTP? It may be advantageous to use
"application/zip" [1].
A derivative like "application/egg+zip" would allow the media type to
be associated with easy_install or other handlers while preserving
the base media type information (although I'm not completely clear on
whether derivatives require registration).
[1] http://www.iana.org/assignments/media-types/application/zip
Ryan Tomayko
rtomayko at gmail.com
http://naeblis.cx/rtomayko/
From fdrake at gmail.com Mon Jun 27 15:55:04 2005
From: fdrake at gmail.com (Fred Drake)
Date: Mon, 27 Jun 2005 09:55:04 -0400
Subject: [Catalog-sig] .egg media type? (was: PyPI upload doesn't
support eggs?)
In-Reply-To: <273A8ED8-A991-44EE-802B-7EEDCBD95A9E@gmail.com>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
<273A8ED8-A991-44EE-802B-7EEDCBD95A9E@gmail.com>
Message-ID: <9cee7ab80506270655231e466f@mail.gmail.com>
On 6/27/05, Ryan Tomayko <rtomayko at gmail.com> wrote:
> On an almost related note, what should the MIME content/media type be
> for serving egg files via HTTP? It may be advantageous to use
> "application/zip" [1].
Perhaps.
> A derivative like "application/egg+zip" would allow the media type to
> be associated with easy_install or other handlers while preserving
> the base media type information (although I'm not completely clear on
> whether derivatives require registration).
"application/egg+zip" would require registration. I've not seen the
"+foo" annotation style used for anything other than "+xml" yet, but
this use makes sense to me.
-Fred
--
Fred L. Drake, Jr. <fdrake at gmail.com>
Zope Corporation
From rtomayko at gmail.com Mon Jun 27 16:33:53 2005
From: rtomayko at gmail.com (Ryan Tomayko)
Date: Mon, 27 Jun 2005 10:33:53 -0400
Subject: [Catalog-sig] .egg media type? (was: PyPI upload doesn't
support eggs?)
In-Reply-To: <9cee7ab80506270655231e466f@mail.gmail.com>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
<273A8ED8-A991-44EE-802B-7EEDCBD95A9E@gmail.com>
<9cee7ab80506270655231e466f@mail.gmail.com>
Message-ID: <0BEC27EF-7197-4BD2-B2C6-F99C9D41E150@gmail.com>
On Jun 27, 2005, at 9:55 AM, Fred Drake wrote:
>> A derivative like "application/egg+zip" would allow the media type to
>> be associated with easy_install or other handlers while preserving
>> the base media type information (although I'm not completely clear on
>> whether derivatives require registration).
>>
>
> "application/egg+zip" would require registration. I've not seen the
> "+foo" annotation style used for anything other than "+xml" yet, but
> this use makes sense to me.
Same here. I'm still trying to dig it up but I think I remember
seeing the "+foo" annotation explicitly specified in the normative
application/xml media type specification. But I'm not seeing it so I
could be wrong.
Ryan Tomayko
rtomayko at gmail.com
http://naeblis.cx/rtomayko/
From bob at redivi.com Mon Jun 27 16:32:48 2005
From: bob at redivi.com (Bob Ippolito)
Date: Mon, 27 Jun 2005 10:32:48 -0400
Subject: [Catalog-sig] .egg media type? (was: PyPI upload doesn't
support eggs?)
In-Reply-To: <9cee7ab80506270655231e466f@mail.gmail.com>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
<273A8ED8-A991-44EE-802B-7EEDCBD95A9E@gmail.com>
<9cee7ab80506270655231e466f@mail.gmail.com>
Message-ID: <51DD7AFE-007A-4E1D-9BAE-55B7C5B547D2@redivi.com>
On Jun 27, 2005, at 9:55 AM, Fred Drake wrote:
> On 6/27/05, Ryan Tomayko <rtomayko at gmail.com> wrote:
>
>> On an almost related note, what should the MIME content/media type be
>> for serving egg files via HTTP? It may be advantageous to use
>> "application/zip" [1].
>>
>
> Perhaps.
-1. Eggs should be opaque to software that doesn't necessarily know
what an egg is. For a point of reference, Java's jar format is
'application/java-archive'.
-bob
From rtomayko at gmail.com Mon Jun 27 16:51:52 2005
From: rtomayko at gmail.com (Ryan Tomayko)
Date: Mon, 27 Jun 2005 10:51:52 -0400
Subject: [Catalog-sig] .egg media type? (was: PyPI upload doesn't
support eggs?)
In-Reply-To: <51DD7AFE-007A-4E1D-9BAE-55B7C5B547D2@redivi.com>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
<273A8ED8-A991-44EE-802B-7EEDCBD95A9E@gmail.com>
<9cee7ab80506270655231e466f@mail.gmail.com>
<51DD7AFE-007A-4E1D-9BAE-55B7C5B547D2@redivi.com>
Message-ID: <82E0D872-53C5-4971-B4F9-F13386D24DEC@gmail.com>
On Jun 27, 2005, at 10:32 AM, Bob Ippolito wrote:
> On Jun 27, 2005, at 9:55 AM, Fred Drake wrote:
>> On 6/27/05, Ryan Tomayko <rtomayko at gmail.com> wrote:
>>> On an almost related note, what should the MIME content/media
>>> type be
>>> for serving egg files via HTTP? It may be advantageous to use
>>> "application/zip" [1].
>>
>> Perhaps.
> -1. Eggs should be opaque to software that doesn't necessarily
> know what an egg is.
Yea, "application/zip" would be bad as it would clash with zip
handling applications, making it very unlikely that an egg handling
application could be provided as the default handler.
But what about "application/egg+zip"? If the "+foo" annotation is
doable, it would allow egg handling applications to be registered but
also allow fallback to zip handling applications when there is no egg
handling application available. I don't see the downside.
> For a point of reference, Java's jar format is 'application/java-
> archive'.
I apologize for being cynical but, given Java's history of
disregarding/butchering web and internet architecture, I'd be
surprised if that was put in place by anyone having experience with
internet media types. Media types are like view source/HTML, it's
easy to miss the huge body of spec text dedicated to their behavior.
I really don't know the history of "application/java-archive" though,
so take that as an uninformed, biased, and probably a little unfair jab.
Ryan Tomayko
rtomayko at gmail.com
http://naeblis.cx/rtomayko/
From rtomayko at gmail.com Mon Jun 27 19:17:18 2005
From: rtomayko at gmail.com (Ryan Tomayko)
Date: Mon, 27 Jun 2005 13:17:18 -0400
Subject: [Catalog-sig] .egg media type? (was: PyPI upload doesn't
support eggs?)
In-Reply-To: <0BEC27EF-7197-4BD2-B2C6-F99C9D41E150@gmail.com>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
<273A8ED8-A991-44EE-802B-7EEDCBD95A9E@gmail.com>
<9cee7ab80506270655231e466f@mail.gmail.com>
<0BEC27EF-7197-4BD2-B2C6-F99C9D41E150@gmail.com>
Message-ID: <6320650D-DD11-4A2E-8042-E471A54A15DA@gmail.com>
On Jun 27, 2005, at 10:33 AM, Ryan Tomayko wrote:
> On Jun 27, 2005, at 9:55 AM, Fred Drake wrote:
>> "application/egg+zip" would require registration. I've not seen the
>> "+foo" annotation style used for anything other than "+xml" yet, but
>> this use makes sense to me.
>
> Same here. I'm still trying to dig it up but I think I remember
> seeing the "+foo" annotation explicitly specified in the normative
> application/xml media type specification. But I'm not seeing it so
> I could be wrong.
The "+xml" suffix is the only suffixing scheme at IANA and is
normatively defined in the RFC 3023 XML Media Types [1]. The section
linked to below contains justification for inventing the suffixing
scheme, which is almost as interesting as it is amusing. :)
[1] <http://rfc.net/rfc3023.html#p32>
Ryan Tomayko
rtomayko at gmail.com
http://naeblis.cx/rtomayko/
From fdrake at gmail.com Mon Jun 27 20:04:17 2005
From: fdrake at gmail.com (Fred Drake)
Date: Mon, 27 Jun 2005 14:04:17 -0400
Subject: [Catalog-sig] .egg media type? (was: PyPI upload doesn't
support eggs?)
In-Reply-To: <6320650D-DD11-4A2E-8042-E471A54A15DA@gmail.com>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
<273A8ED8-A991-44EE-802B-7EEDCBD95A9E@gmail.com>
<9cee7ab80506270655231e466f@mail.gmail.com>
<0BEC27EF-7197-4BD2-B2C6-F99C9D41E150@gmail.com>
<6320650D-DD11-4A2E-8042-E471A54A15DA@gmail.com>
Message-ID: <9cee7ab805062711042967c1f3@mail.gmail.com>
On 6/27/05, Ryan Tomayko <rtomayko at gmail.com> wrote:
> The "+xml" suffix is the only suffixing scheme at IANA and is
> normatively defined in the RFC 3023 XML Media Types [1]. The section
> linked to below contains justification for inventing the suffixing
> scheme, which is almost as interesting as it is amusing. :)
The "XML is the first generic data format that has seemed to justify
special treatment" (A.14) in certainly humorous, especially given the
context of this discussion.
I'm firmly in the "application/egg+zip" camp at this point.
-Fred
--
Fred L. Drake, Jr. <fdrake at gmail.com>
Zope Corporation
From martin at v.loewis.de Mon Jun 27 23:05:12 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 27 Jun 2005 23:05:12 +0200
Subject: [Catalog-sig] [Distutils] PyPI upload doesn't support eggs?
In-Reply-To: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
Message-ID: <42C06A08.1010504@v.loewis.de>
Phillip J. Eby wrote:
> I just tried doing the upload via the web interface, and got the same
> error. It appears that PyPI doesn't support uploading eggs, which is
> surprising because I could've sworn that the sprinters at PyCon said they
> were putting eggs on the list of allowed filetypes.
I'm not sure whom specifically you are referring to - I personally
don't recall saying such a thing.
Regards,
Martin
From pje at telecommunity.com Mon Jun 27 23:16:20 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 27 Jun 2005 17:16:20 -0400
Subject: [Catalog-sig] [Distutils] PyPI upload doesn't support eggs?
In-Reply-To: <42C06A08.1010504@v.loewis.de>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
<5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20050627171310.036590e0@mail.telecommunity.com>
At 11:05 PM 6/27/2005 +0200, Martin v. L?wis wrote:
>Phillip J. Eby wrote:
> > I just tried doing the upload via the web interface, and got the same
> > error. It appears that PyPI doesn't support uploading eggs, which is
> > surprising because I could've sworn that the sprinters at PyCon said they
> > were putting eggs on the list of allowed filetypes.
>
>I'm not sure whom specifically you are referring to - I personally
>don't recall saying such a thing.
I think it was Richard Jones who said he was including .egg on the list. I
gave him some additional info about the format (e.g. that eggs include an
EGG-INFO/PKG-INFO file), but he said he didn't think it was worth bothering
with checking beyond the filename for .egg. (I mention this only to
highlight the point that we did talk for a minute or so on the subject, not
to get into the subject of the .egg format's internal layout.)
Anyway, I got the impression from what was said that he was actually
literally implementing the filetype check as we spoke about it, which is
why I was surprised to find it's not actually in there.
From richardjones at optushome.com.au Wed Jun 29 01:15:15 2005
From: richardjones at optushome.com.au (Richard Jones)
Date: Wed, 29 Jun 2005 09:15:15 +1000
Subject: [Catalog-sig] [Distutils] PyPI upload doesn't support eggs?
In-Reply-To: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
Message-ID: <200506290915.15984.richardjones@optushome.com.au>
On Mon, 27 Jun 2005 02:05 pm, Phillip J. Eby wrote:
> I just tried doing the upload via the web interface, and got the same
> error. It appears that PyPI doesn't support uploading eggs, which is
> surprising because I could've sworn that the sprinters at PyCon said they
> were putting eggs on the list of allowed filetypes.
Hurm. I recall talking about it. Sorry the code didn't actually make it in!
I'm still trying to find some time to actually work on PyPI, and fixing some
issues with the file upload are on the top of the list - right next to
migrating over to the new hardware and actually *promoting* the thing.
Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050629/9c551a31/attachment.pgp
From ianb at colorstudy.com Thu Jun 30 19:51:56 2005
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 30 Jun 2005 12:51:56 -0500
Subject: [Catalog-sig] .egg media type?
In-Reply-To: <9cee7ab805062711042967c1f3@mail.gmail.com>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com> <273A8ED8-A991-44EE-802B-7EEDCBD95A9E@gmail.com> <9cee7ab80506270655231e466f@mail.gmail.com> <0BEC27EF-7197-4BD2-B2C6-F99C9D41E150@gmail.com> <6320650D-DD11-4A2E-8042-E471A54A15DA@gmail.com>
<9cee7ab805062711042967c1f3@mail.gmail.com>
Message-ID: <42C4313C.5040102@colorstudy.com>
Fred Drake wrote:
> On 6/27/05, Ryan Tomayko <rtomayko at gmail.com> wrote:
>
>>The "+xml" suffix is the only suffixing scheme at IANA and is
>>normatively defined in the RFC 3023 XML Media Types [1]. The section
>>linked to below contains justification for inventing the suffixing
>>scheme, which is almost as interesting as it is amusing. :)
>
>
> The "XML is the first generic data format that has seemed to justify
> special treatment" (A.14) in certainly humorous, especially given the
> context of this discussion.
>
> I'm firmly in the "application/egg+zip" camp at this point.
But shouldn't that be application/x-egg+zip ?
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
From fdrake at gmail.com Thu Jun 30 21:51:25 2005
From: fdrake at gmail.com (Fred Drake)
Date: Thu, 30 Jun 2005 15:51:25 -0400
Subject: [Catalog-sig] .egg media type?
In-Reply-To: <42C4313C.5040102@colorstudy.com>
References: <5.1.1.6.0.20050626235632.020fbe60@mail.telecommunity.com>
<273A8ED8-A991-44EE-802B-7EEDCBD95A9E@gmail.com>
<9cee7ab80506270655231e466f@mail.gmail.com>
<0BEC27EF-7197-4BD2-B2C6-F99C9D41E150@gmail.com>
<6320650D-DD11-4A2E-8042-E471A54A15DA@gmail.com>
<9cee7ab805062711042967c1f3@mail.gmail.com>
<42C4313C.5040102@colorstudy.com>
Message-ID: <9cee7ab80506301251296daa6b@mail.gmail.com>
On 6/30/05, Ian Bicking <ianb at colorstudy.com> wrote:
> But shouldn't that be application/x-egg+zip ?
Not if it's registered.
-Fred
--
Fred L. Drake, Jr. <fdrake at gmail.com>
Zope Corporation