CPAN functionality for python - requirements

Sean Reifschneider jafo at tummy.com
Tue Feb 27 14:53:51 EST 2001


On Tue, Feb 27, 2001 at 06:28:32AM -0500, Doug Hellmann wrote:
>It sounds like the knows how to find a particular package, but getting it
>installed is your problem.  We can make it smarter than that.

That's more a distutils problem than an archive network problem.  My
vision is that the archive network simply gives the client package
information, which the client then can deal with as they see fit.
Ideally, once downloaded, the archive network client would then just
tell the package "Install thyself", but there will probably have to
be some additional smarts in the client than that.

I expect these additional smarts to be little more than scripts:

	mkdir tmpdirectory
	cd tmpdirectory
	tar xpvfz archivefile
	cd archivename-with-.tar.gz-removed
	python setup.py

That sort of thing...

>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?

That decision is up to the client.  If the client has the smarts to turn
a distutils package into an RPM, then the client would list it's preferred
format as a distutils package and it would handle the rest.  If it can't,
you can either select an RPM, or fall back to a distutils package.

>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.

That's exactly my target.

>> 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.

The schema lists platform version, name, architecture, and format.  So, it
can handle "RedHat 7.0 ix86 in RPM format" if we wish.  Any of those
fields can be "*", which will probably be the case in source distutils
package cases.

>Wait -- maybe that's where the disconnect is!  I'm describing features of the
>system from the client-side view, assuming the network would provide services
>to support those features.  It sounds like you are describing features of the

The archive network client I believe should have a step which is "install
this", but I believe that largely needs to be abstracted from the client.
Scripts that are used to control the "I've got this thing, here's how to
install it".  In the case of a tar file (not a distutils package) we
probably want to extract it then drop the user into a shell saying
"Check out the README and INSTALL files, do the install, then type
'exit' when done".  Automating it to the point that we can...

>network.  We should determine the requirements from the user perspective first,
>and design something to meet those requirements.  Designs for the network
>services will follow from the requirements.

That's why I've been posting my schema and trying to decide what my vision
of the client interaction is.  If it doesn't meet the user needs, then
it needs to be re-worked.  However, I believe it has the flexability to
handle the policy decisions that have been discussed here.

>I can't remember now whether CPAN did installations or just downloaded stuff
>and made you figure out how to install it.

It does a "make test" and a "make install".  There is a convention that CPAN
packages will have a "make test", even if it doesn't do much.  It's a great
idea...

With Python modules we could almost make some of the dependencies automatic.
If we try to import the module and it throws an exception on an import, we
know we've hit a dependency...  That'd be cute...

>Right, so we need a single way of determining, maintaining, and
>resolving dependencies.

One could say that the appropriate way to find out if a required module
is available is to try importing it.

I firmly believe that we have to allow not only system-wide installs,
but also user installs (into their home directory, for example).

Sean
-- 
 Come see the violence inherent in the system!
 Help!  Help!  I'm being repressed!  -- Monty Python and the Holy Grail
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python




More information about the Python-list mailing list