headers
Richard Jones | 2 Jan 2005 23:47
Picon

Re: PyCon sprint for PEPs 314 and 243?


On Fri, 31 Dec 2004 08:48 pm, Bob Ippolito wrote:
> I'm interested in helping this along.  Similar to your revisions with
> PEP-243, here's what I think should happen to PEP 314:
> [python module names only as provides/requires]

This seems reasonable to me. In particular:

> Requires should not be arbitrary.

I really can't see a reasonable situation where anything *other* than this 
could be the case (racking my brain to try to think of *any* python module / 
package which could be replaced with another, retaining API compatibility).

The current list of changes to PEP 314 version 1.15 are:

* Platform and License need to be altered to indicate they take text 
describing the platform/full license text in the case where there is no 
appropriate Classifier. 
* Requires/Provides need to specify *only* python package or module names. 
Abstract names are not considered useful.
* Conflicts, on the other hand, probably *does* need to specify actual 
distutils package names, rather than python package names or module names, as 
the latter can be determined from the Provides field.

I've had another glance at DOAP, but I think I'd need to dedicate at least 
half a day to it, which I don't have at the moment. Is anyone up to speed 
enough with it to give a summary of what we'd need to change to become 
compatible? Or does the patch against PyPI:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bob Ippolito | 3 Jan 2005 00:13
Gravatar

Re: PyCon sprint for PEPs 314 and 243?


On Jan 2, 2005, at 5:47 PM, Richard Jones wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, 31 Dec 2004 08:48 pm, Bob Ippolito wrote:
>> I'm interested in helping this along.  Similar to your revisions with
>> PEP-243, here's what I think should happen to PEP 314:
>> [python module names only as provides/requires]
>
> This seems reasonable to me. In particular:
>
>
>> Requires should not be arbitrary.
>
> I really can't see a reasonable situation where anything *other* than 
> this
> could be the case (racking my brain to try to think of *any* python 
> module /
> package which could be replaced with another, retaining API 
> compatibility).
>
> The current list of changes to PEP 314 version 1.15 are:
>
> * Platform and License need to be altered to indicate they take text
> describing the platform/full license text in the case where there is no
> appropriate Classifier.
> * Requires/Provides need to specify *only* python package or module 
> names.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Reifschneider | 16 Jan 2005 01:23
Gravatar

Re: PyCon sprint for PEPs 314 and 243?

On Fri, Dec 31, 2004 at 08:28:35PM +1100, Richard Jones wrote:
>Without looking into it too closely, it seems like yum is closely tied to RPMs 
>and their associated package databases.

I would suspect that the code for handling mirror lists and downloading of
files is not at all tied to the RPM file format.  That code has had
something like a year of development on it, and probably can be used with
few changes.

There are 3 different downloaded file types: RPM packages, RPM headers, and
the repository information.  The repository information would probably
require some tweeks, and the RPM packages and headers would need to be
replaced with something else.  Unless we were to decide to use RPM as the
package format.  Which is probably also not a bad idea.

>Also, I'm not sure I want to try to solve dependencies.

I'm not sure you have a choice not to.  I'm also not sure it's as hard a
problem as some people seem to think.  Red Hat and Debian have fairly good
solutions to this problem with years and years of thought behind them.

Sean
--

-- 
 Like its politicians and its wars, society has the teenagers it deserves.
                 -- J. B. Priestley
Sean Reifschneider, Member of Technical Staff <jafo <at> tummy.com>
tummy.com, ltd. - Linux Consulting since 1995.  Qmail, Python, SysAdmin
Permalink | Reply | 3 comments |
headers
Bob Ippolito | 16 Jan 2005 01:53
Gravatar

Re: PyCon sprint for PEPs 314 and 243?

On Jan 15, 2005, at 19:23, Sean Reifschneider wrote:

> On Fri, Dec 31, 2004 at 08:28:35PM +1100, Richard Jones wrote:
>> Without looking into it too closely, it seems like yum is closely 
>> tied to RPMs
>> and their associated package databases.
>
> I would suspect that the code for handling mirror lists and 
> downloading of
> files is not at all tied to the RPM file format.  That code has had
> something like a year of development on it, and probably can be used 
> with
> few changes.

Well, yum is GPL and therefore not suitable for inclusion into Python.  
It doesn't really matter if the code is already written in Python and 
implements some useful things, unless you're certain that you can get 
those components relicensed to suit Python.

> There are 3 different downloaded file types: RPM packages, RPM 
> headers, and
> the repository information.  The repository information would probably
> require some tweeks, and the RPM packages and headers would need to be
> replaced with something else.  Unless we were to decide to use RPM as 
> the
> package format.  Which is probably also not a bad idea.

Is the RPM format itself well specified?  Is there already a suitably 
licensed pure Python implementation for creating and using RPM files?  
Platforms that don't already have RPM are going to need it, and I
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sean Reifschneider | 17 Jan 2005 01:17
Gravatar

Re: PyCon sprint for PEPs 314 and 243?

On Sat, Jan 15, 2005 at 07:53:51PM -0500, Bob Ippolito wrote:
>Is the RPM format itself well specified?

Yes.  At it's heart it's just a cpio archive with some extra information.

>Is there already a suitably 
>licensed pure Python implementation for creating and using RPM files?

Doubtful.  However, it's still valuable to use a mature package format,
despite lack of existing code, as it prevents you from having to design and
build a new format.  .deb and .rpm have years of experience under their
belts, including ability to be relocated, tools to build and manipulate
them, signatures in the case of .rpm, dependencies, etc...  I'd recommend
.rpms primarily because they have the ability to be signed.

>Platforms that don't already have RPM are going to need it, and I 
>believe that librpm is GPL (and probably also not portable everywhere 
>Python is), so we couldn't add that dependency for an extension to wrap 
>this functionality.

Personally, I wouldn't use a system that didn't integrate with my system
package format.  Instead I'd prefer "python setup.py bdist_rpm" or
bdist_deb.  That's why I was always more interested in solving the problem
of distributing these packages as opposed to building a new package format.

The process of building the catalot system seems to get mired down in
issues like handling all platforms and allowing non-root users to install
packages outside of the system package location.

>Dependency tracking and resolution requires package maintainers.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Jones | 17 Jan 2005 02:33
Picon

Re: PyCon sprint for PEPs 314 and 243?


On Sun, 16 Jan 2005 11:23 am, Sean Reifschneider wrote:
> On Fri, Dec 31, 2004 at 08:28:35PM +1100, Richard Jones wrote:
> >Without looking into it too closely, it seems like yum is closely tied to
> > RPMs and their associated package databases.
>
> I would suspect that the code for handling mirror lists and downloading of
> files is not at all tied to the RPM file format.  That code has had
> something like a year of development on it, and probably can be used with
> few changes.

It's been pointed out that yum is GPL, which precludes any of its code going 
into Python. We might be able to learn from its design though when we address 
downloading from mirrors.

> There are 3 different downloaded file types: RPM packages, RPM headers, and
> the repository information.  The repository information would probably
> require some tweeks, and the RPM packages and headers would need to be
> replaced with something else.  Unless we were to decide to use RPM as the
> package format.  Which is probably also not a bad idea.

I don't see what RPM gains us over the sdist format.

> >Also, I'm not sure I want to try to solve dependencies.
>
> I'm not sure you have a choice not to.  I'm also not sure it's as hard a
> problem as some people seem to think.  Red Hat and Debian have fairly good
> solutions to this problem with years and years of thought behind them.

No, I do have a choice not to, and I choose not to :)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris McAvoy | 20 Jan 2005 19:02
Picon

We'd really like to Sprint.

Hi catalog-sig,

Forgive me for being a bull in a china shop, but can someone suggest a
5 hour Sprint task for the Chicago Python Users Group to Sprint on? 
Is there a paragraph in a PEP that we could tackle with the
catalog-sig's blessing?

Thanks,
Chris
Permalink | Reply | 5 comments |
headers
Richard Jones | 28 Jan 2005 09:14
Picon

Re: We'd really like to Sprint.


On Fri, 21 Jan 2005 05:02 am, Chris McAvoy wrote:
> Forgive me for being a bull in a china shop, but can someone suggest a
> 5 hour Sprint task for the Chicago Python Users Group to Sprint on?
> Is there a paragraph in a PEP that we could tackle with the
> catalog-sig's blessing?

Sorry for the delay. 5 hours probably isn't enough for any of the things I had 
planned. I guess if you were able to get together a patch implementing PEP 
314 then that would be great. I've still not revised the PEP, which I will 
try to do this evening around the most recent discussion:

  http://article.gmane.org/gmane.comp.python.catalog/240

I'm still keen to actually Sprint at PyCon - I'm going to put up the proposal 
in the wiki tonight too. If nothing else, I'll sit around before PyCon and 
bloody well write the thing by myself :)

    Richard
Permalink | Reply | 4 comments |
headers
Chris McAvoy | 28 Jan 2005 15:49
Picon

Re: We'd really like to Sprint.

Is there anything that we could do in 5 hours?  We had talked about an
XML-RPC interface for searching, and a client.  Something that could
grow into the perl -MCPAN -e shell sort of interface.  Is that
something you'd be interested it?

5 hours could build an XML-RPC client and server with time left over
for us to figure out how to Sprint.

Chris

On Fri, 28 Jan 2005 19:14:39 +1100, Richard Jones
<richardjones <at> optushome.com.au> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 21 Jan 2005 05:02 am, Chris McAvoy wrote:
> > Forgive me for being a bull in a china shop, but can someone suggest a
> > 5 hour Sprint task for the Chicago Python Users Group to Sprint on?
> > Is there a paragraph in a PEP that we could tackle with the
> > catalog-sig's blessing?
> 
> Sorry for the delay. 5 hours probably isn't enough for any of the things I had
> planned. I guess if you were able to get together a patch implementing PEP
> 314 then that would be great. I've still not revised the PEP, which I will
> try to do this evening around the most recent discussion:
> 
>   http://article.gmane.org/gmane.comp.python.catalog/240
> 
> I'm still keen to actually Sprint at PyCon - I'm going to put up the proposal
> in the wiki tonight too. If nothing else, I'll sit around before PyCon and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Bicking | 28 Jan 2005 18:07
Gravatar

Re: We'd really like to Sprint.

Richard Jones wrote:
> On Fri, 21 Jan 2005 05:02 am, Chris McAvoy wrote:
> 
>>Forgive me for being a bull in a china shop, but can someone suggest a
>>5 hour Sprint task for the Chicago Python Users Group to Sprint on?
>>Is there a paragraph in a PEP that we could tackle with the
>>catalog-sig's blessing?
> 
> 
> Sorry for the delay. 5 hours probably isn't enough for any of the things I had 
> planned. I guess if you were able to get together a patch implementing PEP 
> 314 then that would be great. I've still not revised the PEP, which I will 
> try to do this evening around the most recent discussion:

There's also a lot of more boring (wait, no, straight-forward but fun!) 
tasks that we could do as well, like port it to WSGI so it could be run 
under mod_python, make it run with Postgres, and separating out the HTML 
into templates (ZPT I'd guess).  Whatever it is, it should be something 
we can get cleaned up and integrated before the PyCon sprint.

>   http://article.gmane.org/gmane.comp.python.catalog/240
> 
> I'm still keen to actually Sprint at PyCon - I'm going to put up the proposal 
> in the wiki tonight too. If nothing else, I'll sit around before PyCon and 
> bloody well write the thing by myself :)

Well, there might be parts we can work on in advance, based on the 
presumption you (and your multitude of sprinting minions!) will be 
filling in other parts later.  E.g., we could work on a mirroring 
script, which might later use some appropriate metadata that's added to
(Continue reading)

Permalink | Reply | 2 comments |

Gmane