CPAN functionality for python - requirements

[Doug Hellmann]

In article <mailman.983284693.1818.python-list at python.org>, "Bruce Sass"
<bsass at freenet.edmonton.ab.ca> wrote:

> On Tue, 27 Feb 2001, Doug Hellmann wrote:
>> On Tue, 27 Feb 2001, Bruce Sass wrote:
>> > On Mon, 26 Feb 2001, Doug Hellmann wrote:
>> > > On Mon, 26 Feb 2001, Sean Reifschneider wrote:
>> > > > On Mon, Feb 26, 2001 at 06:45:33AM -0500, Doug Hellmann wrote:
>> > <...>
>> > Dependencies are a big problem.  I've spoken with a local LUG member
>> > who was complaining that Debian does not know about the stuff he gets
>> > from CPAN, which makes mixing CPAN and debianized CPAN stuff a pain.
>> > Debian's solution is a user level program to debianize arbitrary CPAN
>> > modules... I want the same solution for Python modules, except I want
>> > it done transparently.
>>
>> I can see that as somewhat desirable, and it could be implemented, but
>> do you make the cyphon client download the right package format or
>> convert a standard distro into the right format?  Doesn't the user have
>> to specify a package type?
> 
> I prefer building from a generic package to a system specific package

This model would work. I didn't realize distutils would generate
system-specific package formats.  If we and agree on a standard format,
then it would be possible to populate the archive network with standard
formats and optional system-specific formats.  As a developer, I might
choose to provide several formats.  As a mirror operator, I might choose
to support one or many formats, and do some conversion for the end user.
As a user, I could choose to download in whatever format is available and
then convert to the format I want to use for installation.

> I would not use it if it means bypassing the native package management
> system, and would be willing to wait for "official" packages rather than
> use third-party packages.

What "official" packages do you mean here?

> Best of all scenarios would be if all the Python programmers used the
> same system I did and spit out packages in my favorite format, next best
> is having a package built by someone who knows my system just as well or
> better than I, then their proxy in the form of a scripted build,
> followed by someone I don't know building the package, a tarball or some
> other package format I can handle.
> 
> The first is a dream, the second could happen now and then if I was
> lucky, so I'll try for my third choice (and it sounds like distutils can
> handle it).

I think that's where we're headed.

>> > Downloading is independent of the native package management system.
>>
>> No, it isn't.  Even if *all* the tool does is download things I told it
>> to find and write them to the current directory, it has to know what
>> format I like or it may download (for example) debian packages for my
>> Mac -- and then I won't get useful results from the tool.
> 
> Build up the name of the download from the name of the package and
> system specific information, just like is done with the names of .deb
> and .rpm packages.

File type should not be dependent on file names.  We can add file type as
a field in the database.

>> > Complexity is only increased if the new tool thinks it should handle
>> > platform/OS/distro specific issues.
>>
>> It *must* handle those issues to be useful.
> 
> Isn't that is a lot of duplicated work.

Not if we use distutils for that part.

[About CPAN features...]

>> > Cons: Dependencies problems when mixed with modules fetched by other
>> > methods.
>>
>> Right, so we need a single way of determining, maintaining, and
>> resolving dependencies.
> 
> Or a way of enabling the native tools so they can do it.  I would not
> want to accept the job of keeping up with changing packaging standards
> for <how many?> different systems, and don't expect that anyone else
> would want to (or be able to keep it up).

But dependencies could be built into the network data structure.  Then it
is independent of the uploaded package format entirely.  AND, I would be
able to discover that the contents of the RPM I want depend on some other
package which exists only in source and deb formats.

Doug